gemini:// space
spwhitton.name
spwhitton.name
Obviously humans are a bit better at contextual clues, but.. the information has to be there for a human user to make the distinction.
If anybody ever opens an S&M themed bakery, the problem will be accentuated.
Now it won't be a surprise.
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.
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.
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.
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.
Not always, but often enough that it's an informal standard.
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)...
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.
Reading, as a discipline, is hard at the edges, and lots of humans don’t get it right either!
<sentence lang="en-US-x-Pittsburgh" intonation="falling"><word pos="subject-pronoun" ipa="hi">He</word> <word pos="verb-simple-past" ipa="ɹɛd">read</word> ... </sentence>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.
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 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...
Imagine saying accessability hardware - like corrective lenses - is niche.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
This is uncharitable. They were specifically talking about multilingual accessibility. You responded to something they didn't write.
Yes, and a minority of those users are visually impaired, hence it is a niche. Maybe you considered "niche" to mean "preference" or "novelty"?
" niche, adjective
denoting products, services, or interests that appeal to a small, specialized section of the population. "
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!
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.
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.
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.
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.
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.
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.
Ooof. This kind of wording makes me flinch away.
There are differences in the display (font) of the same Unicode character.
https://en.wikipedia.org/wiki/Han_unification#Examples_of_la...
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.
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'
Am i crazy?
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:
Page 500 from the 1994 "The Internet Complete Reference" by Harley Hahn: http://9ol.es/1994-internet-book.jpg (info: http://9ol.es/1994-copyright.jpg)
Page 272 from the 1993 "The Online Users Encyclopedia" by Bernard Aboba: http://9ol.es/1993-internet-book.jpg (info: http://9ol.es/1993-copyright.jpg)
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.
>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.
(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.)
# Page title
# 1. First heading
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
# 2. Protocol design
[0]: https://proxy.vulpes.one/gemini/gemini.circumlunar.space/doc...
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.
[1]: https://portal.mozz.us/gemini/gemini.circumlunar.space/?raw=...
[2]: https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/...
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."
[0] http://web.archive.org/web/20080610092329/http://blogs.sun.c...
> 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.
Imagine a code review tool that tries to show a diff as text/gemini.
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.
Just to clarify, triple quotes work fine in gemtext. It's triple backticks that start and end preformatted sections.
So only a line that exactly starts with triple backticks can't really be shown properly. Everything else can.
- 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.
let me add some more:
- 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.
There could be a distributed blogging/wiki platform where the articles are all written in Gemini markup (or maybe Markdown) and hosted over IPFS.
> 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 like this sentiment.
gemini://idiomdrottning.org/texts.gmi
> 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.
> 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
> It doesn't try to replace the web
This is what they claim, yes.
> From this point of view it makes total sense to reuse TCP, TLS and DNS, because they're not trying to replace them
I do not understand this point. Wanting to replace the web is irrelevant to using better and simpler protocols.
> That would require adding headers
Treat any server that contains extra headers as invalid gemini then.
> which means extension is possible
Extension is possible regardless, even on gemini. I can set my mime to text/gemini-2 and add all kinds of stuff in it.
> Moreover HTTP is just HTTP, Gemini is transfer + encryption + client identification
HTTP might just be HTTP, https however..
No it is not. See the FAQ again at https://gemini.circumlunar.space/docs/faq.html:
> 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.
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.
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.
But the only way to have some success with a old-new web is widespread adoption.
I try to host and share trough my own blogs/sites to not put everything on the giants. But if 99% does not we will still be were we are.
> 2.5 Why not just use a subset of HTTP and HTML?
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.
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.
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.
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.
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.
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.
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 just downloaded Lagrange and ended up here: gemini://cbrews.xyz/literature/the-castle-of-otranto.gmi
It does remind of early web surfing(my ref is 90s).
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.
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.
Gemini has quite a bit of good content, if you like to read without feeling the need to weigh in or interact, when the mood strikes you.
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:
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.
Except hypercore/dat, ipfs, freenet, tor, i2p, gnunet, ...
To be fair, though, tons of non-technical users were able to handle HTML in the old days. It's not that complicated.
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.
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.
Extending text/gemini is more feasible indeed.
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.
This allows you to browse Gemini space through a classic Web browser.
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).
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.
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.
gemini://midnight.pub/
Another one I know of is gemini://geddit.glv.one/
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.
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.
I agree with you. The structure of his thoughts could use some improvement.
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!