💾 Archived View for rawtext.club › ~sloum › geminilist › 002197.gmi captured on 2020-09-24 at 01:22:08. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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 authorshould consider what will happen with ANSI sequences. It is reasonableto strip or escape all of them, or a subset of them, or decide to letthem through. Consider that a terminal UI is itself built with ANSIescapes and rendering them within the page could break the UI (orworse, emulate the UI!). Moreover, you'd need to fully parse thesequences and emulate terminal state to implement a sandboxed versionof ANSI sequences (unless you limit to a subset, say, SGR). I learnedthat 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 certainlyescape all HTML tags and entities. First, it makes sense to show thecontent to the user instead of interpreting it as control sequences.Second, I've learned on the web that rendering any user-suppliedcontent without sanitizing will result in a disaster.
Gemini is still small and friendly, but when designing software it'ssmart 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.