💾 Archived View for idiomdrottning.org › page-vs-capsule captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

The Page vs The Capsule

URLs have tree semantics, which is evidenced in practice by the way relative links work. (Especially since .. and co exist).

A link to bar/baz from gemini://server/foo leads to gemini://server/bar/baz while a link to bar/baz from gemini://server/foo/ leads to gemini://server/foo/bar/baz.

I’ve now implemented 31s and 301s from the slashed to unslashed so now I can start using relative links again. Except they’ll have to be written to reflect the reality that /foo is a leaf node and not a directory node, i.e. the leaf node is no longer a file named “” (the empty string).

It’s also something that might be good to reflect in culture and convention.

I could see if, for example “gemini://medusae.space/index.gmi?20”, instead had the url been gemini://medusae.space/home/cooking/index.gmi, how that would make sense in some way.

I’ve kept my own web page & capsule having all flat URLs in one huge name space for a while. It’s a tradeoff…

It’s in service of the page—someone can visit, and link to a text like gemini://idiomdrottning.org/semmel or a particular image or git repo and it’s just the most sense-making URL I could think of for that particular resource.

The philosophy of trying to present any one resource as if it were as first class as possible, short of registering a domain for it.

Any one given resource doesn’t try to “upsell” anything else. It’s not an ad for the rest of the capsule.

In service of the page but at the expense of the capsule as a whole.

If that had been in gemini://idiomdrottning.org/aesthetics/semmel instead people would be like “Oh, she has other categories maybe?” or “Oh, maybe there are more ‘aesthetics’ posts?”

There’s a gradient of possible points I could’ve landed on between designing the capsule in service of each particular resource, for people who are exploring the larger web and get linked to and wanna read/view/hear/clone one particular thing, vs designing it in service of those who want to explore my own capsule specifically.

Generally I leaned towards the former when it comes to URL design. That was a deliberate decision but it definitely came with drawbacks when it comes to discoverability and “upsell”. But I kinda thought those drawbacks were cool in a way. Like “OK here’s what you wanted to read, hope you liked it. Have a nice day now. Come again if you wanna but there’s no ‘ads’—not even in the URL.”

That’s also why the images don’t each have their own li’l web chrome page, instead the gallery links just lead directly to png and jpg files. It’s just: How can I… let go, maximally, of the text or image? How can I let it be itself without trying to hold on to it? That was the goal.

After a few years I did add overview pages, such as /texts for example, for those who do wanna explore the full thing. RSS and atom (and now gmisub) I’ve supported since day one. Since that was supported for those who specifically requested to keep up with the latest and loudest, I saw less of a need to make the entire web page push the newest stuff, or be date- or time- or FOMO-based. You basically need to view source to even see dates if you don’t use a feed reader.

It’s sort of a design paradigm I always liked. Make simple things even simpler, but keep unusual things possible (not just in your face).

In software, a minimally simple set of options but you can tweak to your heart’s content with a about:config or a registry or a .conf.rc file.

In hardware, huge friendly buttons on the front for everyday stuff and smaller buttons on the back for things only weird nerds wanna do occasionally.

In web design, only the most relevant links and text, and then rel alternate or meta name dc.created or whatever for those who want more.