💾 Archived View for drawk.cab › projects › gemini-site › gemini-reflections.gmi captured on 2024-05-12 at 15:24:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
The Gemini project occupies two adjacent niches: a transfer protocol, and a hypertext markup language (yes, but that is exactly what gemtext is.) And both are well in the running for simplest usable thing in those niches. To dismiss gemini on the grounds that there are more featureful or more useful things in the same niches is just to deny that there is value or beauty in the simplicity for its own sake.
But I wonder if the project has limited its own scope by focusing on people interested in both of these two niches.
This is good. I don't miss ordered lists. I hope it doesn't get extended very much. The journey of HTML is kind of interesting in that over the years it's managed to move away from batshit random (oh, also SGML) to something which is actually pretty coherent and fit for purpose. You can reject the purpose, but imo you can't deny that HTML5 is the best HTML yet. Gemini just doesn't try to be in that race.
I do miss emphasis though. Arguably if I can't emphasize something using rhetoric, it isn't worth emphasizing using pixels, but I'm really not used to that.
The interest in Gemtext could be pretty wide, if you include everyone who has written an e-mail but has been put off setting up a Web page. Gemtext pages are lightweight, and because their semantics are simple, I'd expect them to work well with assistive technologies too.
Gemini-the-protocol takes what we've learned about hypertext protocols and pares it back. It's got status codes (HTTP/0.9 didn't) but it doesn't have caching or keep-alive or lots of other features, because the (not always) unspoken pact is that Gemini will never be big, and so will never need these complicating features.
Firmly part of a "roll your own" maker culture, Gemini feels transparent and comprehensible. However, it can only be comprehensible because the rest of the hugely complex network stack is well abstracted. And this is where I feel the protocol has its weakness. I can write a 100-line Gemini client in Python, provided it begins with
import ssl, sockets
but then I can write an equally small HTTP client if I begin it with
import requests
So the actual protocol is only interesting to hobbyists who want to tinker with that specific layer, and it's actively detrimental to scalability, because of the features of HTTP that it's abandoned.
However, there is another aspect to having a separate protocol.
A URL scheme clearly defines a space. The concept of a new space is very important to the project, as we can see from quotes like
I couldn't believe it, and it inspired me to make something of my own: my own space.
or
As I continue my journey in life of becoming ever more obscure, I eventually find myself in Gemspace
or
Welcome traveller. Park up your Gemini capsule, rest your legs, roast a marshmallow, and chill out.
By not using HTTP, Gemini forces users to rethink their side of things. Their favourite browser doesn't get the scheme, so there is a small barrier to entry. But it's an equitable barrier, as much as such a thing is possible. The need for a new client provides the leverage to mandate a new markup language as default. (There's nothing stopping me from serving HTML over Gemini-the-protocol, except the wrath of the community.)
All links, even to other hosts, will either conform to Gemini practice, or they'll have a different scheme, and thereby alert the user that they are entering somewhere else. Clients can help with this.
Lagrange, on skyjake.fi (a site which works in a similar way to this one)
Contrast this with some other options, like, domain name conventions (too easy to break) or serving Gemtext files over HTTP (you don't know what type you'll actually get until you've followed the link.)
But none of this actually requires a distinct protocol. Imagine I invented the Apollo protocol, which is actually identical to HTTP(S), but with the conventions that
Would this actually be any different in a practical sense? If you were in the know, you'd be able to access my Apollo server at http://drawk.cab:1968/ and get back whatever it was serving, which browsers would probably just render as text. But you don't have to tell people that. On the other hand, I can take advantage of the wider Web infrastructure to serve my content.
I'd say the potential audience for a system which guarantees lightweight and accessible pages, and can prioritize links to similar pages over links to other places on the internet, is actually larger than the audience for a new protocol.
(Would I allow Apollo to serve other content types, or should it switch to HTTP for those? Not sure.)
You might have noticed I didn't mention Gopher. Gopher is cranky and just as bad as the mid-90s Web, in terms of being a sane thing to want to use in the 2020s. Few people are running HTTP/0.9 servers for kicks.
As it happens, I started a mini-network of websites in the late 90's which had similar goals to the Gemini project. It was basically just a bunch of pages which didn't link outside the network, by mutual agreement. It didn't go anywhere, because the Web itself was pretty small at the time, and because, well, I was a student.