Soweli Lukin

On gopher conservatism

(WARNING: long, rambly, preachy content ahead)

Recently, ZLG wrote 1 about his distaste for an attitude amongst certain Gopher users that we must actively resist Gopher becoming "like the web". I would like to ask ZLG to expand on his thoughts here, because absent the context of the original discussion in

gopherproject that triggered his post, it's not perfectly clear what

sort of philosophy is being railed against. I may agree with it, or I may not. The issue of Gopher conservatism is a complicated ones. "Changing gopher" can mean a lot of things, with making changes to the base protocol and getting them widely implemented in clients and servers at one extreme, and simply changing conventions of usage within the confines of strict backward compatibility with the original software from Minnesota.

One concrete thing ZLG did mention was excessive hierarchy. I have definitely been bothered by this. The "Why is Gopher still relevant" document by Cameron Kaiser 2 that so many SDFers link to from their root menu puts Gopher's hierarchical structure up on a pedestal and says that this is why we all love Gopher, not because we're tired of the obese and distracting web. I actually don't think this is true at all for most active Gopher users today. There's not an awful lot of deep hierarchy in most gopherholes, and where it does exist it's not really that different from well-organised material on the web. While it sounds nice and clean, I do get a little tired of the old "home" -> "phlog" -> "this year" -> "this month" -> "latest post" dance. But maybe that's a flaw with my workflow, and with better use of some kind of tool like moku-pona I would be blissfully jumping directly to content.

On the question of changing gopher in general, I am not quite as conservative as some. There are a plenty of newer servers and clients under active development these days and I am not completely opposed to them doing new things which very old software can't handle. I understand some people like to surf gopherspace from very old or under-powered hardware, and a lot of this hardware may be more or less permanently stuck with old software. I would genuinely hate to see these people totally unable to browser modern gopher content at all because some massive change broke their clients, and I would oppose anything that could result in that.

On the other hand, I don't think I have a problem with lots of nice small upgrades that would just result on them missing out on little things. For example, there is a "telnet" itemtype in Gopher, and clients which support it (like VF-1) let you launch a telnet connection to some sever on some port just by selecting a gopher menu item. It seems obvious to me and not at all contrary to the spirit of Gopher that in 2018 it would be nice if the community could standardise on a new itemtype for SSH that functioned in precisely the same way. This would require no server-side changes and changing any client that supports telnet items to support SSH ones too should be a very simple effort. This would let those of us using modern clients do some cool things. People stuck with ancient gopher clients are probably also stuck without SSH clients that connect to modern servers, so they're not going to miss out on anything anyway. I may have to suggest this on the gopher-project mailing list.

So, clearly I am not opposed to all progress when it comes to gopher. However, in general I am pretty skeptical about changes to gopher beyond, perhaps, the level of usage conventions, and this actually is precisely because I don't want Gopher to end up like the web, and I am terrified of setting the community on any kind of slippery slope toward this. I'll elaborate on what I mean, at length (naturally), and this will also serve as my contribution to the recent thread of people discussing what makes gopher special to them.

Visiting a website today is basically a massive exercise in trust. I am saying to some random, unknown person: "here is my computer, do more or less whatever you want with it".

This sounds like a crazy exaggeration, but it's not really. When I send a HTTP request somewhere from within a modern browser, it is absolutely impossible for me to know in advance:

In this environment, it is impossible to make informed decisions about what happens to you on the web. The web is something that happens to you, whether you like it or not. The relationship of a modern web user to webmasters is one of subservience. The only possible course of action is blind trust. This trust can be and routinely is violated, and webmasters do all kinds of nasty shit to you every day. Some of it is "just" minor discourtesy, a total lack of common decency toward one's fellow human being, like automatically playing videos. Some of it is far more nefarious, like tracking you everywhere you go from server to server over the net, and actively countering your efforts to stop this (by e.g. using "supercookies" to replace the regular cookies you delete). This is not just a lack of decency, this is full on "act of war" stuff.

None of this is true on Gopher. When I select an item in a gopher menu I know, a priori, and with total confidence, that I am asking my computer to make exactly one connection to exactly one known server and there is no way for the person running that server to trick a non-buggy client into doing otherwise. If my client is well-designed, then I will know before I select that item whether it is going to display an image or play a sound or a video (okay, there is no standard itemtype for videos and the "binary" filetype leaves you unsure, but by current very wide-spread convention that is only used in cases where the item name contains the underlying filename so you can guess from the extension). There is no way for the person running that server to persistently store data on my drive, and there is no way for them to learn anything about anywhere I have previously been. There is nothing at all analogous to the HTTP "Referer" header, and there is nothing that facilitates an analog to the infamous browser fingerprinting. Unless my client is badly buggy, it's pretty much impossible for following a link in gopherspace to cause my CPU or RAM usage to increase more than very slightly, for a second at most. The whole thing is a short, sharp, singular event, concentrated in time, with no side-effects.

