Ansi colour markup - what encoding or mime type

Hannu Hartikainen hannu.hartikainen+gemini at gmail.com
Sun Jul 12 23:15:32 BST 2020


On Sun, 12 Jul 2020 at 11:50, Luke Emmet <luke at marmaladefoo.com> wrote:
> ANSI escape sequences should not be interpreted within text/gemini
> content (after all when would it stop - there could be embedded html or
> other markup that clients will become expected to interpret). Similarly
> they should not be stripped out - since how would one know they were
> there, and should be intepreted rather than just presented.

IMHO if a client is outputting to an ANSI terminal, the client author
should consider what will happen with ANSI sequences. It is reasonable
to strip or escape all of them, or a subset of them, or decide to let
them through. Consider that a terminal UI is itself built with ANSI
escapes and rendering them within the page could break the UI (or
worse, emulate the UI!). Moreover, you'd need to fully parse the
sequences and emulate terminal state to implement a sandboxed version
of ANSI sequences (unless you limit to a subset, say, SGR). I learned
that when trying to render 80-column ANSI art on wider terminals
(ansi.hrtk.in does that but background colors leak).

Similarly, if I was writing a Gemini-over-HTML proxy I'd certainly
escape all HTML tags and entities. First, it makes sense to show the
content to the user instead of interpreting it as control sequences.
Second, I've learned on the web that rendering any user-supplied
content without sanitizing will result in a disaster.

Gemini is still small and friendly, but when designing software it's
smart to account for bad actors.

-Hannu

PS. I just added yet another ANSI streaming server,
gemini://asciinema.hrtk.in/ for playing back asciinema.org recordings.
Probably only useful as a tech demo or a client test.


More information about the Gemini mailing list