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