Gemini – A new, collaboratively designed internet protocol

I'm acquainted with some of the folks involved in this project, and it's been a privilege to see them bring the concept so much to life in such a short span of time. For those who share an active interest in alternatives to the farrago that the modern web has become, I can unreservedly recommend Gemini to your attention.

I installed `elpher` via emacs and then didn't know where to go to actually see any content. Eventually I followed a link from "The Elpher Project Page" - it linked to "Project Gemini (hosted using gemini)". From there I found something called CAPCOM and am having fun exploring... but my suggestion is "list some gemini content on the gemini site!"

(Update: oh dear, I've never played with Gopher before. This is my kind of internet! There goes the rest of my day...)

There is the Castor[1] GUI client, which ends up being a bit nicer to use. But the protocol draws heavily from Gopher so text-based clients are the default.

[1] https://sr.ht/~julienxx/Castor/

I see that they've specified both a transport protocol, to replace HTTPS, and a document format, to replace HTML.

BLUF: They should have just run the text/gemini format on top of HTTPS 1.1, make a gemini --> HTML formatter, and maybe a restricted subset of HTTPS, and called it a day. Replacing HTTPS is a waste of time. Also, most of the benefits of the document format could be gotten with a sane subset of HTML. There are no mandatory bad parts to HTTP or HTML.

I've seen this "The Web is too complex, we need Gopher" sentiment on the Fediverse a few times and it looks like the same class of thinking as "C++ / Rust is too complex, we need C."

They are complaining about how _bad_ parties use HTTP and HTML and concluding that _good_ people should disavow HTTP and HTML as a result. It is like refusing to drive your pickup truck because someone else's truck has truck nuts on it.

But I've run websites with the "Motherfucking website" HTML style and it's fine.

All the complexity of the web is opt-in. Switching my site to Gemini wouldn't prevent, say, the New York Times from wanting a complex HTML website. All I'm doing is shooting myself in the foot to spite my enemy. The FAQ says they intend to co-exist with the web, so I'm sure they agree with me on this. They just want to lead by example. I also don't think it's a good example.

About extensibility, from Section 2.1.2 in the FAQ:

"Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol."

These claims are made:

- Privacy violations are inherent to HTTP/HTTPS/HTML - Making a protocol non-extensible is feasible

But if you're specifying a completely new client and server, you could also just refuse to send and accept the ETag and cookie headers that are known to allow privacy violation.

And no protocol is non-extensible. They seem to think that software and ideas are controlled and owned by the first people to think of them. But if Gemini catches on, then it can be forked. This should be obvious to people working in FLOSS. I seem to recall it happened to IRC. Designed simple, forked into incompatible competing versions, the official next version is in dev hell, and now it's also competing with XMPP and Matrix.

Perhaps that belief is why they chose to make a new spec instead of defining a subset of HTTP and HTML. They think that HTTP and HTML are atomic and we must not reuse any good ideas from them, they've been tainted with bad ideas, so we have to change everything all at once.

To this end they even made the status codes different from HTTP.

"Importantly, the first digit of Gemini status codes do not group codes into vague categories like "client error" and "server error" as per HTTP. Instead, the first digit alone provides enough information for a client to determine how to handle the response."

They could have just specified a subset of HTTP status codes, to make it easier to remember which codes are which. Personally I like having 4xx and 5xx separate. Maybe they were really happy to save 33% of status code bytes compared to HTTP.

Regarding performance, the spec says, "Connections are closed at the end of a single transaction and cannot be reused."

I believe there's also no inline media, so 1 document == 1 connection == 1 request.

Again, this is completely possible with a sane subset of HTML and HTTP - Just write a server that can't reuse connections, and write HTML that doesn't have inline media. Use a linter or transpiler (from text/gemini to HTML) to enforce that.

But if you _do_ reuse connections, or use something like QUIC, then you can get better performance. So they are making that impossible. Again, until someone forks it and adds it anyway.

I feel like I'm the crazy one because there's clearly a few people working on this project seriously, and I'm one person writing a rambling comment. But I don't see the point. Now I feel like I owe the world a subset of HTTP and HTML to put my money where my mouth is.

> They are complaining about how _bad_ parties use HTTP and HTML and concluding that _good_ people should disavow HTTP and HTML as a result.

A protocol that can be easily abused is perhaps not a good protocol.

A verbose markup language with loads of historical baggage, inconsistent implementations (much better these days), and whose spec is half-baked and incomplete at best, is perhaps not a good markup language.