An Inhabitant of Carcosa

As part of the ongoing revitalization of gopher, there has been quite a bit of discussion about what, exactly, is good about gopher, and whether you can separate that from what’s bad about the world wide web. From another angle: are there good things about the web that we can import to alleviate gopher’s shortcomings?

The discourse

A recent thread of that conversation has been an exchange between ~solderpunk and ~enkiv2. Solderpunk opened with an article titled Pondering what’s inbetween gopher and the web. They suggest a new protocol that is gopher-like, with a few changes.

1. Everything goes over TLS, but with key validation based on TOFU and certificate pinning rather than CAs.
2. Text files are expected to have simple markup such as Markdown for links and minimal text formatting.
3. A URL-like selector type, where the client interprets and acts on the selector according to its schema.

Note that all of these except transport encryption are backwards compatible with existing gopher, at least in the sense that they would degrade gracefully in clients that didn’t support them.

Enkiv2, a critic of not just the modern web, but the early web, too, responded with an article titled Avoiding the gravity well of webbiness in gopher. This article was originally published on Medium, but I have linked to the gopher mirror.

He argues that the link-supporting plain text markup that you should use for gopher is gophermaps, and that any more formatting would be a waste. He also argues that there is no need for an interpretable selector type, because you can always just add more selector types instead (if I understand correctly).

Finally, he is lukewarm on the idea of transport encryption for gopher, thinking that it is mostly unnecessary, and, on the web, was one of the key enablers for hypercommercialization.

The transport encryption issue has been addressed by solderpunk in response to other people previously saying much the same thing as enkiv2. I’m not going to add anything to that reply.

The main thing I want to point out is that all of the changes that solderpunk purposes are basically responses to workarounds that are already in use in the gopher community and which are basically dirty hacks.

The first of these is using gophermaps as a crude form of hypertext, which solderpunk describes as abuse of the 0/1 type semantics. The way I understand it, gophermaps are primarily a way of adding formatting to directories, not to documents. If you do use them to mark up documents, you run the risk of someone reaching your document from a directory that serves it with a 0 selector, and the client fails to interpret it as a map. The end result of links on footnotes is satisfactory if it’s done right, but it’s not always done right.

The other issue is abuse of the html document selector ‘h’ to serve arbitrary web content or alternate URL schemas like “mailto”. We see hacks being used here presumably because the needed client updates to add selectors seems out of reach. By trying to avoid these hacks, which are in common use,, solderpunk is in some ways being more conservative than enkiv2’s call to avoid the gravity well of webbiness.

The Lynx Web

But let’s say, for sake of argument, that we do not especially want to avoid webbiness per se, but just the abuses of the modern web. The way selector semantics are abused in practice shows that current gopher users do want these features, and it makes sense to design them in.

I, personally, enjoy a minimalist website designed for Lynx than I do a gopher hole, generally speaking. So what if we looked at the question of what’s between gopher and the web from the perspective of how we can remove unwanted things from the web rather than how we can add usability fixes to gopher. I want to call this web minus the Lynx Web, because I want to emphasize the pleasure of reading well designed web pages in the Lynx browser. There are other text browsers, but Lynx is in some ways the most constrained, and some of the things I’m going to propose are more constrained than what Lynx offers.

The most restrictive profile

This is a profile for the Lynx web that I want to propose meets most of the things that solderpunk considers important to gopher in gopher conservatism, while still being distinctly “webby”.

1. No JavaScript. This almost goes without saying, but the Lynx web is a document retrieval system, not a client side application platform. Besides this basic philosophical difference, JavaScript makes everything bad. It takes basic client capabilities like styling visited links and weaponizes them against the user.
2. No server provided stylesheets. This ensures that the user experience is consistent between sites and under the control of the user. There may be client provided stylesheets, to suit the user’s typography preferences or accessibility needs.
3. No inline or background images. This, along with no server stylesheets and no JavaScript ensures that one user request (following a link or submitting a form) corresponds to one web request. This means the consequences of clicking on a link are predictable.
4. No cookies or other forms of user tracking. Note that this is more restrictive than actual Lynx, and would make some reasonable uses of dynamic web pages, like my own brutaldon, impossible.
5. The set of request and response headers is strictly specified and not extensible. This means that cookies cannot be snuck in via the back door.
6. The transport protocol is a strict subset of HTTP 1.0 (not 1.1), optionally over TLS.
7. The native document format might be a large subset of Markdown rather than HTML, for friendliness of authoring. The early web used HTML primarily in the expectation that pages would be authored using SGML-aware tools, but in practice that was never true.
8. Tables are supported, but with no server control of formatting, so tables cannot be used for layout.
9. Forms are supported.

Except for item 7, this profile could be realized by restricting what servers send, without any client changes. Solderpunk’s Shizaru web server could be used to impose those limitations.

A less restrictive profile

This less restrictive profile includes things that I consider good, but which could be abused for evil purposes. It enables server side applications, as long as they are basically dynamically generated documents. Consider it a diff to the restricted profile.

1. Inline images are allowed, but only as figures. There is no server controlled way of controlling their size, positioning, etc.
2. HTTP Basic-Auth is supported.
3. A single header, Session-ID is added. This works as a restricted subset of cookie functionality, allowing anonymous or authenticated sessions, but not allowing any other data to be stored on the client. There’s no expectation that session tokens be stored between browser sessions.

This profile, except for the restricted cookie header, is basically supported by most text browsers and simple graphical browsers like dillo today.

An alternate future profile

I’m not perfectly convinced that these restrictions are the best possible future for the Web. Imagine that, instead of JavaScript, we had seen rich declarative enhancement of HTML for the purpose of adding interactivity. I am not going to attempt to specify this profile, but the general idea is similar to what is currently implemented for JavaScript browsers by intercooler.js.

Not a conclusion

There’s clearly a wide range of possibilities between the most strict interpretation of gopher and the most ad-riddled, surveillance-funded single page app, and I don’t think that it’s a simple slippery slope from Lynx to Chrome. I think that “webbiness” is not intrinsically bad, and it’s something that the modern gopher community might like to recover from its current state rather than rejecting altogether.