Missing The Point

Daniel Stenberg (cURL author) wrote a critique of the gemini specification.

Stenberg's post.
thrig.me wrote a spirited defense of gemini.

It is interesting to follow this conversation on the two mediums. For example, here an excerpt from the top comment on Hacker News:

I think Gemini proponents who think Daniel is missing the point [...] are the ones missing the point.

I humbly submit that it's a bit of both. There are some clear signs that Daniel doesn't get how gemini is intended to be used, or used in practice, like this gem:

Serving an average HTML page using a number of linked resources/images over this protocol is going to be significantly slower than with HTTP/1.1 or later.

Gemtext does not support CSS, JS, or inline images. Daniel does note similarities to gopher elsewhere (deridingly), but doesn't put 2 and 2 together here. Yes, gemini defines a very poor transport for the modern (large) web, *yawn*. But for gemtext documents the way the protocol is actually used (and in fact specified in the doc he read), gemini pages consistently load much, much faster than web pages in practice.

Or similarly, his observation that gemini is "GET-only". I did actually laugh out loud at that one.

I wish that he had successfully put himself in the headspace of "this came later than HTTP and HTML, look for the purpose behind apparent backward steps."

Yet at the same time there are valuable points that Daniel is in a unique position to make, and the gemini community should take those seriously. His post ends with 6 change recommendations, and they are worthy of discussion.

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.

By my count:

Kneejerk defensiveness is just going to prevent us from learning what we can, even from imperfect sources.

~tjp

---

Home