You can build a minimal browser that uses HTTP and only renders special markdown files. You can use the Accept header to send special markdown to these minimal browsers and minimal HTML to normal browsers. A new protocol is unnecessary to accomplish the goals you mentioned.
It pretty much would. You couldn't link to the HTTP-Markdown-Web from the HTTP-HTML-Web (normal browsers don't and won't support Markdown) and you couldn't link to the HTTP-HTML-Web from the HTTP-Markdown-Web (the Markdown browser doesn't and won't support HTML)
(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 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.
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.
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.
That's a massively more complex implementation for no benefit.
Also it's definitely not enough to set a HTTP header. Need to use a different schema so that the restraints on content can be expressed in the URL of a link.
A key feature of Gemini browsers is to visually distinguish between links to Gemini:// URLs and links to HTTP:// URLs.
> That's a massively more complex implementation for no benefit.
It’s barely complex. It’s a standard dispatch on the accept header, all major web servers handle this out of the box. Also it has the significant benefit of working with existing browsers. On what basis were you making that statement?
> Also it's definitely not enough to set a HTTP header. Need to use a different schema so that the restraints on content can be expressed in the URL of a link.
You can accomplish the same URL transparency by using a file extension convention. E.g. “https://foo.com/my log.gemini”
> I meant that an implementation of HTTP is massively more complex than an implementation of Gemini.
The subset of http necessary to support Gemini-style requests is really not complex at all. I’ve written basic http servers in hours if not minutes.
> The extension shouldn't be `.gemini` it should be `.this-is-not-malware-i-super-pinky-promise`
If you are someone who uses what I’m calling “http-Gemini” because they are worried about malware then use the stripped down “http Gemini” browser. For the rest of the world who is already comfortable with potential malware in their links, there is no change. The control stays in the user’s hands.
