The author gives some opinions about the protocol, which represent his own personal point of view and you are free to agree or disagree with. He doesn't sound like a big fan, whatever.

But he also gives constructive criticism about the spec itself and how it could be improved at the end of the article, and I didn't see anyone react to that, although it find it quite valuable, especially given his expertise:

> 1. Split the spec into three separate ones: protocol, URL syntax, media type. Expand the protocol parts with more exact syntax descriptions and examples to supplement the English.

> 2. Clarify the client certificate use to be origin based, not host name.

> 3. Drop the TOFU idea, it makes for a too weak security story that does not scale and introduces massive complexities for clients.

> 4. Clarify the UTF-8 encoding requirement for URLs. It is confusing and possibly bringing in a lot of complexity. Simplify?

> 5. Clarify how proxying is actually supposed to work in regards to TLS and secure connections. Maybe drop the proxy idea completely to keep the simplicity.

> 6. Consider a way to re-use connections, even if that means introducing some kind of “chunks” HTTP-style.

1. Absolutely. Maybe the URL syntax can stay within the gemini spec, but he raises ambiguities and resolving them can only improve the spec. The gemtext specs however should be separated from the protocol. Those are very different things, the gemini protocol can and does serve any type of content, gemtext can be served through gemini or any other channel. I always found it odd that the gemtext specs are a section of a completely different thing.

2. Sounds fair enough, it's a minor change for most use cases.

3. Not too sure about the scaling part, he raises concerns for handling thousands of certs, I seriously doubt it would cause any pain at least a couple of orders of magnitude past that figure. However, I did have issues with TOFU with server certificates: Mozz (owner of the Astrobotany capsule, among other things) uses signed certificates and renews them periodically, which is probably good practice (at least, I've never seen anyone criticize this way of running his server). However, it teaches clients to accept new certificates if they want to access the capsule, which is a bad habit. Being one of the most used gemini capsule makes the issue worst. Now TOFU for client-generated certificates actually feels like a good choice to me, instead of relying on passwords (which are often bad (human-made) or rely on external software).

4. I don't see any objection about clarifying an ambiguity. Most implementations of the protocol seem to agree, so there is already a consensus about what it means.

5. I don't know enough to have an opinion about that.

6. I've seem many comments saying it's missing the point of gemini, as requests are usually few and spaced out, since each request are sent by user interaction and not cascaded when loading a document. But keep in mind you can serve HTML pages over gemini, or that people use bots that can have a much higher rate of sending out requests.

-- Response ended

-- Page fetched on Thu May 2 14:32:57 2024