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