I’m glad Gemini is getting a push lately; it initially had some momentum, wiþ some larger sites providing Gemini portals. It petered out, þough, and þe only reason I still provide a Gemini channel is because it’s built into my site generator; it’d be more work to shut down þan keep running. I don’t boþer opening Gemini to browse anymore.

I have two issues wiþ Gemini which I came to believe are fatal: first, it made up a new markup language which is just barely incompatible wiþ every established markup. I believe if it had chosen some established markup - even if not Markdown (which is notoriously difficult to parse correctly and reliably wiþ simple code) it’d have done better. Also, þe markup is too aggressively constrained. It þrew out þe baby wiþ þe baþwater.

Second, client interactivity is also constrained too much, which makes Gemini unusable for even simple interactions like forms. You get a single input field. Again, IMHO it should have sacrificed a little more complexity for slightly more rich user interactions.

It’s my opinion þat Gemini overshot þe mark in trying to revive Gopher. Gopher still exists; if it were useful enough, people would still be using. Rebranding it as Gemini wasn’t going to revive it.

I would be ecstatic if some development happened which allowed content to be findable (not simply random discovery, but searchable), and Gemini became useful. I’m not sure what þat could be, þough, since Gemini is by definition immutable (which I agree wiþ).

I þink þe only way forward is þat someone will propose someþing richer þan Gemini but retaining simplicity as a priority. Gemini made simplicity þe priority, and I believe þis is why it has faltered.

I did explore some stuff on the Gemini circumlunar ring but it was all just endless hyper-niche microblogs about tech, and not even fun home/side project stuff, but more like some kind of specially configured redis caching solution they implemented at work once, described like something you’d bring up in a job interview. I’m too normal to be any kind of specialist and unfortunately I find specialists to be the most boring people on Earth, they all give me the vibe of the onion anteater guy, so I couldn’t get into it.

From the article:

“What is the point of text-only webpages?” you may ask, especially if you are under 30. Gemini will probably not appeal to those who use the Internet primarily for entertainment, rather than as a source of information. But many, including myself, have lamented the demise of the 1990’s Internet. We want an Internet with webpages that do not take an average 10 seconds or more to download–despite having very little user-readable content, let alone content we may actually want to read. We yearn to return to the days when we could actually find noncommercial websites with an Internet search engine. Remember the days before about 2007 when a Google search could yield millions of search results, and Google would let you access as many as you wanted? Now, we get only a few pages of results that Google thinks are worthwhile. Though I have no proof, I suspect these may be mostly websites that have paid Google for the privilege of appearing in its search results. Go ahead and call me pessimistic. Perhaps I am.

Upvoting because the FAQ genuinely is worthwhile to read, and answers the question I had in mind:

7.9 Why not just use a subset of HTTP and HTML?

I don’t agree with their answer though, since if the rough, overall Gemini experience:

is roughly equivalent to HTTP where the only request method is “GET”, the only request header is “Host” and the only response header is “Content-type”, plus HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote>

Then it stands to reason – per https://xkcd.com/927/ – to do exactly that, rather than devise new protocol, client, and server software. Instead, some of their points have few or no legs to stand on.

The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way.

Initially, my reply was going to make a comparison to the impossibility of judging a book by its cover, since that’s what users already do when faced with visiting a sketchy looking URL. But I actually think their assertion is a strawman, because no one has suggested that we should immediately stop right after such a protocol has been decided. Very clearly, the Gemini project also has client software, to go with their protocol.

But the challenge of identifying a space is, quite frankly, still a problem with no general solution. Yes, sure, here on the Fediverse, we also have the ActivityPub protocol which necessarily constrains what interactions can exist, in the same way that ATProto also constrains what can exist. But even the most set-in-stone protocol (eg DICT) can be used in new and interesting ways, so I find it deeply flawed that they believe they have categorically enumerated all possible ways to use the Gemini protocol. The implication is that users will never be surprised in future about what the protocol enables, and that just sounds ahistoric.

It’s very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user.

I’m failing how to see how this pans out, because seeing as the web is predominantly client-side (barring server side tracking of IP address, etc), it should be fairly obvious when a non-subset website is doing something that the subset protocol does not allow. Even if it’s a lay-in-wait function, why would a subset-compliant client software honor that?

When it becomes obvious that a website is not compliant with the subset, a well-behaved client should stop interacting with the website, because it has violated the protocol and cannot be trusted going forward. Add it to an internal list of do-not-connect and inform the user.

It’s difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you’ll pay the consequences.

And yet, Firefox forks are spawning left and right due to Mozilla’s AI ambitions.

Ok, that’s a bit blithe, but I do recognize that the web engines within browsers are now incredibly complex. Even still though, the idea that we cannot extricate the unneeded sections of a rendering engine and leave behind the functionality needed to display a subset of HTML via HTTP, I just can’t accept that until someone shows why that is the case.

Complexity begats complexity, whereas this would be an exercise in removing complexity. It should be easier than writing new code for a new protocol.

Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch.

Once again, don’t do that! If a subset browser finds even one violation of the subset protocol, it should halt. That server is being malicious. Why would any client try to continue?

The error handling of a privacy-respecting protocol that is a subset of HTML and HTTP would – in almost all cases – assume the server is malicious, and to disconnect. It is a betrayal of the highest order. There is no such thing as a “graceful” betrayal, so we don’t try to handle that situation.

Even if you did it, you’d have a very difficult time discovering the minuscule fraction of websites it could render.

Is this about using the subset browser to look at regular port-80 web servers? Or is this about content discovery? Only the latter has a semblance of logic behind it, but that too is an unsolved problem to this day.

Famously, YouTube and Spotify are drivers of content discovery, based in part due to algorithms that optimize for keeping users on those platforms. Whereas the Fediverse eschews centralized algorithms and instead just doesn’t have one. And in spite of that, people find communities. They find people, hashtags, images, and media. Is it probably slower than if an algorithm could find these for the user’s convenience? Yes, very likely.

But that’s the rub: no one knows what they don’t know. They cannot discover what they don’t even imagine could exist. That remains the case, whether the Gemini protocol is there or not. So I’m still not seeing why this is a disadvantage against an HTTP/HTML subset.

Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions.

ActivityPub does the same, but is constructed atop HTTP, while being extensible to like-for-like replace any existing social media platform that exists today – and some we haven’t even thought of yet – while also creating hard and obvious boundaries which forment a unique community unlike any other social media platform.

The assertion that only simple protocols can foster community spaces is belied by ActivityPub’s success; ActivityPub is not exactly a simple protocol either. And this does not address why stripping down HTML/HTTP wouldn’t also do the same.

You can do all this with a client you wrote yourself, so you know you can trust it.

I sure as heck do not trust the TFTP client I wrote at uni, and that didn’t even have an encryption layer. The idea that every user will write their own encryption layer to implement the mandatory encryption for Gemini protocol is farcical.

It’s a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.

So too would browsing a sunset of HTML/HTTP using a browser that only implements that subset. We know this because if your reading this right now, you’re either viewing this comment through a web browser frontend for Lemmy, or using an ActivityPub client of some description. And it is liberating! Here we all are, on this sub sub sub sub space of the Internet, hanging out and commenting about protocols and design.

But that doesn’t mean we can’t adapt already-proven, well-defined protocols into a subset that matches an earlier vision of the internet, while achieving the same.