[woodrowbarlow]

then use kineto[1] or similar to cross-host your gemtext content as html over https, with your own css.

1: https://sr.ht/~sircmpwn/kineto/

(i do this for my blog, anachronauts.club/~voidstar. i kind of hate gemini-the-protocol, but love gemtext-as-default and love having a space where text-forward content reigns.)

[Terretta]

For similar but not gemini-the-protocol you can do similar with markdown and caddy2.

Here’s how to make it pretty-ish: https://github.com/dbohdan/caddy-markdown-site

Serving just the markdown as plaintext to e.g. Lynx is straightforward.

Discussion here:

https://caddy.community/t/markdown-support-in-v2/6984/12

[zzo38computer]

But is there "Gemini over HTTP"? You can serve text/gemini files also HTTP(S), and also local files too. (On my computer I have it set up that it is capable of loading files of this format (locally and remotely), although most other programs are not capable of understanding this format)

[woodrowbarlow]

but www browsers don't render gemtext and gemini browsers don't fetch http(s) resources.

ideally we'll tweak our gemini-to-http proxy to look at the client's "Accept:" header (as suggested in other comments on the op) to decide whether to reply with raw gemtext or converted html-with-css. then a www browser receives light formatting, curl receives raw gemtext, and gemini browsers format however they like.

[zzo38computer]

Some browsers might accept both. My computer accepts both (although not the Gemini protocol, but it does have Gemini file format, and can read this over HTTP(S) and local files (including inside of ZIP archives, so gempub files can be displayed)). (Also, curl does not have Gemini (although I think that it should).)

There are some problems with using Accept header (although you can use it as a start; if you can implement it, then you might do so). Even if it is mentioned in the Accept header, servers will not necessarily understand it, and if a lot of file formats are implemented then it can make the Accept header very long, knowing properly the preference, trying to explicitly download the raw file or a specific other format (regardless of the Accept header), and other problems, etc.

(My idea is a Interpreter response header, although this requires that web browsers will implement it.)