Because of this, I surf through gopherspace fearlessly, unthinkingly, with a light heart and a clear mind. I'm like a kid in a candy shop. I don't have to trust anybody at other end of a socket on gopher, because you can't hurt me here. The producer and consumer in gopherspace are on equal footing. You can offer content to me, clearly marked as to what is is, and I can consume it, or not, item-by-item, as I wish. You can point me to interesting content on other servers, but you'll never know if I follow those links, and if I do follow them, those other servers will never know where I came from.

This is what really makes gopher special to me. Yes, the content here is great, I appreciate easy navigation and I like the simplicity of the protocol and all that other stuff, I really do, but the thing I care about the most is that gopherspace is not an experience that is forced upon me, it's a safe place for me to actively explore under my own will power.

I will fight tooth and nail against the widespread adoption of any change in protocol, or software, or user culture, which I perceive to threaten this state of affairs. So, in that sense, I do believe that Gopher must not become the web, ever.

You might think I am being paranoid here and that the simplicity of Gopher means we are all safe forever from any insidious would-be spoilers of our textual haven, but it's not true, not by a long shot. Tomasino has a page in his phlog 3 about achieving persistence or sessions in gopher to sidestep the limits on applications that can be built on it. Tomasino, my friend, I am sorry to have singled you out here because I have no doubt you are not alone in thinking about this stuff, and I also don't question at all that you absolutely had not one iota of ill-intent in writing that stuff, but I must say, it scares me that you are thinking and talking like this! Trying to make Gopher stateful is kind a taboo topic to me. Yes, it can be done, and yes, it would facilitate building applications, but why do we want to build applications on Gopher? Gopher was certainly not designed as and historically has not been used as a platform for hosting applications. Gopher was designed to permit quick and easy dissemination of well-organised information. That is an important job for something to solve, and Gopher solves it well, so why-oh-why must we shoehorn it into some other role? This feels to me like very much like the first steps toward repeating the tragedy of the web.

I was really, really surprised when the folks from Bitreich - you know, hardcore minimal software elitists from Germany with high-minded principles and an honest-to-God manifesto - added a text-based "point and click" style adventure game 4 to their gopherhole which uses your IP address to maintain state between requests so that you can travel around the game, adding items to your inventory and using them later. Don't get me wrong, I love the game itself, and I've had fun playing it, even though I can't get very far. I enjoy the slightly self-deprecating nerd humour in there (your default inventory includes an "old Thinkpad", naturally) and I applaud the creativity that went into it. But come on, if those guys think that rough-and-ready client fingerprinting based on IP address is acceptable, where can we expect less principled types to stop?

The Bitreich game uses your IP address to track you through the game. This is perhaps not a big deal, because your IP address probably changes all the time, and is not uniquely tied to you because it can be shared via NAT. But there are other ways to solve this problem. There is no reason a suitably written server could not generate a random hexadecimal string everytime somebody visited the root menu, and insert that string as a prefix to all other sector paths. If a visitor, not realising these tracking strings were in there (because how often do you look at selectors before following links on gopher?) bookmarked one of these selectors, then the host would know if they returned a few days later, even if their IP address had changed. If two hosts ran this server, and knew they were both running it, they could also insert the same string into links they display to one another (hell, if this server advertised its support for this kind of tracking to other servers via a special selector, like Gophernicus' "/server-status" selector, then any time it linked to another server it could query it first and insert the tracking tag if it discovered that it would be supported). By comparing logs, the admins of these two hosts could track visitors between their two sites. This requires no change to the protocol and no change to the client, it would even work on ancient UMN gopher.

Right now there is nobody operating in Gopherspace who I believe would have the least bit of interest in doing this, but my point is that they could. It is technically possible. There is no protocol simple enough to prevent this kind of thing. The only possible protections against it are obscurity (and this will probably rescue gopher from most ills, in the end) and/or a strong, widespread and actively enforced social norm against it. This norm would have to be pretty strict. If the culture is "maintaining a little bit of state is okay if it's for a good cause", then slowly but surely, year by year, the meanings of "a little bit" and "good cause" get stretched further and further and twenty years later anything goes. This is basically what happened to the web. If the norm is "no, not even a little, not even once", then and only then is there a chance that the status quo can be preserved.

Did I say, many, many lines further up, that "on the question of changing gopher in general, I am not quite as conservative as some"? Well, maybe that's not true, maybe I'm the the most powerful God-damned force for gopher hyper-conservatism on the net. But I swear it's not dogmatic. I'm just worried about something which has already happened before happening again. I have no beef with changes to gopher that can't possibly lead us down that road. New item types, no problem. TLS support, bring it on. Anything that could conceivably lead one day to user tracking? I will come at you in a dark alley with a bladed instrument.

Soweli LukinIssuesAlex Schroeder