Gemini - The small Internet
December 20, 2021
Gopher
Over the course of the workday Iâll do routine things like browse Stack Overflow, tinker around with a React feature in a codesandbox someone made, check Twitter real quick, Google an obscure error message, and so on. And sometimes Iâll find myself thinking that surely this is the Internet, and this must be how everyone interacts with the web.
Of course, the Internet is not those things. It isnât those things now, and it never was those things. Itâs completely incidental that we even have Google, Twitter, JavaScript, or HTTP, or even the Internet at all, for that matter.
The incidental nature of the modern web becomes a bit more apparent when you consider that there was (and still is) an alternative to what we think of as the web, which was the Gopher protocol. In the Gopher model, when you visit a site in âGopherspaceâ, youâre presented with a plain text menu that you can use to access sub menus or text documents.
Itâs a rigid hierarchical structure thatâs different from the sprawling web that constitutes what we usually think of as the Internet. Although Gopher can send binaries and some image formats, most content is plain text. And there is no notion of enriching this text via any sort of styling or interactivity, thatâs purely a web concept.
There arenât that many Gopher servers around, but there is definitely still a dedicated community who argue that Gopher is still relevant today.
The Gemini Project
Gemini is another alternative to both the web and Gopher that emerged in 2019.
I discovered the existence of both Gemini (when someone posted a link to the Lagrange Gopher/Gemini client on Hacker News), gopher way back in the 1990s - and have been almost mesmerised by both ever since.
This yearning is embedded in the protocol design. I highlight a few interesting features here, but the FAQ linked above definitely deserves its own read. Consider the following Gemini protocol features:
Gemini supports exactly one response header, Content-Type.
This means there is no support for cookies or any other tracking mechanism that could potentially be injected into the server response. Section 2.12 of the FAQ, âWhy isnât there an equivalent of the HTTP Content-length header?â provides a beautiful justification for this design choice:
Non-extensibility of the protocol was a major design principle for Gemini. Things like cookies, Etags and other tracking tools were not present in the original design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers. To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to include one and exactly one piece of information in the response header for successful requests. Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again. There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality. Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length. The same is true for other harmless and useful HTTP headers, like Last-Modified.
The idea of putting hard limitations in place to ensure the community remains safe from invasive tracking technologies is deeply compelling.
Geminiâs ânativeâ content type, text/gemini has no support for styling
Whereas CSS can be embedded in the webâs ânativeâ content type, HTML, via style tags or inline styles, Geminiâs gemtext markup language has no such facilities. This language is inspired by Markdown, but has a few key differences, e.g only supporting three levels of headings, no nested lists, etc.
The idea here is that the protocol designers put styling in the hands of the readers, not the content creators, thus section 2.11, âWhy doesnât text/gemini have support for styling?â :
While itâs true that something much simpler and lighter than CSS could easily be designed, Gemini instead takes the position that visual styling of Gemini content should be under the sole and direct control of the reader, not the writer. Not everybody has the same taste in colours and fonts, and no single way of styling a page will be optimal for all readers, all devices and all lighting conditions. There is much more at stake here than the age old divide in preference for dark text on a light background or vice versa. People with reading disabilities like dyslexia may benefit tremendously from using specially designed fonts, for example.
âŚ
Experience from the web suggests that accessibility issues will often be an afterthought at best. Itâs much simpler, and in fact much more liberating for content authors, to let content just be content, and leave styling to the client.
The list of Gemini clients, contains terminal clients as well as GUI clients that pay a little more attention to style. Itâs up to the user to decide how they want to consume Gemini content.
There is nothing stopping anyone from serving html over Gemini with a mimetype of text/html, and someone else creating a Gemini client that parses it and renders it with CSS, JS, etc. But that would really be missing the point.
The very fact that Gemini is a different protocol from HTTP.
What resonated the most with me was the answer to the obvious question asked in section 2.5, âWhy not just use a subset of HTTP and HTML?â This gets at the heart of the Gemini project. There are plenty of websites out there that have little to no styling but still host amazing content. Why bother with creating a new protocol? The answer:
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. Itâs impossible to know in advance whether whatâs on the other side of a https:// URL will be within the subset or outside it. Itâs very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. Itâs difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules youâll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, youâd have a very difficult time discovering the minuscule fraction of websites it could render.
Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While youâre there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites youâve never heard of before, which just popped up yesterday, and be confident that they wonât try to track you or serve you garbage because they canât. You can do all this with a client you wrote yourself, so you know you can trust it. Itâs a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
Gemini provides guarantees about content that do not and cannot exist on the web.
The Small Internet
Knowing a bit more about Gemini, I highly encourage you to download a client and go for a walk through Geminispace. The Gemini search engine lives at gemini://geminispace.info/. Point your client there and look for whatever you like. Browsing through peopleâs sites (called âcapsulesâ in Geminspace) is delightful, and feels liberating to me in the way I believe the creators intended.
One capsule I found has an interesting post outlining the way publishing in Geminispace differs from publishing on the web. Gemtext doesnât support inline links the way Markdown does, every link has to be its own line. Itâs a small difference, but it forces you to think more deeply about where to put your links, and what content deserves to be linked to, since links are much less subtle in gemtext. The result is typically longer blocks of text - more of the authorâs own thoughts on a subject instead of just a vehicle for links that lead to other places.
To many people, plentiful linking is what makes the web great, in which case Gemini might not be the best option. The Gemini maintainers fully acknowledge this, and it is not the intention of the project to replace Gopher or the web, but to coexist with them for the benefit of people who want to experience a particular flavour of content.
Maya makes an interesting point when she says that maybe the reason that Geminispace feels so good is because itâs new and only accessible to people who have at least some technical inclinations. To get on there requires a little bit more effort than just hitting the Tweet button (but not that much).
Her sentiment that Gemini âis a grail quest for the Eternal August, before webscale crushed the things we loveâ feels heartbreakingly true. It would be great if more people discovered Geminispace, but then maybe the community would have to contend with a deterioration in the content.
Or maybe not. Iâm choosing to remain optimistic and excited about the future of the Gemini project. There is so much out there to discover - so many tiny, hidden capsules, so much wonder.
Links
Gemini search engine (HTTP version)