[zamadatix]

Aren't e-readers perfectly able to display e.g. MD over HTTP on existing clients instead of gemtext over Gemini on a one off client? Or even gemtext without it being over Gemini or a dedicated client? Similarly how does being incapable of doing something enhance just not doing that something?

I get Gemini as a way to form a clique of like minded people who know of it but I don't get Gemini as enabling anything that couldn't or wasn't already being done before.

[cpdean]

You are correct, ereaders have supported viewing the web for years, but it has been a miserable experience since the beginning.

    * Inline links everywhere tempting you to click away to a new page, both fracturing your attention as well as being a multiple-second delay between pages
    * Images are everywhere, needing to be interpreted by the rendering engine of the ereader either with a simple monochromatic threshold to figure out what parts of the fully color image are black and white, or if you're lucky it has some way to re-process the image through dithering so that it's possible to see what it is
    * web layouts always wanting you to have a screen larger than an ereader can support, so you're stuck scrolling back and forth on a tiny screen that already has a miserable refresh rate of once or twice a second.
    * the web is an application platform now, the vast majority of its features just not fitting within what an ereader can support

You're all correct, you can easily implement what Gemini does if you make one website that is only text. In fact, you can probably do it better since you don't have to be constrained to gemtext, or constrained to its handful of weekend-project servers for hosting the site, all of which have their own issues.

But the thing that keeps drawing me back to is is that while you can easily implement Gemini with HTML and HTTP, it is impossible to implement HTML and HTTP in Gemini. The fact that you can't implement a webapp in Gemini means that if you're browsing pages in Gemini, you get a consistent experience and every site is clean and respectful of the experience (whether the author wanted to respect it or not, they have no choice).

Perhaps the real counter-argument to Gemini is not "why don't website authors just make their websites simpler?" but instead "why don't modern browsers run in 'reader mode' by default?".

[zamadatix]

Where did I say anything about websites or HTML? Since when can HTTP and HTML be implemented in Gemini? And even if it could how does that answer the question?

For all the explanation of what Gemini does and why HTML+HTTP in a browser don't this response does very little to actually answer the question: "Aren't e-readers perfectly able to display e.g. MD over HTTP on existing clients instead of gemtext over Gemini on a one off client?"

[octoberfranklin]

Gemini takes a while to appreciate.

The first step is realizing that it was deliberately designed to be inextensible. Anything that can be extended will accrue bloat.

The second step is to realize that it's really just plain text. Once you realize that, the choices about what kinds of formatting make total sense:

   * bulleted lists, but not hierarchical
   * links but they have to be in a paragraph of their own
   * preformatted blocks but no italics
   * linewrapping but no collapsing of multiple sequential linebreaks
   * headings but no boldface
   * blockquote with > just like email (*are you listening, @dang?*)

They're the kinds of formatting that impose zero burden on somebody reading through a terminal. In fact, linewrapping is really the only thing you need to do to gemtext to make it readable (versus just "cat foo.gemini"). Rich clients like Lagrange then take this limited set and render it as beautifully as possible on something much more powerful than a VT100.

In a way, this is just an extension of the "first step". If you start allowing rich markup, where do you stop? Not allowing anything that would make the markup itself any less readable provides a natural point at which to halt extensibility, for principled reasons.

I recently discovered that Lagrange will treat a link to an image as a lazily-loaded inline image -- you have to click the link to make the image appear, but it appears inline where the link had been instead of replacing the page that linked to it. I think this is a really beautiful way to enhance the experience for people reading through a GUI without tempting authors to do anything that would burden people who are reading through a terminal.

The only big wart on the whole thing is TLS. It's cute that it solves the TCP truncation problem, but that's a lot of bloat to pay in return. I guess there isn't yet something at Layer 4 that is as minimal, elegant, and battle-tested as wireguard (Layer 3) to take the place of TLS though.

[ksec]

>They're the kinds of formatting that impose zero burden on somebody reading through a terminal.

Interesting. From a modern Web POV a lot of these are backwards, but if you look at it from terminal and other usage it is quite refreshing.