Gemini: The Misaligned Incentives
gerikson.com
gerikson.com
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?
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....
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.
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
Which is kind of the point of semantic markup: it is independent of presentation.
Thus demonstrating my point that the moment you go above a VT100 in presentation quality, your complexity goes exponential.
What you're raising as an objection is actually the entire point of my example.
And you are grossly underestimating the complexity of even an ASCII typesetting engine. RUNOFF/nroff/troff/ditroff/groff isn't even easy for a character device like a vt100. The developers of those engines reads like a who's who of computing luminaries.
My point as to why rewriting a web browser is hard is that you are developing a "typesetting engine", and developing a typesetting engine is HARD.
> 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.
> A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer.
This isn't a particularly appealing protocol characteristic to me, but YMMV.
> 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.
That... just does not make sense. I get that they admit that they do borrow heavily from Markdown, but there's no reason why they can't pick features from Markdown (including inline links and images), put them in their spec, and still call it "gemtext".
The real reason they don't do this is right there: they don't want to. They decided on a weak set of features, leaving out things that most people probably would find useful, and that's that.
I do understand the desire to limit features and extensibility, to avoid Gemini turning into the mess that is the current state of web standards, not to mention the attractiveness of being able to cut off ads and tracking by design. But I agree with OP that they're going about it in a way that all but guarantees they will not be particularly successful. Telling users they can't have inline links or images, and telling developers their creativity in implementation is severely limited isn't going to make you many friends.
And maybe that's also by design. If they want to recreate the internet of the 80s and early 90s, including the "feature" that a very tiny percentage of humanity was on it, maybe this really is the way to do it.
I wish them well, but I don't think this would be an ecosystem that would give me joy (no judgment, and I'm sure the Gemini folks don't care, and that's all fine).
I've been meaning to move to Foot, because it's apparently _even_ faster, but I haven't gotten around to it yet.
Also, how did you measure that? I'm interested to time Alacritty.
As long as you only implement the good features!
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.
full disclosure: I really like this protocol and have developed a full unicode client for esp32
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.
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.)
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".
How can there be talk of implementing anything in the spec, when the spec was designed with the explicit intent of never being updated?
Extra syntax to allow for italics and bold, much less any accessibility features, seem like new features.
/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.
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.
And unwrapped markdown in a line-wrapping text editor (most text editors support soft-wrapping) is perfectly readable even without rendering.
The style guides for many programming languages require you to put hard breaks in long lines, for example. Also, old-school mailing lists require this.
The place where it "makes sense" to have a line break in prose is a function of the reader's desired line width, which is not only unknown to the author at the time of writing, but also varies from reader to reader. If you don't insert semantically insignificant newline characters, any modern application for reading text can soft-wrap long lines to that width. But because arbitrarily inserting newline characters destroys information, the opposite isn't true. If you add \ns to break your lines at 80 characters and I try to read your text in a 60-character-wide terminal, I'll get alternating line widths of ~60 characters and ~20 characters. And I can't just replace all the newline characters at position ~80 with spaces and re-wrap the resulting text myself, because for all I know one of those line breaks could have been semantically significant.
Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. If you resize your browser window or zoom in or out so that the line wrapping in this comment occurs at different places in the text, the readability and meaning of this text is essentially unchanged. That's not generally true of code - even in languages whose compilers ignore whitespace, arbitrarily shifting, adding, and deleting line breaks doesn't preserve meaning (to humans) because programmers generally use whitespace methodically for the sake of clarity and readability.
What would be cool is a well-behaved autoformatter like Black, or perhaps gofmt or rustfmt (clang-format definitely fails since it's not even idempotent), which automatically reflows code to the width of your text editor (or even shrinks the indentation size) as you resize or split the window, and reformats it back to a standard width upon saving and committing. This requires that formatting to a different width then back to the original is a no-op, which I believe Black and rustfmt can achieve, but is harder to get right than storing the code as an AST on-disk. Also, rustfmt fails to reformat the interior of macro invocations.
But editing text in soft-wrapping editor is distracting (to me), as it continually re-wrap whole paragraph during editation. In hard-wrap text editor i can just edit paragraph and then press key for auto-wrapping.
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.
IT isn't HTML lite. It's text.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a
'The links are awkwardly placed, and the "placeholder" markers (such as numbers or brackets) to connect the text to the link below has not gelled to a standard.'
It's like hashtags in tweets - it'll eventually become some kind of community ad-hoc standard, that will be inferior to simple inline links. I guess it makes things harder to parse, so understand why they did it - but inline links is HTML's killer feature. The rest is fluff!
I've noticed that at least in the client I use (amfora) URI are not treated any differently from text and the client can insert a line break in the middle of them, making selecting the URI to paste it elsewhere hard.
This is not the client's fault btw, it's part of the spec. Anything not preceded by the magic characters '=>', '#', '`' or '>' is just treated literally.
> External links normally should not be placed in the body of an article. https://en.wikipedia.org/wiki/Wikipedia:External_links
I'll stick to gopher.
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
The incredible increase in the complexity of the modern internet has almost completely restored that fundamental distinction, if not made it deeper and wider, giving rise to publishers (e.g. Facebook, Twitter, YouTube, etc) and other media companies (e.g. Google) with powers we haven't seen for over a century, if ever.
Where does this idea come from?
One of my favorite manifestos was about the issue of [the non-existence of] spectrum scarcity, which also hashed out the threat posed by the reimposition of a strong publisher/consumer dichotomy. Alas, I haven't been able to find it again in the past several years.
These days whenever I come across a good article (my metric is an article I return to at least once, either to re-read or cite) I archive the link. Google is now useless for finding anything but the most recent content, and headed in that same direction when it comes to finding substantive content. Another object lesson in the perils of centralization and technological reliance.
> The first web browser - or browser-editor rather
> ...
https://worldwideweb.cern.ch/worldwideweb/
> Editing
> To edit any document, whether it's one you created, or a page on the world wide web:
> Click on the text you want edit.
> Edit it.
I disagree. I do _not_ equate a "publisher" with a "developer". I'd much rather see a world where publishers are _not_ developers. It's not like all the books I read are written by developers.
Of course, publishers are not actually the same as developers. Few Facebook engineers consider themselves publishers. Heck, Facebook doesn't consider itself a publisher--in the contemporary context a publisher would be a media platform (or "technology" platform). But it's publishers who pay developers, and it's often developers who seek to find themselves in the role of publisher, building their walled gardens, through their startups. Similarly, both publisher and developer are active roles, whereas user and consumer are passive--they exist as largely distinct roles with one primarily existing to enrich the other in exchange for entertainment.
The original promise was in many ways overly simplistic. For one thing, scientists (e.g. CERN scientists) were much better positioned to acquire and utilize certain technical skills as an ancillary part of their job. But the ultimate belief was that by eliding the distinction between publisher and consumer, the erstwhile consumers would be empowered and the erstwhile publishers disempowered. The concern was, as it remains today, about relative control over both the media and the message.
It many important ways it's still relatively simple as an absolute matter to throw up a simple HTML site. But the opportunity costs are different, and so we self-sort ourselves into traditional roles. In that way the original promise was even more naive in believing that roles wouldn't bifurcate in a manner similar to how they historically had been.
Also, suffice it to say that there are still huge markets where developers work building systems not directly related to publishing. But it's the publishers and their ecosystems that are driving most modern software systems, and they drive those systems in directions that are rarely well suited for the needs of everybody else. Rather, those systems are optimized for a network where media platforms push out highly sophisticated content and users are still largely passive consumers notwithstanding the interactive, social aspect.
There's no nuance here. You're defining "active" and "passive" as two sides of a binary; one can only be active or passive. See, in my daily life I do several things, like using running water, that I am only partially active in. I can choose when to run the water, but the infrastructure and construction of the apparatus under my control was built by someone other than me. So is this active or passive? Does my relationship to running water need to change if I'm happy with it? Why? Can we define "passive" in a philosophically consistent way?
> The original promise was in many ways overly simplistic. For one thing, scientists (e.g. CERN scientists) were much better positioned to acquire and utilize certain technical skills as an ancillary part of their job. But the ultimate belief was that by eliding the distinction between publisher and consumer, the erstwhile consumers would be empowered and the erstwhile publishers disempowered. The concern was, as it remains today, about relative control over both the media and the message.
I think this was one of many messages floating around on the early net and web, and you've made a nostalgia-oriented strawman around it. The ideology itself seems so simplistic as to not stand the test of a basic philosophy course. If people could be neatly slotted into "producers" and "consumers" the world would be a very easily legible place, but it's not.
> Rather, those systems are optimized for a network where media platforms push out highly sophisticated content and users are still largely passive consumers notwithstanding the interactive, social aspect.
Again what does it mean to be "active", what does it mean to be "passive", why is there a dichotomy, and why is it bad to be "passive"? The terms you use seem to have an implicit moral philosophy/valence to it, but I'm not sure why. Under what ethical framework is "passive" bad and "active" good? There's the reality of Gemini to confront as well that this world full of "active" people only produce canned, specific, largely similar content that is only read by other "active" people; the world of "passive" people outside publish and consume media much more diverse and rich on a multitude of platforms that are full of your "largely passive consumers".
To tie this back into the protocol itself, is Gemini then a form of religion or philosophy? Because much like people appreciate not being prosletyzed to by religious figures, people also appreciate not being prosletyzed about technical religion as well, and _no_ Gemini advocate ever mentions how there is mostly a religious belief underpinning Gemini rather than a practical one oriented around the goals in the top pages. (I say this as someone who has written apps and pages on Gemini.)
The Web really just does not have a user-oriented document format presently.
HTML5 via WATWG / Google / Facebook is advertiser friendly. The result is horrible both for anyone looking to independently implement a fully-compliant, capable Web browser AND any user actually accessing Today's-Web-As-Designed.
Gemini addresses the dev-unfriendliness ... bu still tosses out far too much functionality IMO in the name of simplicity. The basic semantics of HTML5 are actually reasonably sound, but without some external enforcement over styles and complexity, it's simply going to be abused. Having used tablets and e-readers principally for the past six years or so, I much prefer the presentation of, yes, PDF (generally, it's still possible to stuff those up entirely) to virtually anything rendered in HTML by a browser.
At a desktop system, console-mode simple markup remains reasonably readily consumed, and is quite useful for reference and incorporation into other works (writing / literature study).
I'm not entirely sure where the answer lies, but I don't think Gemini is the promised land.
Possibly a bondage-and-disciplin markup format, enforced by ... what exactly I don't know, though a defined set of document formats, and perhaps an independent search platform's ranking systems, might be one approach.
(Yes, addressing the issues of copyright, compensation, and authors integrity might also help, though at this point, stripping the Web of all advertising seems a good start.)
Regardless, I largely feel that constrained markup formats are where the effort to make the web both user and developer friendly again should lie. There is also another defunct format, the AMB [3] which is a very different approach, but its goals and assumptions are a little too far out from the expectations of modern users IMO.
[1]: https://en.wikipedia.org/wiki/EPUB
[2]: https://en.wikipedia.org/wiki/Wireless_Markup_Language
[3]: http://amb.osdn.io/
On physically-constrained devices (e.g., phones < 6" diagonal), it's about the only reader format that works at all. For larger devices, I strongly prefer a fixed-layout format such as PDF or DJVU.
Designers still foul up ePub far too often. The evolved typography of print took about 500 years to reach present development (though most of the modern elements were in place by the early 19th century). After a long enough period of getting things right, any change is most likely to be in the direction of Schlimbesserung: making things worse whilst attempting to improve them. This includes various font, point, and other stylistic choices. ePub affords too much freedom and authority to designers and not enough to readers.
On desktop platforms, there are few good ePub readers. fbreader on Linux is especially unpardonably poor. (I think Zathura may improve on this, if it does support ePub.)
And I think ePub still doesn't support formulae properly.
Thaks for the AMB and WML references, I'd not seen those yet. Oh ... WML -> WAP, right. I still think that the Web needs to be split up, probably along the lines I suggested some years ago:
- Documents
- Applications / Games
- Commerce / Finance
- Multimedia
https://old.reddit.com/r/dredmorbius/comments/256lxu/tabbed_...
These are ultimately different domains with different needs and uses. There's some call for complex and mixed formats .... but far less han their promotors would like us to believe. Advertising must die or be killed.
Interesting, I don't think I have a strong preference here. For textbooks I tend to prefer DJVU simply because of filesize, though DJVU readers aren't quite up to snuff in comparison to, say, evince (at least on nix, I'm not sure the state on non-nix).
> And I think ePub still doesn't support formulae properly.
Well, in theory, the latest versions of ePub have support for MathML. In practice... I don't know. I've tried to consume books with formulae on ePub and it's been a little nightmare.
> These are ultimately different domains with different needs and uses. There's some call for complex and mixed formats .... but far less han their promotors would like us to believe. Advertising must die or be killed.
There are promoters still? I would have been more sympathetic for mixed formats and flows when the web was younger, but these days, it feels obvious to me at least that the cases do have very different needs. Hell, every time I have to deal with a shadow DOM (which I don't have to do often, luckily) I regret the choices that ended up creating the concept of a shadow DOM in the first place.
Is your sub a place to discuss issues like this? I'd love to think/discuss these sorts of things in a thoughtful environment, and thanks for your exchange.
Thanks for the MathML reference.
The subreddit is effectively dead. Reddit is a hostile entity.
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?
> 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)
In addition to crafting a suggestive response that tacitly asks the reader to attribute two flawed arguments to me (re "design you find distasteful", and you're being "interested to hear" "who's tracking and got autoplaying video on their site"—two really obnoxious strawmen), you've used selective quoting of the linked FAQ to present a narrow target and paint a picture of a fundamental conflict between my remarks and the essence of Gemini. Extremely bold to do that while in the next breath having the confidence to offer an opinion about what is or is not a "fair take".
Gemini's proponents purport to be interested in a set of values. Proponents defend Gemini's design in terms of those values; the values form design constraints that inform all aspects of the project (including, for example, its markup format). Given that it is possible for Gemini residents to demonstrate a commitment to those values even with vanilla HTML and HTTP—because one is forcing anyone to make use of any of the Web technologies that Gemini omits—then we should expect them to do exactly that. The litmus test is to ask whether they do that, or whether they expect the downstream recipients of their own work to be comfortable compromising on those very same values when it comes to consuming media over the Web. This is the _entirety_ the argument I laid out before.
> you've used selective quoting of the linked FAQ to present a narrow target
If there's a part of the FAQ I've not quoted that commits Gemini's proponents to the value of making websites "look [...] like those found on cr.yp.to", please let me know.
That is: I don't think it's fair to argue from the idea of judging a "commitment to values" that aren't explicitly claimed by the project. That's not suggestion; I'm just saying it. If you can't be explicit about what's been committed to and how the commitment's been broken, then it's not me being "suggestive." If you do want to elaborate on that, I remain genuinely interested to hear it, because I still think it's possible you have stuff in mind that I don't know about. I broadly agree with you that it's fair to judge Gemini folks by their HTTP/S sites. However, for it to have anything to do with "how deep their convictions run", that judgment has to refer to their actual convictions, not just your preferences or mine.
> I remain genuinely interested to hear it, because I still think it's possible you have stuff in mind
I have no interest in corresponding with you further.
> I don't think it's fair to argue from the idea of judging a "commitment to values" that aren't explicitly claimed
(Odd position to take, given how many arguments you've tried to sneak into my mouth.)