Gemini: The Misaligned Incentives

https://gerikson.com/blog/comm/Gemini-misaligned-incentives.html

by todsacerdoti • 5 years ago

69 84 5 years ago

rektide• 5 years ago

none of these faults resonate with me. gemini feels like an http html lite, that exposes what is. that the author of this post wants more us fine. but we have html already for that. the idea of making visible making explicit the content, of not making it rich: it's simply andifferent philosophy than what this author seems to be seeking.

latch• 5 years ago

I tried to get into Gemini. I wrote a server in Elixir. Then I started to write content. The lack of inline links is a brutal and I'm pretty sure it'll keep Gemini from growing beyond anything but a curiosity.

IT isn't HTML lite. It's text.

csande17• 5 years ago

Personally, I could never use a platform that didn't support inline links[1]. Simply unthinkable! How could you possibly indicate which part of the text a link was related to?

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

TrevorFSmith• 5 years ago

In a world where only megacorps have the resources to fully implement web browsers and performant web servers, it is entirely reasonable for Gemini to lessen the complexity of development at the expense of features.

pkulak3• 5 years ago

There is a hell of a gulf between Chrome and a gemini client. OP just seems to be lamenting how wide it is. I like simple software, but not when it's too simple. I spend my whole life in a tiling window manager + terminal... but the whole "suckless" thing is too far for me. Gemini does seem a bit too far as well.

nathias5• 5 years ago

when it comes to terminals st (suckless terminal) is superior to anything in speed and features ... it really pays off to invest the time to set it up

selfhoster11• 5 years ago

The lack of features is a feature in itself, for some.

Karrot_Kream9• 5 years ago

You can dig a hole for planting a sapling with an excavator, with your hands, or with a shovel (and much more). Chrome chose the excavator, Gemini the hands. I'd rather have a shovel. This isn't a binary choice, there's a lot to explore here.

NoboruWataya• 5 years ago

It's all relative. Gemini was actually intended as the shovel, Gopher being the hands.

bullen• 5 years ago

To build a simple but performant HTTP/1.1 web server is not that hard: https://github.com/tinspin/rupy

As long as you only implement the good features!

kelnos4• 5 years ago

Sure, but those are two extremes. I can't believe that there isn't some middle ground (even if that "middle" is much closer to Gemini than the WWW) that continues to achieve Gemini's goals without sacrificing so much on both the user's and developer's sides.

tfehring3• 5 years ago

It's wild to me that so many technical people, including the author, consider arbitrarily inserting \ns at a certain character length a desirable feature. Adding semantically insignificant line breaks results in a loss of information - if you break lines at 80 characters, you can't distinguish between a semantically significant line break at character 80 vs. just running out of space in the line. It also imposes the writer's preferred character width on the reader: What if I want 132 characters? What if I have poor vision and/or a small monitor and can only fit 60 in my desired font size in the desired portion of my screen? And it necessitates weird rules and/or stricter line-length restrictions to deal with stuff like quoting, e.g. as described in https://useplaintext.email. So it sounds to me like Gemini got this one right, and if your text editor isn't smart enough to wrap lines when the input doesn't contain a literal \n you should probably find a better text editor.

/rant

In terms of the other limitations the author mentioned...yeah, those do seem kind of silly. I guess I don't see the advantage of a custom and even more limited format over, say, Markdown. But of course everyone has their own preferred subset of "important" features and if you just take the union of them all you'd wind up back at something close to the current feature set of the Web.

skybrian2• 5 years ago

In the case of Markdown, the extra newlines are there so that you can write for two different kinds of readers at the same time. A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable.

So the newlines aren’t “semantically insignificant” any more than comments are in source code. Just because they’re stripped during the conversion doesn’t mean they’re meaningless in the unconverted state.

nyanpasu642• 5 years ago

A text editor will show the unrendered state and a Markdown converter will take it to the rendered state. Both should be readable.

And unwrapped markdown in a line-wrapping text editor (most text editors support soft-wrapping) is perfectly readable even without rendering.

gerikson3• 5 years ago

Author here.

Treating a paragraph or block as a logical unit is what I am used to. It works in Markdown, HTML, Latex, and basically every word processor.

Treating a single line as a logical unit is just as valid, technically, but it imposes requirements on me, the author, to change my workflow. If I found Gemini more compelling that might be worth it, but as I'm sure you've all noticed, that is not the case.

tfehring3• 5 years ago

To clarify, I don't think of it as lines vs paragraphs. The text I'm typing right now doesn't contain any newline characters, but it's still a paragraph. I think of it more as a distinction between paragraphs with line-wrapping points predefined by the writer vs. paragraphs without them. Either way I'm very underwhelmed by Gemini myself so I don't blame you in the least for not wanting to change your workflow to accommodate it.

Karrot_Kream9• 5 years ago

I really don't like the popular concept in the Gemini project of conflating that developer-centric software is somehow _less evil_ than tech megacorps. Software can be user-hostile and be written by individuals, coops, collectives, or corporations. Software can be user-friendly and be written by individuals, coops, collectives, or corporations. Being anti-megacorp doesn't make your software friendly to use or more effective, nor does being pro-megacorp. Gemini is developer-centric and user-hostile while also being written by non-megacorp developers. That's all. Let's stop trying to use "anti-megacorp" to promote software that is developer-centric and user-hostile, when it is simply just developer-centric and user-hostile.

