💾 Archived View for eph.smol.pub › re-solutionism captured on 2022-04-29 at 12:24:47. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
➡️ Next capture (2023-01-29)
-=-=-=-=-=-=-
Recently, an article was published and shared on Station about the Gemini protocol. I feel that this article warrants a response. You can read the original article by following the link below.
Gemini is Solutionism at its Worst
Because the author's katakana name transliterates as 'Marius', and I don't have a Japanese keyboard layout, I'm going to call the author Marius.
It all started with a simple post by someone on Superhighway84 who shared a link to their Gemini site. While I was interested to see what that person was writing about and working on, I couldn’t, because that person did not share a HTTP link, with the Gemini URL as an alternative to it. Instead, it was only a Gemini URL.
Marius seems to have a problem with the fact that Gemini is not built on HTTP or 'compatible' with HTTP, e.g.:
What Gemini is doing, is saying “we don’t need no videos, images, stylesheets, nor JavaScripts, because we want to have a lightweight web experience, so we throw all that crap out!”. Fine, sounds great. But why does it require a new protocol for that?
Why couldn’t one simply build on top of existing HTTP infrastructure, throw away all the baggage and instead implement a new Content-Type, which existing browsers then could parse?
Why not have a new protocol? HTTP is a mess, and it's more fun to do something different. Yes, you could build on top of HTTP for a more 'minimal web' experience — Marius did it on his website — but Gemini is not HTTP. Gemini is (by design) not extensible while HTTP is. There would be nothing stopping a hypothetical ♊/HTTP capsule from becoming out-of-spec precisely because HTTP is so extensible. Additionally, a hypothetical ♊/HTTP client would have to verify that a capsule is within the ♊/HTTP subset. That's dumb.
The question here shouldn’t be why not to use a subset of HTTP and HTML, but rather, why not build on top of HTTP with a different markup layer other than HTML.
Because HTTP is extensible and Gemini isn't! That's it, take it or leave it!
Existing infrastructure could have been extended to offer a more lightweight experience of the web that doesn’t come with JS, CSS or anything else.
So just HTML? You can already do that. If you're really adamant, use Dillo.
People then could decide whether they want to go the extra mile of installing Lagrange or any other dedicated Gemini browser, or simply have a browser extension that would take care of rendering the Content-Type properly.
Here's a HTTP-Gemini proxy; no programs needed.
It probably wouldn't be too hard to write a browser extension in the same vein as the Overbite Project, but for Gemini.
If you read the the Gemini project page, you'll note that Gemini does not try to replace the web. Marius seems to assume that this is not the case, as evidenced by the following:
Hence, Gemini’s argument of being “lighter than the web” doesn’t make that much of a difference at all from a protocol perspective, and it certainly does not justify completely replacing existing infrastructure and standards that humans have mutually agreed upon.
it would nevertheless be possible to bend existing HTTP servers to only include the bare minimum additional info in their response, that would still allow a modern browser to process the data.
That's not the point of Gemini! It's intended to be separate from existing web technologies as opposed to being built on top of them.
Gemtext is barely a "variant" of markdown, acting most often like a subset of markdown. I wrote this post in a markdown editor with no problem. Sure, Gemtext could be brought more in line with whatever 'standard' markdown is — but who cares? If Gemtext renders well-enough in most markdown parsers, why should it be brought 1000% into compliance for something its not?
Also, per the Gemini FAQ, you can serve Markdown over Gemini.
Gemini FAQ (relevant section 2.9)
It’s also not IPFS or ZeroNet. It’s not a blockchain. It’s not bittorrent.
Good. I don't want to use those protocols to read someone's blog, and I'm not vain enough to want my own writing to be appended to some immutable database or sent bouncing around a peer-to-peer network forever.
Marius is probably right here. I don't know enough about secure networking to comment on this. As for tracking, I'd ask why someone would want to put all of that together? Gemini isn't really conducive to commerce, and who the hell would want to buy that data?
I think the main thrust of Marius' essay is that Gemini is exclusive because web browsers can't handle the protocol yet. He's annoyed that there are people who aren't publishing their content via a protocol that his browser knows how to use.
Gopher is also a protocol that his browser probably doesn't understand. Unlike Gemini, Gopher has a heritage and no certificates. I guess you could argue that Gopher is just as exclusionary as Gemini. It's not built on HTTP, it could allow tracking with some backend server configuration, and isn't easily accessible from a modern web browser.
I think the point of Gemini is to make a space for people to publish what they want to say away from the mess that is the modern web. That's all. If you don't like it, feel free to ignore it. You could even pull a Stallman and refuse to read or access anything published over Gemini.
I do have a question: If whoever shared that Gemini link on Superhighway84 had instead shared a Gopher link, would you still be malding this much?