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.
I've wanted to make something like this, and I'm happy to see its here because implementing a client looks like a lot of fun.
Here is why I want a simpler web: The NewYorkTimes wont be there! Neither will google or facebook or shopify or influencers or clickbait even! I want a web that is hard to make money from. Something that doesn't support fingerprinting and ad tracking, where my interests aren't at odds with the "platforms".
I want a place where people are posting ideas and creations and info and software and labors of love for free, with weird one-off communities that don't get embroiled in national censorship debates.
I might even want the relatively high barrier to entry, the fact that other people there would be looking for the same thing instead of being directed there by browser defaults and content portals.
I can tell you, from having been involved in a number of the discussions on the mailing list, that these points were definitely discussed. There were a number of people on your side. HTML subsets were discussed, as was using markdown (or a markdown subset). In the end a simple link syntax was chosen along with a few optional items. The simple link syntax is much more than a stripped down html 1.0... it is gopher but with a better syntax that is easier for non-developers to generate content with.
Gemini isn't perfect and is definitely a work in progress that serves a purpose and fits a niche. In my opinion it is geared more to converting people from gopher to gemini rather than from the web to gemini, though I hope we'll get some of both :)
Well it does. Extra characters in the HTTP spec end up getting sent trillions of times per year over the Internet costing real money in bandwidth in aggregate.
> 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.
With respect to the status codes, the original spec was worse (single digit response codes) than what exists now. I didn't agree with the original spec, so when I wrote my own Gemini server [1][2] I reused codes from HTTP. It was only after a drawn out discussion between myself and the original designer that a compromise was struck and we ended up with two digit response codes (and redirects---those weren't in the original spec either).
I still don't see why Gemini couldn't use a small subset of HTTP itself. HTTP is really great, just a little too complicated with all the extra RFC adding stuff to it (cookies, CORS)... if you ignore all that and remove a few of the fancy things in HTTP/1.1 (as defined in RFC-7230), like content-negotiation, you get pretty much what Gemini wants, no?
> Now I feel like I owe the world a subset of HTTP and HTML to put my money where my mouth is.
There are such subsets around: the one used by Texinfo's HTML export for portability [1] and by XMPP for XHTML-IM [2], the ones supported by simpler web browsers, the ones individual developers or projects stick to. An issue with that is the differences between those subsets (along with presence of multiple ones), although they seem to have quite a bit in common: attempted accessible websites tend to be usable in basic (or restricted) web browsers, possibly about as often as random/unrestricted websites are usable in major web browsers.
> But if you _do_ reuse connections, or use something like QUIC, then you can get better performance
I don't have opinions about the rest, but this is a good point.
With text-only I think one could easily slurp a whole Gemini site in one go. Although it could complicate the spec, specifying a way to download the whole site as a compressed archive could be nice. Clients could then offer an offline mode and it could help with mirroring sites.
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.