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.