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.
> 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.
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.
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.
> 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.
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.