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]
 
 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
   use-cases.
 - 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!
 
 ________References________________________________________________
 
 [1]     gopher://ascraeus.org/0/phlog/015.txt