Re: Why Gemini is not my favorite internet protocol

Gustaf Erikson wrote:

> First, there’s no official client. The fact that it’s so easy to implement a client means there’s a Cambrian explosion going on, and the filtering die-back has not yet occurred.

Huh? How is this a drawback? To me, this is a huge plus. Having just one client like SSB, or just a handful of servers like the, uh, “Mastodon protocol”, is not something to emulate.

> Second, the styling limitations [—] the lack of inline links […] leads to stilted, quasi-academic jargony text[.] I’m not going to abandon three decades of hypertext authoring habits to make a developer’s life slightly easier.

It’s not just developers. It can be nice to read a text that doesn’t have a bunch of links all over.

I have many bibles at home and some of them have just the plain text in a large readable font, and others have chapter- and verse-numbers all over the text like li’l ants made out of numbers. The readability difference is huge.

When I read capsules that embrace Gemini’s roots as basically a dirlisting that can have text blocks, I’m happy.

When I read capsules that clobber the text with asterisks or numbers for referencing links, I’m not. It’s the worst of both worlds. The constant interruption of the reading flow with “see here, see here, see here” exits, coupled with pseudomarkup that’s even more intrusive than a blue color or an underline. I’m like: “This author seems like they’d be much happier using HTML.”

I’ve previously said that with gemtext, we finally saw an inventor’s dream become an everyday actuality: people are finally publishing semantically marked up text, something that previously has just failed and failed and failed.

But… are they really? People are marking the text up with these superscripts or bracketed numbers or slashes or asterisks, with the defense of “That’s how we did it on Usenet and email back in the day”. Yes. That’s true. But that wasn’t necessarily a good thing for reability or usability.

So yes. I grant Erikson a huge point here, provided we look at how uglily gemtext is often used in the wild. Erikson vs Gemini: 1–1, so far.

> The solution to widespread tracking and user surveillance isn’t a bespoke hairshirt protocol that no-one is going to use. The solution is widespread legislation that makes using people’s personal data for targeted advertising illegal or very expensive.

I conceded the point of styling because of my own experience running into text that doesn’t embrace gemtext as a format, and here, the opposite happens. It’s because of my own experience of how it’s really stressful being on the web (in a way reading gem capsules isn’t) that I think this hairshirt solution actually was good.

Here is also why the proliferation of clients is a good thing. If I want to just grab some gemtext files with gmni and pop them into my notmuch index, I can. If I want to convert them to ebooks and read on e-ink, I can. It’s a scrapable and mashable format.

Point not granted. Erikson vs Gemini: 1–2.

> If you weren’t [on the pre-September internet], it might have seemed a paradise, but I was, and it wasn’t.

You’re right. Usenet was horrible, and while there are some gems in gemspace, I’m still waiting to discover truly precious treasures on here. Final score: 2–2.

That’s not even counting my own biggest complaint about Gemini, which, as I’ve mentioned before, is:

we were drowning

in specs

so we wrote

more specs

Follow-up

He wrote a follow-up.

Long-lines, a.k.a. gemtext is softwrapped

I agree. Not only with his point that this is frustrating to write (which is solved by programs like 7off or its more light-weight li’l sister, gmihw), it also introduces a way people can publish wrongbad gemtext (by uploading hardwrapped files).

In other words, for more robustness, hardwrapping (and clients needing to do reflow, like markdown) should’ve been the default. (Don’t change it now, obviously! Let gemtext be!)

If the client rewraps the file, then all files regardless of where they’re wrapped on the server will display the same. This increases robustness.

Point granted. Erikson vs Gemini: 3–2.

7off

gmihw

Inline markup

Already thoroughly discussed in the previous post. No new point granted. Almost wanna take one away.

Numbered lists

Reluctantly agree. Leads to the “1986. What a great season.” problem as noted by Gruber.

Header levels

Disagree. Completely arbitrary restriction.

Prioritizing client devs over users

I also disagree with Gemini’s goal of making client-writing “a weekend project”. Your users are gonna have to stick with that thing for a long time.

But what accidentally happened, which was a good thing, it turns out, is that this goal lead to the touchpoint, the interface, between writer and parser, server and client, to be simple.

Leading to fewer bugs and less errors.

Overall-score: 4–4.

My experience with Secure Scuttlebutt