Pondering what's inbetween Gopher and the web
---------------------------------------------

I'm not quite sure what got me thinking along these lines, although
I am sure that recent gopher content from somewhere in circumlunar
space played a contributing role.  Oh, most certainly by cleber's
urbe project[1].

It's no secret, of course, that I love gopher.  Some of my reasons
are outlined in previous writings[2].  And it's neither a secret that
I hate the web, or at least it's modern incarnation.  Both of these
things can be, and are, true while I still believe that Gopher is
not perfect and has shortcomings, and there are things about the
web experience to miss when one surfs on port 70.  So lately I've
been thinking about "the space inbetween", about hypothetical dream
protocols which are more than gopher but less than HTTP.

Maybe this is strictly a thought experiment.  Maybe not.  The number
of people using gopher, and writing new gopher clients and even
servers, is probably growing, right now, at the fastest rate
it has in decades.  If we hit upon a really nifty idea, I don't
think it's inconceivable that usage of *that* protocol could soon
reach the levels that usage of gopher was at even five years ago -
i.e. super rare and niche, but definitely not totally absent.

As a first contribution to this line of thinking, I have come up
with a protocol which basically consists of three small changes
to gopher which address what I *think* I currently believe are its
three greatest shortcomings.

The first change is that TLS encryption of all connections is
mandatory.  No two port cleartext/cyphertext distinction like HTTP
and HTTPS, no upgrade from cleartext using STARTTLS, just secure
connections from the get go and that's it.  But, no certificate
authority system like in HTTPS to complicate things (well, actually,
this is really a client implementation detail and not a part of
the protocol and cannot be enforced).  Instead, I would advocate
a simple TOFU[3] model based on certificate pinning, more like SSH.

The second change is that the standard non-directory item type
is not a plaintext file, but a text file in some very lightweight,
human-readable markup language which supports inline linking to other
resources.  I don't yet have much in the way of ideas or thoughts on
what this markup language should be.  The main motivation for it is
to introduce "real links" to gopher documents, so that people don't
have to abuse the 0/1 type semantics.  I wouldn't object to there
also being support for minimal text formatting (e.g bold, italics).
Certainly no inline images.  Because of this change, a new image
type for "real plaintext" which need to be added.  This change was
inspired by discussion with uwu on the circumlunar IRC network several
weeks back.  uwu was shocked to discover that the
square-bracket-and-number style "linking" system that is widely used
in the phlogosphere is not an official part of the gopherspec with
wide client support, but actually just a matter of convention and that
gopher text files themselves have absolutely no concept of links.

The third and final change is the introduction of an item-type
which means "interpret this selector and interact with it in some
way determined by its schema".  The 'h' item-type already plays
this role for many more advanced clients, if you put a "URL:" in
front of the selector, but this is IMHO an ugly hack which really
spoils the clean semantics of the gopher protocol.  And item-type
of 'h' is supposed to and *should* mean "this is a HTML file", and
item-types shouldn't do double duty as it defeats the point of them.

This set of changes fixes a few gopher shortcomings, and it does so
without introducing anything nasty.  The amount of effort required
to modify existing gopher servers into servers for this protocol,
if they are written in languages with a good TLS library, is very
low indeed.  In many cases it could probably be done in a weekend.
Perhaps even better, it should also be very easy to modify gopher
servers to handle both gopher *and* this protocol simulaneously.
The same "type 0" content could be served for both protocols
without any transformation, since the new protocol's lightweight
markp language is supposed to be human readable.

Does this idea interest or excite you?  Offend and disgust you?
Do you just wish gopher people would stop using gopher primarily to
talk about gopher, so we don't end up being the FORTH of internet
protocols?  I honestly get that concern, and share it, but had spent
long enough thinking about this that I felt it was worth sharing.

[1] gopher://republic.circumlunar.space:70/0/~cleber/phlog/2019-01-18-the-urbe-project--back-to-c.txt
[2] gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/on-gopher-conservatism.txt
[3] https://en.wikipedia.org/wiki/Trust_on_first_use

You are viewing proxied material from zaibatsu.circumlunar.space. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.