[CyberRabbi]

I don’t think you fully understand what I’m proposing.

You create a set of conventions that “Gemini compatible” websites conform to. This will allow your site to work with small Gemini-only browsers. Those conventions mostly amount to sending markdown for URLs when the user agent sends “accept: application/x-Gemini-markdown” (or whatever the mime type would be). Web servers send the markdown to Gemini user agents while they send normal html to browsers that don’t send the Accept header.

To signify that the site is a “Gemini site” at the URL level you can create a convention that the url must end in “.gemini” e.g. https://foo.com/blog.gemini

> (Almost nobody would vary the response based on the Accept header. Besides, if they did, you might as well just set an X-No-Ads-Please header and send HTML in both versions)

I don’t see how sending a different file based on an accept header is any more technically unrealistic than creating an entirely new technology stack.

[immibis]

Your "Accept: application/x-Gemini-markdown" might as well be "Accept: text/html-without-ads-or-scripts-please" and then there is no need to write an additional document parser.

[CyberRabbi]

Well the html format does allow for JavaScript, images, etc. Not to mention it allows for arbitrary document hierarchy. it would be a large cognitive burden on users who are publishing content to remember what is the gemini-supported subset of html that is allowed. It would also be hard to standardize the subset and prevent the subset from growing.

What Gemini got right is that simplifying and limiting the publishing format prevents bloat.