The proof is in the pudding. Most posts on Gemini are all about how awesome Gemini is and ascetic meditations on digital minimalism. Essentially, it's the bouncer at the "plain text cool kids club". I think many of us have an interest in creating non-megacorp-friendly software but the "plain text cool kids club" isn't it.

EDIT: This post has swung wildly in score so there's obviously some interesting thoughts happening here :D

fwip• 5 years ago

I think maybe your post is conflating "evil" and "user-hostile."

Karrot_Kream9• 5 years ago

No and that's the point. Gemini is developer-centric and user-hostile. It isn't evil. These are distinct concepts. We can't use good and evil as a way to exonerate bad software.

cxr3• 5 years ago

The proof is in the pudding

Indeed. For all of the cheerleaders that Gemini has, check how deep their convictions run. Here's an exercise: collect a smattering of names of those who champion Gemini the loudest, and then take a survey of their personal sites on the HTTP web. Do those pages look more like those found on cr.yp.to, or do they look more like the MySpacified web that they purport to be fed up with?

kixiQu5• 5 years ago

If you're looking for hypocrisy, the project FAQ (https://gemini.circumlunar.space/docs/faq.gmi) says it's supposed to be for people who are:

Opposed to the web's ubiquitous tracking of users
Tired of nagging pop-ups, obnoxious adverts, autoplaying videos and other misfeatures of the modern web

Mere design you find distasteful wouldn't really signify here. If you're talking about someone who's tracking and got autoplaying video on their site, I'm interested to hear who that'd be!

