The Mercury protocol

Lately I've been kind of second-guessing myself about various aspects of Gemini's design, particularly the stuff surrounding client certificates. I worry that maybe a lot of complicated stuff is making its way into the spec just for the sake of making clever use of technical possibilities, without clear motivations. Every now and then I get this fear that I've completely lost sight of the original ideal of keeping Gemini simple. So, thinking about the current specification, I've been asking myself "is there something more simple and elegant inside this, struggling to break out?". Here's one idea that's come out of this line of questioning.

Starting from Gemini as it's currently specced:

1. Get rid of TLS. The whole thing happens over plaintext, just like Gopher does. Serving sensitive content over the protocol is discouraged. Users who are concerned about their ISP snooping on or tampering with their browsing of non-sensitive content are encouraged to use the protocol over Tor, use a VPN, or ssh into their favourite pubnix and browse from there.

2. Requests don't change at all. Virtual hosting still works even without TLS SNI to provide the hostname, because the URL in the request also provides it.

3. Because TLS is gone, client certificates are gone, so status codes 21, 60, 62, 63, 64 and 65 are not needed, bringing us down to 14 status codes. If we de-emphasise the role of bots or sophisticated software, intead focusing entirely on human users, then a lot of distinctions made by the remaining codes (e.g. temporary vs permanent redirects or failures) become far less important, so we can get rid of more codes and end up below 10, allowing them to be single digits.

4. The `charset` parameter from the text/gemini MIME type is removed and UTF-8 encoding is obligatory. The `lang` parameter currently under discussion for Gemini is not added.

5. The text/gemini syntax is stripped back to just two line types: links, and plain text. Plain text lines are still wrapped by the client, as they currently are in Gemini.

All of the currently open questions about Gemini - handling client certificates, providing alt-text to pre-formatted text in a way which can't be abused to sneak in extension syntax, providing language metadata - go away in this hypothetical protocol. So, I consider this a finished specification, modulo perhaps some tiny boring details. This protocol is "complete", and is not obviously extensible.

I'm not saying this is what Gemini should be and we should forget about anything else. I'm just saying that this is, or could be, "a thing". This whole adventure started with me thinking of Gopher and the web as opposite extremes at either end of a "complexity axis" (well, not just complexity, but let's call it that for now), and wondering about what the possibilities were between those two endpoints. Obviously, there are arbitrarily many points on this axis, and no clear notion of which is "best".

The decision of where Gemini will fall on this axis is, according to the FAQ, supposed to come down maximising power to weight ratio whilst keeping weight "acceptable". This is, obviously, pretty subjective, which I'm perfectly okay with. But because it's such a tricky subjective decision, it's very useful to have clearly defined "navigational aids": concrete positions on the complexity axis we can easily refer to by name, which we can discuss and form consensus opinions on like "that one's way too complex", "that one's not powerful enough to be worth building", or "that one has serious privacy problems". Then we can think about where we want Gemini to be positioned, relative to those things.

To this end, I'm going to call the thing sketched above "the Mercury protocol". Yes, this breaks the original classic spacecraft naming analogy where Gopher is Mercury, but oh well, this is just a label. A label which allows us to pose questions like the following (wherein "Gemini" is understood to mean "Gemini as currently specced"):

How much more difficult is Gemini to implement than Mercury?

What are the things Gemini can do which Mercury cannot?

How much do we value those things?

Is the difference in implementation effort commensurate with the value of the extra abilities gained?

Is there anything Mercury can do which Gemini can't?

I'm going to be pondering these questions, and I invite you to do so as well! Some quick initial observations follow.

Taking the current Gemini spec document and removing all the parts that this proposal does away with, the resulting document is about 33% shorter, as measured by number of lines. Given that Gemini as currently specced still has the open questions mentioned above, which will inevitably require more detail in the spec, the final difference could be something like 50%, which is far from trivial. It's not so easy to quickly do a comparison for code, but all the experimental client certificate stuff in AV-98 is not trivial, and neither is the TOFU stuff. So there's a real difference in weight here. A good bit of the difference in spec weight comes from my wordy descriptions of optional line types and all the status codes, which don't necessarily have a matching implementation weight. TLS is driving the bulk of that.

If you're coming from a web-only background, Mercury might seem at first glance stripped back to the point of uselessness. But actually, it's either on equal footing with or clearly more powerful than Gopher in every respect I can think of. Literally everything that happens in Gopherspace could happen in a hypothetical Mercuryspace too. That might not be everything that anybody could ever want from the internet, but it's certainly not trivial, either. It's enough to build a vibrant community around.