I'm working on an alternative media type for . I expect it to be contentious, so I'd like to hear some thoughts on what y'all would like to see in an extension Gemtext.

@josias There's only one thing I miss from gemtext and that's a way to escape code blocks. Like, some way to include the characters ``` in a code block.

@almaember I personally do that by indenting those characters with a space.

This is also a problem in Markdown, which resolves it by having two kinds of code block delimiters, ``` and ~~~.

@josias Oh yeah. I think the best solution would be to require the alt text to be duplicated on the closing end. That would allow you to include (in theory) any arbitrary text in a code block.

@josias Always italics, I use them so much in my fiction.

@josias A way to tell the browser the difference between a code block and an ascii graphics block so the browser can just block ascii junk.

@devinprater Do you think this could be possible with existing Gemtext? Clients might be able to determine whether or not something should be read by whether the alt-text contains "ascii" or "graphics" or something like that.

@josias Sure but people aren't gonna use that much of the time.

@derwinmcgeary You can already serve org-mode with Gemini, but that requires using Emacs to use it properly.

Unfortunately, elpher doesn't support org-mode directly at the moment.


I would like support for stock Markdown or maybe CommonMark. The current markup is *almost* there but it uses EOL as a paragraph break, which really doesn't work well with common editors.

@suetanvil Markdown is difficult to parse and render properly unless you're just converting it into HTML, which isn't ideal for Gemini.

It's not straightforward or simple to implement, unlike Gemtext. Something between the two seems appropriate, at least IMO.


Actually, I'd be content (well, less annoyed) with gemtext as-is except that adjacent lines form paragraphs with blanks as a separator.

I mean, it's a trivial script to fix this but that's always struck me as Just Wrong about the design.

@PetabyteStudios At this point Adobe flash might be retro enough to fit into Gemini. Not simple at all though.

not serious, cursed 

@josias @PetabyteStudios uxn embeds instead of flash

not serious, cursed 

@csepp @PetabyteStudios Let's do it. No more cursed than Flash in HTML.

@josias support for tables would be nice.

And there might be some cool use cases for streaming. For example a syntax for replacing previous lines. Something like terminal control sequences, but simplified & with nicer syntax?

@antolius That's not a bad idea. It's out of scope for this, as this is supposed to follow the philosophy of Gemtext while adding a couple features, but this could be useful elsewhere.

To support basically any environment, I think instead of having the client render it directly, a compiler should turn the source into the actual control sequences. That should make it run anywhere.

Whether this is a good idea or not is another question...

@vidak Gemini clients are only supposed to make one request per page, so embedded images wouldn't work in any spec-following client.

I think Lagrange's approach to inline images in existing Gemtext in as good as we'll get, allowing you to click an image link to load it. It already works pretty well.

@josias @vidak Yes, this is a feature. One request per interaction eliminates most fingerprinting and bandwidth concerns. Click-to-load is actually such a good idea that make all media elements above 100kb click-to-load in uBlock Origin.

The only Gemtext feature I want: a distinction between pre-formatted text and ASCII-art, and for programming-language-indicators to be explicitly made a non-use-case for alt-text OR for code snippets to receive their own defined semantics. Really, really important from an accessibility standpoint (esp for screen reader users). aired similar concerns

I don't think adding footnotes are necessary, since you can just add a paragraph and start it with the phrase "sidenote: ". Users can skip the paragraph if they want.

I don't think adding inline formatting is necessary or desirable, since many clients (including many screen readers) just strip inline formatting on the Web anyway. Authors should try to express meaning through words instead.

One of the best things about gemtext is links getting their own lines. This makes authors more likely to have more descriptive links that can double as navigational aids. Enhanced link meaning and the navigational aid make screen reader life much better.

Some non-gemtext Gemini features I want:

1. Compression. Technically not a Gemtext feature. Users of low-bandwidth connections benefit from being able to download single large pages instead of many small resources (see the "Against lazy loading" section of Combining many articles into a single resource can help with this, but payload sizes can skyrocket easily. Text compression can bring payload sizes down considerably; it's what allows many people to offer full-text RSS Web feeds that are hundreds of thousands of words long.
2. Something to supplmeent TOFU so that the initial request can't be intercepted and altered. Since Gemini already relies on DNS, perhaps DANE could work. Alternatively, some sort of distributed hash table (no blockchain obviously) could help. Honestly, your best bet is to make you capsule available as a Tor hidden service (known on the Gemini space as "Deep Space capsules").

@Seirdy @vidak

In my opinion, Click-to-load is a great compromise between inline images and external ones, and actually fits fairly well into Gemini.

1. As you mention elsewhere, wouldn't compression be a server and client feature? Gemini doesn't forbid sending or decompressing gziped files.

2. As for TOFU, I liked the concept of also loading the capsule via Tor alongside the first request to see if the certificates match before adding it to the list of trusted certificates. Could that work?

@josias @vidak For no. 2, this tells you that your client's connection is not compromised. It does not tell you that the server's connection is not compromised.

@josias @vidak

You could embed an image right in a Gemtext file using a data-uri.

For example —

=> data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg== The "alt" Text For The Image

The Gemini browser just needs to display it.

(Terminal based Gemini browsers could display images too as a sixel, or some other Terminal image technology — that most people are unaware but are old.)

@reiver @josias @vidak I was certainly surprised when I read the code implenting SIXEL images in LibTTY, which is the widget your terminal emulator probably wraps.

That was an interesting study!

@josias You mean like a native Gemini specific media format for static images, audio, and/or video?

@josias inline images. If Gemini never concedes its blinkered stance on images nobody (other than people who write gemblogs about how great Gemini is) will ever actually use it for anything

@ItsTheManOnTheMoon How about the clients that make images click-to-load? Are those reasonable in your opinion?

@josias the order of priority is pretty much top to bottom for me

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).