(For the record, I am not a champion of Gemini, and I like how MySpacey my personal site looks; I just don't think this is a fair take)

nathias5• 5 years ago

You are conflating ethics with convenience, user-friendliness has nothing to do with good/evil.

ronsor• 5 years ago

I personally don't understand why they just couldn't use markdown or simple HTML 3.2.

As an aside, there's honestly not even anything wrong with HTML 4.0 as a format. Up until the beginning of the 2010s, it was perfectly practical to create a third-party browser implementation supporting CSS 2 and HTML 4.

bsder3• 5 years ago

The problem is text rendering that exceeds what a VT100 can produce. As soon as you enter that realm, your browser complexity goes exponential.

dredmorbius6• 5 years ago

Semantic document structure need not have a fixed presentation.

Old-school UMIX manpages written in roff were most often displayed on VT-100 terminals, were designed to be compatible with teletypes, and yet could be printed pretty-formatted in variable-width fonts with true italic, bold, and point sizes.

You can still see this, e.g.:

  man -Tps clear | ps2pdf > clear.pdf

Open that and you'll find a fully typeset document.

Which is kind of the point of semantic markup: it is independent of presentation.

kixiQu5• 5 years ago

https://gemini.circumlunar.space/docs/faq.gmi

2.5 Why not just use a subset of HTTP and HTML?
[...]
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. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. 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. 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. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch.

I'd get a kick out of a markdown-web, personally.

Jtsummers2• 5 years ago

That's a fair argument for not saying, "We're going to make our servers only use a subset of HTTP and HTML." However, it neglected the potential to support a subset of HTML (or XHTML if they wanted to avoid the parsing complexity of HTML5) on Gemini itself.

kixiQu5• 5 years ago

Ah, but just for completeness, despite my own fondness for the idea of a markdown-web, their faq states:

2.9 Why didn't you just use Markdown instead of defining text/gemini?
The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini? Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages". Reasons not to go down this route include:
There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly.
The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original!
Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images.
A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs.
Of course, it is possible to serve Markdown over Gemini. The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it.

My experience of Gemini's "one link per line" deal has not suggested it leads to "extremely clear site designs", but I'm also not a Gopher person so maybe I'm missing The Paradigm.

snvzz• 5 years ago

It's essentially a poorly thought protocol, trying to leech on gopher's renewed popularity.

I'll stick to gopher.

thayne• 5 years ago

Gemini seems like a fine protocol for hobbiests, but it doesn't really seem suitable as a replacement for the http/html

emaro• 5 years ago

Is doesn't seek to be a replacement for anything at all.

tephra• 5 years ago

It isn't intended as one.

pkphilip• 5 years ago

Personally I think Gemini team's approach has been to throw out the baby with the bath water. This is really unfortunate because the world needs a system which allows for lightweight pages where the user has absolute control over what is fetched, what is sent etc.

dredmorbius6• 5 years ago

What ideas do you have on getting there from here?

The great bugbear of the Web has been enforcing standars-compliant markdown. We tried that. Authors didn't like it, and we got quirks modes with quirks on their modes' quirks' modes' modal quirkiness....

betwixthewires3• 5 years ago

I can get behind the long lines and lack of italics and bold (there is talk about implementing it in the spec, I hope it gets accepted) but the rest of it is just griping that Gemini isn't HTTP/HTML. I especially get on the case of people who want inline links because if you read the reasoning behind it it is exactly to not have the things the author of this article argues for in favor of them. It exists for a reduction of ambiguity.

krapp2• 5 years ago

there is talk about implementing it in the spec, I hope it gets accepted

How can there be talk of implementing anything in the spec, when the spec was designed with the explicit intent of never being updated?

betwixthewires3• 5 years ago

It was not designed with the explicit intent of never being updated, it was designed with the explicit intent of being complete one day soon. There will come a time when Gemini will be done, and even now any changes are taken very cautiously, but it is still in development.

gnuarch2• 5 years ago

No inline links encourages a more legible writing style. What if Wikipedia had external links all over?

External links normally should not be placed in the body of an article. https://en.wikipedia.org/wiki/Wikipedia:External_links

gliptic2• 5 years ago

What if Wikipedia had inline links all over? Oh wait, it does.

gnuarch2• 5 years ago

Following an inline link on Wikipedia I know what to expect, basically a definition of the linked concept. External links on the other hand I consider more like footnotes at the end of a book chapter or an article. Regarding inline links all over have a look at the 1999 website a-blast.org / assoziations-blaster.de

ddevault• 5 years ago

There is a key point which articles like this fail to understand about Gemini. Gemini draws our attention to the distribution of responsibilities between clients and publishers on the web, and the implications of that distribution, and asks us to question this balance in a new medium. On the web, the publisher is entirely responsible for both the content (HTML), layout (HTML+CSS), and its presentation (CSS). But with Gemini, the publisher supplies only the content, and the client (or rather, the user agent) deals with the layout and presentation. This allows for clients to work in a huge variety of situations different from yours - some people render gemsites for ereaders or for print, some people "render" them with TTS as homebrew podcasts to listen to on the train, and others rely on screen-readers to browse - and the constraints of Gemini provide all of them with a first-class experience that the web cannot.

This is why the markup format, gemtext, is heavily constrained. You should try to express yourself within the constraints of the medium. The medium I'm using now is constrained, too - I can't add inline images or links on Hacker News, but we all seem to have found productive uses for this site nonetheless. And would HN really be better if we could write arbitrary HTML/CSS/JS in our comment bodies?

__void• 5 years ago

Once again, in my view, the so called "limitations" exposed here (hyphen and "long-ass lines") are just problems of imperfect clients; while I can understand the long rant about lack of inline links and italics and bold, the analysis of how limited a developer is in "expressing his creativity" in my view shows that the author has not understood that gemini is *user/information first*, so these limitations are there to convey information with a low signal-to-noise ratio, any "embellishment" is useless and not recommended on gemini

gemini is designed in these ways to make the content consumable everywhere, separate from its representation

The idea is to be able to read text anywhere, from an arduino to a 64qbit Qwave sunBreaze, where "reading" also includes blind and deaf people (via text to speech), people who do not care about the possible "text justification mania" that the author seems to care a lot about

Finally, I think that gemini together with small companion protocols and file formats (e.g. amb[1], uxntal/subleq) are fully compatible with permacomputing concepts and this, in my naive but very tired view of the current state of the internet, is enough to understand what is good and what is bad.

[1] http://amb.osdn.io/

full disclosure: I really like this protocol and have developed a full unicode client for esp32

gerikson3• 5 years ago

Author here.

My partner is blind, I am well aware of the issues of accessibility online.

I strive to use best practices (like semantic markup) in the online content I produce.

I believe a balance can be struck between pleasing presentation for both sighted and blind readers.

Karrot_Kream9• 5 years ago

Finally, I think that gemini together with small companion protocols and file formats (e.g. amb[1], uxntal/subleq) are fully compatible with permacomputing concepts and this, in my naive but very tired view of the current state of the internet, is enough to understand what is good and what is bad.

In practice, where is any of this? Where's the screen reader support? How many blind and deaf people are using Gemini? This is like building a bike lane in a truck parking lot; it makes me doubt anyone will use it and makes me think that it's air cover for the truck parking lot folks to make their parking lot seem more accessible than it actually is.

What is "permacomputing"? It's not listed in any of the goals of the Gemini project. And why do we need amb or uxntal/subleq architectures? Is there a rational chain of thought here that justifies these ideas which doesn't depend on moral philosophy?

(Note that that's my other problem with Gemini. There's a lot of talk of good, evil, producers, consumers, publishers, and all, but the terms are poorly defined and the motivations hand-wavily justified. None of the actual motivational documents regarding the protocol bring these up either, they are just brought up in discussion _around_ Gemini, which is frustrating because it feels like there's a mismatch between the advertised uses of Gemini (and why a user would care) and the concerns of actual Gemini users.)

kelnos4• 5 years ago

gemini is user/information first

It's hard to take that seriously given the limitations of gemtext. A lack of inline links and images, and basic formatting, is the opposite of "user first".

tpoacher• 5 years ago

Personally I'm glad the author doesn't like Gemini, because all the stuff he dislikes about it seem to be stuff I actually like, and if he had his way with Gemini there would be all sorts of stuff he seems to like and I dislike.

Gemini: The Misaligned Incentives

Related Stories