I really like the idea of having a more bare-bones text-only web, but I can't get onboard with Gemini until it offers the same support for screenreaders as HTML. (For example, an equivalent of span lang=XX tags is missing, so if you quote a foreign-language word(s) in your text, you can't let screenreaders know what language to read it in). The visually impaired should not be second-class citizens in any new internet community.
Multilingual accessibility seems to be a niche within a niche. I'm bilingual but I seldom read mixed-language content. And even when I do I wonder how often the author can/bothers to include the markup for it.
If I write "ceci n'est pas du français" here for instance it'll remain untagged.
I think the only websites where you can reliably expect the text to be tagged correctly are dictionaries and the like, where it can be done unambiguously and at scale (wiktionary seems to do it for instance: https://en.wiktionary.org/wiki/coin ). In these case it seems like it could genuinely be useful.
I've also looked at a few language learning apps (such as Duolingo) and none of them appear to use the lang attribute at all, even though it seems like it would be a perfect use case for it.
I guess my point is that I'm not sure it's fair to blame a format that strives to be minimalist for having such a shortcoming for lacking such a very specific feature.
Of course if you're a blind linguist you might have a very different opinion on the subject...
Just to be really clear here - accessibility isnt a "niche". People being able to use software (which presumably is what gemini is about??) is important for everyone, obviously.
Imagine saying accessability hardware - like corrective lenses - is niche.
By "niche" here, we mean affecting very few people, I think?
Then "accessiblity" in general is not niche, it effects everyone or almost everyone.
But "accessibilty" is a broad concept, applying to all sorts of different unrelated needs. Vision impairment, cognitive differences, mobility needs, etc.
Some of them effect more people than others. Some of them will be "niche", effecting few people. it is just a fact, right? It is faulty logic to say that because "accessibility" effects everyone, every single accessibility accomodation is also therefore of use to everyone. It's not so.
How much need is there for multi-lingual screen-reading? I have no idea. It's obviously not universal -- I don't need it for instance, although I may need other kinds of accessibility attention -- but there may be lots of need for it! But we can't prove it one way or another just from language games around the general concept of "accessiblity".
Whether developers ought to accomodate even niche accessibility needs is a separate ethical or practical argument.
> By "niche" here, we mean affecting very few people, I think?
A text only web is pretty niche. Can this project really afford to start slicing off additional portions of its userbase? I agree that multilingual blind users are in the minority, but those users are probably the most likely of anyone to be interested in a text-only web.
And even ignoring blind users, it's just... what's the point of any of this if Gemini is not going to be semantic? It's like religiously adhering to the GNU principles of always printing human-readable text on the command line, and then not shipping a shell with a pipe command or any text parsing capabilities. From just about any perspective, whether you're worried about accessibility, or parsing, or search -- it's useful to know what language a document/section is in.
One of the few advantages of having a limited, well-defined, non-extensible spec is that it's easy to work with and write parsers around. And immediately Gemini is just saying, "filtering sections by language? Good text-to-speech support? No need for that."
If nothing else, Gemini is theoretically built specifically for generality[0], and it's already guaranteeing out of the box that it can't be used well with voice assistants. Those things aren't a fad, a general-purpose document format kind of needs to support them. And trying to have a voice assistant that intuits the current language is just a really bad system for everyone.
One of Gemini's explicit goals is for client implementation to be so simple as to be a weekend project for the average developer.
That's one reason inline links are not allowed (they have to be a separate line): it would complicate the parser.
It shouldn't be too hard to add a "language switch" line, so that sections (but not words within sections) can be different languages.
Making Wiktionary or Etymonline in Gemini would require you to add a line break for each foreign word, which seems annoying to read.
I don't see though, why the spec can't allow links that are written on a newline for markup simplicity but displayed inline? And then the same could be done for foreign words.
You could still do multi-lingual content just by having it in separate .gmi pages and then linking between then. And your screenreader could follow links by embedding the text in the other language in the first page.
I agree with you that those behind Gemini should take this issue seriously, but maybe something like what I've mentioned is what they have in mind as their answer. Not sure.
it would be nice to have more accesible interfaces for everyone. helping one person doesn't mean you fail to help everyone, in fact, helping one person in terms of accessibility generally has the effect of helping everyone.
we're asking for some access. not all the access. scoped properly, it doesn't seem to be that insurmountable of a development goal, honestly.
> in fact, helping one person in terms of accessibility generally has the effect of helping everyone.
How does facilitating multilingual screen-reading help someone who is neither multilingual nor uses a screen-reader? How can it possibly help everyone? (like literally 100% of people, you are suggesting?) What am I missing?
- better client displays (allowing a user client to switch out fonts based on the language, for example)
- better support for users who are not multi-lingual (a client could try to auto-translate sections that are not in the user's native language)
- better search capabilities (find me all documents that contain a French passage)
- better voice-assistant support (if a document is being read out loud for any reason, it would be nice to be able to handle multiple languages well. This also combines with the auto-translate capabilities above.)
Basically, all of the reasons why Gemini includes a "lang" attribute in the first place, except recognizing that parsers and clients want to be able to make use of that on a section-by-section basis rather than purely at the document level.
Sometimes documents are big and expand across multiple languages. It's just a bad abstraction in general to assume that each document would only have one language type[0]. Documents/books in the real world don't work that way, and a document format that can't accurately represent a giant portion of classic literature isn't a very good general-purpose format.
[0]: yes, technically Gemini allows you to specify multiple top-level languages, but that's not useful for anything. If I'm parsing a document, I don't want it to tell me "hey, there's some French in here somewhere, good luck!" Tell me where it is.
I'm not necessarily a fan of your tone, seems pretty shrill.
But at Apple we were well aware that accessibility features like closed captions were often used by people with no disabilities. We would add stuff knowing that all sorts of people would find uses for it.
I can easily imagine a language tag would also be useful for filtering out a German-language gemini for instance.
This was a double edged sword however. Like with closed captions/subtitles, we knew that many people using them that had hearing issues were older and also likely had out of date glasses prescriptions.
But this didn't stop the AppleTV designers from lowering the contrast of the font by displaying it over a transparent background, lowering the font size, using Helvetica instead of an accessible font, and removing the positional text feature that indicated who was speaking. And in typical Apple style, there was no option to make the text more legible.
All of these choices were made to appease people without disability who were using the feature for whatever reason. I didn't like it.
So I guess what I'm saying is, accessibility features are good for all sorts of reasons but don't lose sight of the much, much smaller group of users who require the feature in order to use the product at all.
> I'm not necessarily a fan of your tone, seems pretty shrill.
I think it is important to be honest and upfront when we talk about accessability in software because I've seen so many times when developers and product owners dismiss it entirely. I really want to stress the point that thinking about accessebility as a niche is exclusionary and unethical.
I think about my time working at Net a Porter - UK upmarket online fashion retailer - where I brought up some accessability concerns especially around their terrible in-house captcha and it was dismissed as "they arent our target market" which is so blanetly untrue, but all stems from this myth that accessability is only for a small group of users.
> don't lose sight of the much, much smaller group of users who require the feature in order to use the product at all.
The people who need to use captions/subtitles are not a "much smaller group". I think about foreign language media, where i need the subtitles (like when I watched Dark on Netflix), or even primarily English media but has some forign language (I watched Lost recently - there's a fair bit of Korean and Arabic in that). Or even when you're watching TV around someone who's sleeping.
Everyone needs "accessability", and if you don't now, you will eventually.
I specifically responded to the "niche within a niche" comment, which I interpreted as referring to multi-lingual documentments as a niche within the niche of "accessibility" in general.
Also, accessibility numbers are almost always measured very low because people who need those affordances aren't even attempting to use it, since so much software ignores it. Years ago when browsers let you lock font sizes, I heard many times from both designers and usability "experts" alike, "well, it's not a big deal nobody ever changes the font anyways", not realizing their own self-fulfilling prophecies.
I've always loved that the Kindle, even with such a simple use case as reading a book, supports so many ways to see it and interact with it, so even people without vision or motor problems can use it the way they like best.
A quick internet search tells me that between 50 and 74% of adults (depending on the source) need some for of vision correction. That's very much not niche. Also it's a pretty bad example because very rarely do you need to worry about "corrective lense accessibility", except maybe for things like VR helmets.
A better example would be things like wheelchair accessibility for instance, which is indeed very much not implemented everywhere.
To be clear I'm not saying that it's a bad idea to implement accessibility features, It's actually quite commendable. I just feel like in practice it's a lot of additional work to get it right and even then it may not do much good at all. Again, while the "lang" attribute is technically supported by HTML, I struggle to find places where it's used in the wild, even in places where it doesn't seem like it would be technically difficult to do it (like dictionaries and language learning websites).
If I was a gemini developer I'd definitely listen when people complain about bad accessibility, but I would also take the time to understand how people deal with things like multilingual content in practice and how to make it easier, because clearly at the moment "lang=" is not it.
> A quick internet search tells me that between 50 and 74% of adults (depending on the source) need some for of vision correction. That's very much not niche.
That's my point :)
> Also it's a pretty bad example because very rarely do you need to worry about "corrective lense accessibility", except maybe for things like VR helmets.
Ahh, but what corrective lesnses points to is degregation in eyesight. So ways to make viewing/experiencing content _without_ glasses is definitely a concern to between 50%-70% of adults.
On the other hand, my parents have the font size turned up on their phones because their eyesight degraded with time. I imagine, within time, my eyes will fail more and that'll be me.
Fair in general, but for this example accessible writing is maybe more the issue - whoever made the content should avoid mixing languages if they want to be accessible.
> but I can't get onboard with Gemini until it offers the same support for screenreaders as HTML. (For example, an equivalent of span lang=XX tags is missing, so if you quote a foreign-language word(s) in your text, you can't let screenreaders know what language to read it in).
The problem with this you'll get a million other people saying "Gemini is a really good simple format that the internet needs, but you need to just add feature X". But if Gemini added all those features, it would become as bloated as HTML/CSS/JS!
Gemini is to a large degree a reaction to the commercialization of the web, all that huge load of Javascript etc. arose through the ad economy. Accessibility isn't that, accessibility is something that people trying to do business would prefer to avoid. But letting the disabled be first-class citizens in an online community alongside the rest of the population is a matter of justice. Adding accessibility features isn’t making a standard "bloated", it is simply doing the right thing.
> Adding accessibility features isn’t making a standard "bloated", it is simply doing the right thing.
Yes, and the other million people are going to say their proposed features are "simply doing the right thing".
It may be that marking up what language a short except of text is in is a good feature to have (and would be fairly easy to achieve if Gemini used the Markdown format as you could simply us a <span> tag). A counterargument would be that traditional text doesn't do this, so a text file format ought not to unless it is aiming at being something more than what text does.
But add too many features, the project becomes something else, is maybe less useful & doesn't gain traction. A Gemini project that is too bloated and thus gains no traction helps no-one, disabled or otherwise.
> so a text file format ought not to unless it is aiming at being something more than what text does.
Gemini does aim at being more than text[0]:
> The "first class" application of Gemini is human consumption of predominantly written material - to facilitate something like gopherspace, or like "reasonable webspace" (e.g. something which is comfortably usable in Lynx or Dillo). But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above. This means taking into account possible applications built around non-text files and non-human clients.
Lots of documents and books contain passages in other languages, it's reasonably common -- I don't get why people are saying this is a niche concern. Books get around that problem because they have controls around presentation, and they're not designed to be consumed visually, not as a semantic, parseable format. But Gemini, at least in theory, is designed to be parseable.
If you surveyed people on what features were missing from Gemini and got 10,000 responses how many people do you think would mention "semantic tags for when the language switches mid document" and at what priority when mentioned? Now the same for the top item on the list? Now pick 5 random responses only mentioned once, do you think there is one that could theoretically be used by a large percentage of the population if implemented but even if you had thrown it in the survey itself but still wouldn't have been selected by many people or as a high priority?
I.e. it's not enough for something to be possibly usable by a large portion of people - the userbase have to actually be interested in utilizing it and consider it more important than other things instead. I strongly think if you follow this logic you'll find it's a very niche group that cares this deeply about the semantic language tags. Maybe you truly strongly don't and consider it something everyone would love if only it was there.
That is a really good point, and a really good way of phrasing that point, but I still have two semi-objections.
First, I do think this kind of thing falls into a category of... maybe 'polish', for lack of a better word?
This is something that you're not going to notice you're missing until you think "I want to write one of these quick and dirty display clients that I've been encouraged to build over the weekend, and wow, embedded Japanese is just literally impossible to render well." If you have a document format that's designed to be adaptable and flexible, predicting what you're going to need is difficult.
So maybe the idea is that you're not going to throw transcriptions for comics/manga into this, and nobody would need to search documents for embedded passages in other languages, and stuff like auto-translations in a client wouldn't be useful. But to me it kind of just smacks of, "this is designed for the use cases we could think of right now." I don't know what features will be critically important until I try to do something creative, that's why I value a tightly constrained format that's simple to understand but still offers at least some flexibility.
The other objection that keeps coming up in my mind is: is Gemini actually swamped for feature requests right now? Are they being forced to prioritize features? I'll definitely concede that if you surveyed 10,000 people using Gemini, stuff like a hard limit of 2 subheaders is very likely annoying more people right now than anything to do with language types. But Gemini also doesn't look like it's trying to fix its subheader limit. The impression I get from the FAQ is that this is not a spec that's actively evolving much right now.
And that kind of loops me back around to thinking about polish again. On one hand, I'm inclined to think you're right, this is probably not the first thing on anyone's mind. But on the other hand, "a document with multiple languages in it" is a reasonably common thing that will show up in multiple settings. So I'm still looking at a text format that even just on the surface level doesn't seem to be very good at describing text, even in cases where the solutions seem pretty simple. Having a language switch tag in the spec or just allowing multiple top-level media types in the document doesn't seem like it would complicate the parser spec or make it any harder for me to build a client.
Part of this is, if I'm going to adopt a format, I want it to be well thought out -- I want the authors to have spent more time thinking about it than I have. So if I can immediately see problems before I even start using the spec, it makes me wonder what else I'm going to run into where I'll just be scratching my head over why it was designed that way.
On some level I get where you're coming from, and rendering multiple languages is not the end of the world. You can even potentially work around it, maybe. But it would also be very, very easy to get this right, and I don't understand why the first thought from a spec designer putting together a content type header wouldn't be "what if the content type changes mid-document". This is maybe unfair, but the immediate thing that it makes me think is, "these are people who have not spent much time considering how text documents work, even for simple cases."
But if Gemini was in heavy active development, my opinion would probably be different. I don't know, maybe it is? Are they actively evolving the spec right now? Maybe I'm just being over-critical. But I feel like I shouldn't be able to immediately think of use cases involving basic text that Gemini just can't handle, it should take me longer to see the limitations of a general-purpose text format.
> Lots of documents and books contain passages in other languages, it's reasonably common
Yes they do, and since Gemini allows Unicode, it can cope with this. Note that books typically don't mark what language foreign words/phrases are in.
> But Gemini, at least in theory, is designed to be parseable.
If I was designing Gemini I'd design the source format as something very like Markdown and have it compile to a format which would be a subset of HTML. This would allow <span lang=...> constructs.
> A counterargument would be that traditional text doesn't do this, so a text file format ought not to unless it is aiming at being something more than what text does.
Other text-centric media often emphasize foreign words in some fashion. For instance, in an English language novel foreign language text is often italicized. Same in many articles.
Really feel you're on the wrong side of this one. It's not the same at all in my book. Especially if, as the author of the blog claims, it will never be able to be changed.
The lang attribute is also required for embedding Simplified Chinese/Traditional Chinese/Japanese/Korean text in a document containing two or more of those.
There are differences in the display (font) of the same Unicode character.
As a screen reader user, automatic language switching is the first thing I disable. A lot of HTML templates just include 'lang="en"', and developers rarely notice that, even if their website is in another language.
I find Gemini pretty accessible overall. There are no images, so including alt descriptions isn't even a concern. There's no CSS, so you can't make controls that visually look like check boxes, but are much less accessible. In fact, it's way harder to make an inaccessible Gemini site than to make an inaccessible website. The only gripe I have is the possibility to introduce ASCII diagrams, which usually aren't accessible.
> I find Gemini pretty accessible overall. There are no images, so including alt descriptions isn't even a concern. There's no CSS, so you can't make controls that visually look like check boxes, but are much less accessible. In fact, it's way harder to make an inaccessible Gemini site than to make an inaccessible website. The only gripe I have is the possibility to introduce ASCII diagrams, which usually aren't accessible.
The provides an alt text tag to preformatted text blocks for this purpose:
> Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine.
> The only gripe I have is the possibility to introduce ASCII diagrams, which usually aren't accessible.
CAD software exports .stl files which can be processed into instructions for machines. That is, there is already software that can take lines on a screen and convert it to instructions for a machine. There's probably a way to annotate ASCII images of drawings (schematics, architectural) and output text "text* drawing of an object 14 centimeters by 5 centimeters, ..." Stuff like vinyl cutters (and even the proprietary cricut) can take vector graphics and convert them to instructions for a machine. so it, in theory, might be possible to just paste the ascii drawing text into some software: render ascii as .svg/vector, convert to 2d stl ("a layer"), convert stl to descriptive text. Since the software renders, you don't need OCR for the annotations, which are mostly instructions.
if there's no annotation, assume the '-', '_', '|', etc are to scale, and just use "units" as the dimensions instead of centimeters or whatever. |----| = 'two verticals separated with a 4 unit line'
I would argue that that complexity should be handled by the screenreader through heuristics rather than the .gemini format itself, based on the desire to keep basic clients very simple (~100 loc). But that’s a really good point!
Heuristics might work for longer text where the sample is large enough to uniquely identify the language, but for single words there is not enough information. If I write "coin" in my text, for example, am I using an English word, French word, or Irish word? The pronunciation varies drastically, and screenreaders have to know what to say.
My go to anecdote on this is when I returned to Switzerland after several years in the US and walked by a bakery displaying a sign advertising a "Pain Surprise".
If anybody ever opens an S&M themed bakery, the problem will be accentuated.
Not strictly S&M :) but fresh out of the oven Sangak bread of Iran can offer a "pain surprise" followed by culinary pleasure! Picking those hot pebbles off the back of the flatbread on the way home in the morning is a cherished memory of my childhood in Iran.
My vision is good and I also don't know if the word you quoted was supposed to be in English, French of Irish? The point being, a screen reader has no more or less information than a human reader.
It might be better then to invest effort in improving language inference heuristics, which would help in all applications (pdf documents, text files) than to try to build in support in each underlying protocol.
But the screen reader needs to say the word, and the pronounciation of "coin" isn't the same in every language. I don't know about Irish, but it's radically different between French and English, the only sound in common is the "k".
This means that if the screenreader picks the wrong language, then the user has to guess the spelling from the way it's pronounced to understand the text.
Though I'll concede that right now on the web it isn't much better; but that's a failing of publishing tools, not the format.
> a screen reader has no more or less information than a human reader.
Indeed, so why not let the human writer clarify it?
Why do you prefer a resource intensive guessing algorithm that will
never have a 100% accuracy over just having an annotation that
takes less than 10 bytes and is trivial to parse?
In my opinion there's no reason to even consider the first
option, especially with gemini's focus on simplicity in mind.
This "what can another little JS library hurt" attitude is what
lead to gemini in the first place.
Add language inference heuristics to cover all kinds of formats
and now you've got a dependency. Then some people need different
settings so you add config files and parsers/dependencies for
those. At some point you update the model and now it can't
properly differentiate Mandarin, Cantonese and short Japanese
phrases anymore. You start adding cross-platform support and
other features, and now some people say it's too slow on their
Raspberry Pi Zero setup. Bloggers complain as they have to
rearrange some quotes via trial-and-error so the heuristics pick
up the correct language. Unfortunately that makes it worse for
people running the older version 0.7.
After this rant it should be obvious, but: I prefer just adding
a ["en"] or similar and stop worrying about it.
PDF actually has support for language tagging, and using it is a recommended part of any guide to accessibility for the visually impaired.
It may be that the language which a quoted foreign-language word is meant to read in was mentioned far back in the text. Human sighted readers will know how to read it, but computers won't yet (and perhaps won't for many years if not decades). However, there are visually impaired people now who need to be guaranteed the same Gemini experience as sighted users.
But some unicode characters are supposed to be rendered differently based on the language of the text that contains them. So this (language tagging) is required even for getting the thing rendered correctly.
Sure. But computers spotting foreign words in context similarly to how humans do is a lot more likely than getting most foreign words appropriately semantically tagged.
Sure. A quoted foreign word might (but not always) appear in some context where any reader will know how to read it. However, for the time being, computers won't, and a screenreader won't manage without adequate semantic tagging.
The difference is that the screen reader has to pick a pronounciation which could be wrong, a sighted user reading matches on the letters. Mentally matching from a wrongly-spoken word is harder.
Gemini does support a `lang` parameter to its mime types, which can be used to indicate a document is in a mixture of languages. That could be enough of a hint for a client to tune its pronunciation.
I do agree though that this is a far bigger problem space than HTML's `lang` attribute is capable of solving. It's not like knowing the language of the text always tells you the unique pronunciation of a string of characters.
Fair point, for example is it read or read? Maybe a better option would be a phonics tag or attribute followed by phonemes that no matter the language of the following word(s) would be able to be spoken by a reader?
Not having the ability to do this forces the screenreader to solve the problem, and it's a really hard problem in general - something like "real" that already exists in English but crops up in Spanish contexts fairly frequently is tough, let alone all the proper nouns etc.
On the other hand, there will also be a bunch of cases where people don't do the work to mark this up (maybe not even realising they need to)...
Did you know the chinese character '男' and japanese '男' are spoken totally differently?
Okay, now try to read this comment with a screen reader accurately. Someone who knows chinese, japanese, and english will be able to pronounced both of those words correctly. There's no heuristic that can do the same.
I should be able to annotate each of those characters with whether it's meant to be chinese or japanase.
This is first I'm hearing about the lang attribute (edit: for something smaller than the whole document), so I'm curious how commonly is it used in the "web at large". Do you know?
It’s very common to use it on the HTML element, less common to use it on elements further down the tree. Like many accessibility features of the web, it’s often neglected by developers.
I live in a multilingual country and don't see it used as often as I would hope, even if it's more common here than elsewhere.
I often see it on elements/sections of sites that link to content in another language.
Here, German is the "main" language and lots of documents are available in German but not English. If you need to link to a German page/doc from an English one, it's not uncommon for the link text to be in German too.
If you like the idea of having bare-bones text-only web then you will see how everybody and their granny have a feature that they won't get onboard until it is implemented. Then at that point we will have HTML again.
I'm more optimistic, I think it might be able to find its niche. I agree it would be hard to outright replace the web, but there's room for more than one way of delivering text. man pages are still around, for instance.
Browsing via a remote session (https://gemini.circumlunar.space/clients.html) is classic. Telnetting to a machine that had a text web browser was a real thing back in the early 90s
Someone is either old or has done some serious homework (maybe both). Good job.
Note: also, since people who don't know what they're talking about occasionally seem to want to challenge me on early (pre-1996 or so) web history here's some references:
The author is 100% right about the effect of having formally designated spaces for things that you would think could happily exist as informal subspaces of a wider environment.
Cold engineering logic drove us to see that everything is just bytes and so everything can be served over HTTP.
The same logic is used in the retail world to optimize away culture and quirk and nuance and difference: everything is just a product, so everything can be sold in just one superstore.
I see the small Internet movement as not just about nostalgia (although it’s definitely a little bit about nostalgia), but about countering monoculture by prioritising things other than efficiency.
Gemini doesn’t need to be extensible because if you want to do something different, you can use a different tool and they can happily coexist, because the objective is not to achieve a winner-takes-all network effect victory.
>Cold engineering logic drove us to see that everything is just bytes and so everything can be served over HTTP.
>The same logic is used in the retail world to optimize away culture and quirk and nuance and difference: everything is just a product, so everything can be sold in just one superstore.
That seems an odd aspersion to cast on a protocol that gave Hacker News the culture and quirk and nuance and difference of the early web it's so nostalgic for.
I've entertained an idea to build a set of tools for contemporary development (version control, code review, CI, etc) which would only speak Gemini. That would be both the UI and the API.
Blockers came fast:
* no way to upload anything that exceeds 1024 bytes,
* escaping is subtly broken and so it would be impossible to review code written in Python or Markdown (triple quotes)
* No text editing capabilities, pretty much.
Which is fine: Gemini is great because it's restricted. It's nearly impossible to abuse. It will find its users, even if it would not be me.
The one thing that puts me off the most is the limit of two levels of headings.
(There are three, but you need one for the page title, and it would be awkward to reuse the "title" heading level for "section" headings. Even if you got over this awkwardness, three levels is still annoyingly constraining.)
and go from there. The format is meant to be human-understandable, not machine-readable.
But your point is a good one, and made me wonder how the documentation of Gemini itself handles the issue. And behold, the Gemini FAQ [0] itself has the first level 1 heading as
## 1. Overview
and the second one as
# 2. Protocol design
That's really disturbing once you notice, but I'd wager that hundreds of people have read the page and not noticed.
>IMHO you could just use [...] and go from there. The format is meant to be human-understandable, not machine-readable.
I disagree that it's not meant to be machine-readable. Accessibility clients rely on heading levels to infer sections and subsections. HTML has `<section>`, but a Gemini client only has heading levels to go by.
But anyway, that's why I said it'd be "awkward", not "impossible", to reuse the title heading level for section headings. The rich-text Gemini client as well as the human user reading the raw file have to special-case that the first `#` is the page title and not equivalent to other `#` in the file.
And like I said, even once you get over that awkwardness, three levels is still very limiting. I'm looking at a markdown documentation file right now that has five levels of headings. That's with one unique level for the page title, so even if it were to reuse the title heading level for the section headings it would still require four levels of headings.
>And behold, the Gemini FAQ [0] itself has [...]
Ha, I didn't know about that one. I had noticed in the past that the homepage [1] uses a unique level for the title, but the specs page [2] does not because it can't afford to.
I also noticed a few cases of trying to use markdown emphasis on the docs. If you can't even write the platform docs without having to work around your markup system, maybe don't go on about how the spec will never need updating.
I would argue that being limited to two levels is a feature.
Here's a related quote[0] from Edward Tufte.
"Dr Spock's Baby Care is a best-selling owner's manual for the most complicated 'product' imaginable -- and it only has two levels of headings. You people have 8 levels of hierarchy and I haven't even stopped counting yet. No wonder you think it's complicated."
True, text/gemini is not really suitable for UIs. I did write a wiki engine where the editing is done with sed commands and all responses are text/gemini. It works but people used to modern web apps are not going to love the UX.
You can serve other mimetypes over gemini (the protocol). That's useful for some use cases (eg. ansi.hrtk.in serves modem download emulated versions of ANSI art; requires a streaming-capable client).
But all in all, Gemini tries hard to not be an application platform. These exercises in stretching the limits are fun and IIRC have also guided the development of the spec. But the focus of the project is on text-based content.
> 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.
So not as the default markup language, but available.
Really nice project, seems like some keys to open up the internet again would be:
- Decoupling of data (articles, videos, ...) from platforms.
- Decoupling authorship claims from platforms
- Decoupling online identities from platforms.
- Decoupling of user networks from platforms.
- Distributed archiving, some years ago if you had an article/manifesto or whatever on Napster or any other P2P system it was trivial to find it again anytime you wanted, now dead blogs, videos disappearing from Youtube, or broken links to Twitter are the norm. You have to archive stuff yourself or hope somebody did it.
- Related to decoupling user networks from platforms, it would be nice to decouple comment sections from platforms and from the articles themselves too. People could comment the same article in different curated comment sections with different moderation policies using their own decoupled online identity.
- Create decentralized networked chains of trust (could help revitalize some scientific communities too).
Seems like very interesting things going on with projects like gemini, Urbit, IPFS, still on the early stages and only usable by power-users, but hopefully they will keep growing.
- decouple documents from the transport layer: many web vulnerabilities and complexity are due to the strong connection between http and html
- decouple documents from styling: every document should be legible with any stylsheet (bring back 'userstyle'), cut back css features which lead to nasty things like keylogging via css, transparenting elements for clickjacking, hide text to manipulate clipboard, etc.
Commenting on posts is something that Gemini enthusiasts are still figuring out. Currently people post Re: posts to their own gemlogs and then mail a link to the person who made the original post, but I think they are hoping to have a less effortful convention.
I found this quote on a gemlog by Alex Wennerberg:
> Gemini's obscurity and lack of utility means that there are no analytics, no metrics, no ways to go viral, to monetize people's attention, build a career or even a minimally-functional web platform. No sane business would build on top of Gemini, and that is exactly why it is capable of having the character that it does.
I don't understand why the gemini people don't just use http 1.0 (+ host) with html (or plaintext/markdown/whatever even, without js/css). Seems like a case of NIH to me. Don't get me wrong, I am not against "reinventing the wheel" for a toy project or to learn but gemini seems to have become more popular than just that. If someone is really tired of the modern web I would suggest to them a distributed alternative rather than this.
> I don't understand why the gemini people don't just use http 1.0
Think of it as cars and bicycles: why do people use bikes if cars already exist?
- because it's healthier
- because given a proper infrastructure it's more pleasant (and probably safer)
Of course one can ride one's bike on most car oriented infrastructure, but it's nice to know you're not going to be hit by a truck if you make a turn somewhere.
Well, for one thing, you can easily write Gemini pages in a text editor, without worrying about HTML, WYSIWYG or other markup formats.
You can write your own server or client in a couple days, from scratch, without using libraries or worrying about corner cases.
You're not exposed to the larger web, accidentally or otherwise: no web crawlers, links from modern web sites (causing annoyed users who think your site is broken), or invasions by thousands upon thousands of 4chan trolls or whatever.
So, to go back to the metaphor: a bicycle is not a car, and for _most_ use cases it's objectively worse. It doesn't go nearly as fast, it exposes you to the elements, it can't carry very much. But it's easy to tune and maintain yourself with just a few simple tools. It does require effort on your part, but the exercise can be enjoyable. You don't need to worry about refueling, accidents aren't so dangerous, you can go on winding little trails and skip the freeways. Traffic isn't an issue. You end up paying more attention to your surroundings and noticing details more on a bike ride than you would in a car.
One option is very deliberately simple and low-tech, and despite that it ends up being (for some people) a more pleasant and beneficial experience.
> you can easily write Gemini pages in a text editor, without worrying about HTML, WYSIWYG or other markup formats.
text/gemini is a markup format by itself, and I do not think that it is any more readable/editable compared to say markdown.
> You can write your own server or client in a couple days, from scratch, without using libraries or worrying about corner cases.
Good luck implementing TLS from scratch. If we ignore TLS this argument still does not make a lot of sense, I made a toy http server years back within a few hours.
> links from modern web sites (causing annoyed users who think your site is broken)
This line of argument seems elitistic to me, as in "we do not want the common non-technical folk to start using it".
> or invasions by thousands upon thousands of 4chan trolls or whatever
Yet one of the most popular sites on gemini is a BBS by kiwifarms (which includes 4channers).
The metaphor (thanks for explaining it by the way) seems to make the incorrect assumption that gemini is a simpler protocol compared to a subset of http that gemini could have used instead.
A big part of the reason is Gemini was developed by people interested in Gopher, acknowledged the short comings of Gopher, then thought of solutions in the context of Gopher.
I do not buy it. Just use gemini:// rather than https:// to refer to that specific subset of https + html. Maybe also add a header to the server response that says x-gemini: true or whatever.
> It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers
Just do not use mainstream browsers then. Make your own like you do for gemini. They address it a bit later with:
> Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch
And I will disagree on this part, http 1.0 is actually easier to implement than the gemini protocol.
> Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
Except gemini browsers render even less websites right now.
It seems to me that the gemini developers can't really think outside the box. This is further proven by their dependence on things like TCP, TLS, and DNS.
gemini isn't trying to reinvent the web, to make it P2P or serverless or whatever; it's just reusing the ideas of gopher and the web but going in another direction. It doesn't try to replace the web. From this point of view it makes total sense to reuse TCP, TLS and DNS, because they're not trying to replace them.
> Maybe also add a header to the server response that says x-gemini: true or whatever.
That would require adding headers, which means extension is possible, and that's explicitely something gemini doesn't want. I believe it makes sense in the goals gemini wants to achieve.
> And I will disagree on this part, http 1.0 is actually easier to implement than the gemini protocol.
HTTP 1.0 still has multiple headers and multiple verbs. It's actually closer to HTTP 0.9. Yes, you can say "don't use those" but at some point it's good to refresh the spec and see what is and what isn't needed. Moreover HTTP is just HTTP, Gemini is transfer + encryption + client identification (through client certificates); the latter is still the wild west for the HTTP world, there is no clear set of "best practices" in this domain
> 1.4 Do you really think you can replace the web?
> Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that many people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.
For the other point you seem to forget that gemini doesn't exist on technical grounds but on philosophical grounds: it wants to create a new space with its own rules, even though the technicalities are close to something that already exist. People have written blogs (called gemlogs in gemini), and they "hacked" the format to build an informal replacement to Atom. The constraints of the medium created the requirements and the result is a simple, human-readable and human-editable document that can replace Atom in most cases: https://proxy.flounder.online/gemini.circumlunar.space/docs/.... It follows the philosophy of making this new space more human-centered.
By "This is what they claim, yes." I meant that they claim that they are not trying to replace the web, not that they claim that they try to replace it.
Every Gemini post on HN has an inevitable post like this.
Gemini developers want to keep things inside of a box that can't be bulldozed by corporate interests. I love it. I just wish Gemini browsers would optionally inline media and video links, but I'd be surprised if that doesn't happen before too long.
What I meant I guess was displaying images and video inline on a graphical browser instead of on a new page or browser instance. Looks like LaGrange already does that at least for images.
Yeah, I really like the links being on distinct lines. I don't know why, but it's refreshing. I think it also encourages a document writer to actually provide details about the link and definitely gives the user agent an opportunity to display the destination and be clear about what is happening.
> 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.
Not that I can't see the appeal for the gemini devs to start from scratch and roll their own protocol rather than start with a browser and subtract the unwanted parts, but that justification is, technically, practically, and also generally very weak.
Technically, because you can very well limit HTML to a subset of markup elements (for example, to exclude <script> elements or, likewise, onclick and similar attributes accepting script). The whole point of SGML, on which HTML is based, is to define markup languages, and also derive restricted languages from general ones. The problem here is rather that HTML on its own isn't expressive enough for interactive things we've come to expect (such as idk menus, table-of-content summaries, and other navs or in-page search dialogs and other interactive features that are not quite webapps) yet is also too powerful with js being inserted everywhere to non-heuristically comprehend content for reader mode apps and screen readers in the general case.
Practically, because syntax checkers (SGML or otherwise) and NoScript exist and have for a long time. It would also be cool if search engines could finally come around and penalize or at least flag content relying heavily on script and/or invasive tracking for ads. One way to make this happen is to introduce application/html as opposed to text/html media types.
Generally, because HTML and other markup vocabularies have been developed using public money for, well, publishing hypertext in academia, and it's odd to marginalize that original use case just because of the desires of ad companies.
The argument isn't being technical or practical, it's being mental.
It's acknowledging the fact that if you given humans a different/unfamiliar protocol they will be naturally inclined to treat it's content differently, which is the entire point.
as i understand they don't want that people start browsing supposedly gemini-only web with browsers supporting more than that is in the gemini specs. So those people will still get the dark side of the modern web.
The idea isn't to use more simple tools, but to create an environment where only simple tools can be used.
Http was made to transport documents to people (or machines) requesting them. Then images. Then form submissions. Now, try going to a website where all you're trying to do is read some text and see what you get. The vast majority of web browsing to this day is people trying to read text. Yet the vast majority of links you click go to great lengths to do things other than deliver you text. Wouldn't you say, at least for that use case, that a more restrictive protocol would make everyone's lives a little better? It is not enough to just write documents without the megabytes of cruft packed in, you must make it so that to reach people you cannot pack megabytes of cruft into your documents.
TL;DR: a completely different protocol creates a different space; when you're on gemini you know what is and isn't available, there's no need to think about not being tracked or not fetching MBytes of images and scripts, even if you don't display or execute them, because the protocol says no.
I've been diving head first into the Gemini space this weekend and discovered some really great content. It takes me back to web of the early 2000's where you had websites with manually curated content (webrings! link rolls!) instead of corporate milked content aggregators.
Combined with my love for minimalistic websites (hello http://motherfuckingwebsite.com/) I find Gemini a perfect small web to enjoy.
I've even started updating my static site generator to update both HTML and Gemini output.
I like how it removes noise for the reader. Links cannot simply be put whereever the author pleases. Links have to be put on their own line. (and the browser can neatly indicate to you which links are same-domain, other-domain, other-protocol)
I hate not being able to integrate links in running text - it's been a feature of the web since the start, having to awkwardly add "see this link:" followed by a newline everywhere would drive me mad.
I felt that way at first, but when I started to understand the reasoning behind it (explained in the Gemini space FAQ and counties meta articles, which is a lot of Gemini documents) it makes perfect sense.
When you're reading a document, it is to enjoy information. Whether that's learning, recreational reading of fiction, or whatever, a subtle part of the experience is the structure of the document. It gives you context and helps maintain a flow of thought. A reference to an external document should be plain as day and stand out. It should not bleed into any other part of the document.
This might sound like an over rationalization, but to get an idea for this, imagine if footnotes or references were tossed in using parentheses wherever they were referenced. The structure of the document is important, sometimes as important as the content.
I've found that the lack of good footnote handling in Gemini is a real pain in the rear.
Consider footnotes in a book, you see the superscript 1 or the star or the cross and you know you glance towards the bottom of the page for that content, then jump back to where you were. On books, in dense text, you can put your finger on your current location, look to the bottom of the page, read that content, then pick up where you left off.
On a screen it's harder, since going to "the bottom" involves n pages of text to be scrolled by. If I hit [End], I don't know how many [Pgup] to hit to go back.
I can hit [Pgdn] a few times and count mentally (which sucks, and takes me out of the flow), but due to the way text is flowed, reversing with an equal number of [Pgup]s will usually wind up taking me somewhere above or below where I started.
This disorientation is not desirable.
Inline footnotes on most rich text sites usually have a link directly to the footnote, and then a back link which jumps to where the note was referenced. This is the best of both worlds. I'm on board with most of the Gemini limitations, but I see this being a no-brainer addition to the protocol if not a sane client.
I keep getting pulled toward the small internet by various forces, but I never seem to find the center of it, the place where the good content starts. I want to find the good phlogs and the secret message boards. I've connected to modern day BBSs and could never get used to the keyboard layout. What am I missing?
Gemini is fantastic. For anyone interested in experimenting with it without setting up a server, I've been working on a simple Gemini site builder that works over HTTP and serves the content via Gemini and HTTP proxy:
In my view, Gemini's bare-bones text format is its killer feature. Non-technical users have been able to easily write Gemtext based on a few examples and a bit of experimentation. This gets users away from WSIWYG without forcing them to learn something as complex as HTML. And unlike Markdown, it is clearly-specified, universal, and doesn't compile to anything else.
Many people criticize Gemini for lacking this or that feature, and being basically useless for "practical" applications. I wrote an blog post about this:
Beyond using TLS for the connections, I struggle to understand what Gemini offers over Gopher. Gopher's document type is bare bones text also. Gopher is an open standard also. There's many clients and servers for many platforms, and it's easy to implement.
I've been subscribed to the Gemini mailing list for a while now, and browse the conversations on it (it's very active), and I'm still yet to be convinced it's a viable alternative to the web that will gain any traction outside of it's core hobbyist user base.
Gemini appeals to the 'console-only' aesthetic, I won't bet on it replacing
the everyday web, but it can be used to construct an alternative 'Internet for the terminal'-type experience: lightweight news, libraries, etc accessed from shell scripts(which is plain text vs web scripts that strip html cruft to get real content).
The only thing i dislike is the poor choice of the name, which clashes with millions of sites about horoscopes.
It goes beyond the console asthetic, it becomes about functionality for the user. I think it could very much replace the majority of the web over time, or something like it could. I'm not just being naive about something I have a pet fascination for here either.
Imagine the internet in the year 2121. Do you really think that people looking to read an article about such and such that happened today are going to tolerate your abysmal theme design, constant requests to sign up to your newsletter interrupting their absorption of knowledge (or propaganda), nested dropdowns, account requirements, just to read your take on current events? Will the excuse "how else are we supposed to get paid" be an industry standard in 100 years, when the internet is as integral to the human experience as spoken language?
A big reason we tolerate all the cruft is because the world has just recently left the phase where the internet is just a novelty. The internet was experienced inside of 1 application, the web browser, and that is very clunky. We are already leaving that behind with people demanding a separate app for every type of interaction they have online. The day will come where, when someone just wants to read something, they'll expect just that, and there will be millions, possibly billions, of people willing to deliver that for them. If your goal is to get your message out there (or your ideas into someone else's head), you're going to face a lot of competition, and your audience might not have the time and patience to deal with any more than they asked for.
I've been messing with Gemini some off and on. A little unsure about what to build given the limitations. It seems to expect the user to use direct SSH access to servers for anything that would normally involve sending more than trivial amounts of data to the server.
The most interesting part IMO is the restriction to use user-managed TLS client certs as the exclusive way to identify a user. Nice way to both securely manage user identity without clumsy passwords and all of the issues they bring, and easily allow the user to have zero, one, or many identities and switch among them anytime they feel like it. Eliminating cookies and other such things in favor of it eliminates third-party tracking and puts the user in charge of who knows who they are and when.
I don't know if Gemini itself has a big future beyond a niche circle of bloggers. I would like to see the client cert feature be widely adopted within HTTP though. Maybe, among other things, Gemini can also be a lab to test out ideas that might make the mainstream web a better place too.
> Gemini is one technological piece in attempts to make a version of the Internet which is healthier for humans – the so-called “small Internet” movement – and maybe there will be new ideas about how the small Internet should be which would benefit from a new version of the Gemini specification. So it seems risky to lock-in to one version.
If there are better ideas or fundamentals on which to build the root of another space, then what the Gemini is protocol is saying is that -- make your own protocol and name it something different.
I don't think it's risky to lock-in to the Gemini protocol because: It's very minimal, so A) clients should be minimal as well, and B) Gemini documents are human readable without a client. So if Gemini doesn't work out, your *.gmi files will hardly be useless blobs of tags.
My main annoyance for gemini not having http is that i do not want to run a VPS. My (web) site is running on shared hosting where keeping (or not) software up to date, keeping up with the latest and greatest way Gmail breaks email and any other admin-level stuff i handled by someone else (and also it is cheaper) - i just upload a bunch of static HTML files and anything else i need to share and leave it at that.
If Gemini used http 1.0 (like others mentioned) it'd work out of the box - not just for me, but for everybody else. But the custom protocol pretty much requires a VPS and that opens a can of worms i'm not interested in opening again.
FWIW i used to have my own "gopherhole" but since that one also needs a custom server, i dropped it after i switched from VPS to shared hosting. I still have the client i wrote though[0] and considered making a Gemini one at some point but the fact that i can't make my own site does hamper things a bit (and TBH i haven't updated the Gopher client for years either).
On the last paragraph in the article (criticism of the lack of extensibility of the protocol), Gemini itself is a protocol largely designed to improve on the modern shortcomings of the gopher protocol, so if ever Gemini were to fall short of the demands of the type of people that use protocols like this, the solution is right under your nose: make a new protocol.
I'm a big fan of Gemini. I think the philosophy around light document delivery over the internet is very important. And the lack of extensibility is a core part of that, Gemini cannot be everything to everyone, by design. And no protocol should, I personally find the idea that http is used to deliver news articles and web apps to be a bit ridiculous, the protocol was extended well beyond what it was intended, and I can find no reason for this other than that people don't like typing different things on the left side of the "://", if they ever even type that part at all. Imagine an internet where people routinely use different protocols (and know about it), how much cleaner the experience would be.
I respect the sentiment of starting from scratch to get rid of technical debt. The protocol is not very different than HTTP/0.9, with hindsight applied.
That being said, the protocol interaction model is essentially the same as HTTP.
There is another road where browsers get support for the text/gemini content-type but still talk HTTP only. It doesn't fix everything but it has the advantage of allowing normal users to participate in it.
While I think gemini is a cool 'hideout' on the web, it seems a lot of content served over gemini is also served over http. Does anyone know of any message boards like The Midnight Pub[1] that are served over gemini only? After some browsing, I couldn't find any.
I'm hosting a very simple one at gemini://gemini-textboard.fgaz.me but it's mostly just a demo for my gemini Haskell libraries: https://sr.ht/~fgaz/haskell-gemini/
That's kind of the trouble with Gemini now. Since you can't send significant amounts of text to the server, you can't really make a message board kind of thing in pure Gemini. The content submission has to be done via HTTP or a terminal interface to the server.
But then, if HTTP is the simplest and most secure way to allow posters to make submissions, then is there really a point to allowing the messages to be read over Gemini? Might as well make a simple HTTP layout and have the whole thing run over HTTP.
>That's kind of the trouble with Gemini now. Since you can't send significant amounts of text to the server, you can't really make a message board kind of thing in pure Gemini.
Given the aggressive anti-complexity stance of Gemini, isn't that supposed to be a feature? A messageboard isn't a static text document, it doesn't belong there.
It's on the protocol designers and promoters to determine what it ends up being of course. It seems like a bit of a mismatch to me right now. The client cert support as the exclusive way to identify users is a really cool feature of the protocol IMO, but it doesn't seem like it's very useful without dynamically rendered pages. It's certainly possible to do dynamically rendered pages now, but they're also of much more limited use without the ability to send complex data to the server using the same protocol.
If I understand correctly they insist on no re-use of connections. That one makes no sense to me and guarantees any compliant client will be slow. So people will make "fast clients" that just ignore that rule.
Are there any other protocols that have similar aims? I love the idea of a "corner" of the web that is reminiscent of the plain markup/pre-JS days, and occasionally use w3m to get a taste of it.
I'm not sure about protocols, but I've been browsing Neocities lately. There are thousands of sites. Many of them are a satisfactory throwback for my tastes:
Just a meta-comment, but is this blog meant to be stream-of-consciousness? I found the prose very hard to read, and the phrasing to be quite jarring. Possibly too many commas or separate phrases?
Sorry to put you through that! I normally go back and edit my blog posts at least a little bit, but I wasn't very happy with this one, so I didn't bother. I didn't expect it to have a readership beyond whoever happened to look at planet.debian.org yesterday.
> I now have a games console at home for the first time in some years, which I bought in response to the ongoing pandemic, and one thing that I have noticed is that using it feels like being offline in a way that playing games on a regular computer never would.
I agree with you. The structure of his thoughts could use some improvement.
This is the equivalent to creating a new programming language instead of just using C syntax with the C++ compiler.
HTTP/1.1 is our final network protocol, just accept it. Just like Java is the final serverside programming language. JSON is the final data container.
Everything else is completely stupid, indefinitely.
Also: Make your own crypto! Xo
But if Firefox and Chrome bans HTTP/1.1 (which means they will be obsolete) AND gemini adds chunking (without which it is meaningless) AND port 1965 is opened in every firewall on the globe; I might actually consider switching to gemini/v0.14.4 on my app server!
