-- Leo's gemini proxy

-- Connecting to dgold.eu:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

2019-06-22 - More Plaintext Thinks

I'm enjoying the ongoing gopherverse discourse on a putative gopher successor. Happily, much of the conversation appears to be keeping to the ideas which I talked about in my recent post. [1]

Musings on Gopher

The key - to *me* - is that everything needs to remain focussed on content, and that content should, primarily, be text. I know that there are various discussions about the form that the text should take, and that people have expressed discomfort with the usability level of markdown, primarily based on the inconsistencies of the presentation of markdown elements.

To which I say: good! I like markdown, I find it incredibly useful. In my own professional life, I switched to an entirely markdown-based system, using the power of pandoc to properly format letters, contracts, deeds, agreements and more. That doesn't mean I'm unaware of the difficulties of using the system, I prefer plaintext, but that's not particularly useful for my usecase.

These are my personal contributions to the debate, then, for a successor format:-

The format should be as plaintext as possible.

It should not use a formatting system like markdown.

Content should remain text, and that text should be utf-8.

Links in content should be distinct from the text, they

should be presented reference-style, as in written documents.

Links in a text should be collected at the end of the document.

Menus or indices referring to a collection of documents should

remain hierarchical.

Menus which feature ascii-graphics should gracefully present a

non-ascii variant of those graphics for screen-readers and other


Access to all resources should be trivial, a resource should be

as accessible in this format as it is in gopher, using curl or

wget, even accessible to someone using telnet.

Equally, and most importantly, serving the resources should also

be trivial. Privilege escalation attacks should not be possible,

servers should not parse *anything* other than the address of a

resource, and should only provide the resource requested.

I hope that this contribution to the discussion is of value. I've tried not to be normative, but I've tried to include some things which I feel have been missed in the overall conversation.

Onwards and upwards, people!

-- Response ended

-- Page fetched on Mon Sep 20 02:49:42 2021