Avoiding the gravity-well of webbiness in gopher

Avoiding the gravity-well of webbiness in gopher

A response to Pondering what’s inbetween Gopher and the web <gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/pondering-whats-inbetween-gopher-and-the-web.txt>

With regard to formats:

The author suggests that the ‘default format’ should not be ‘plaintext’ but a ‘minimal markup’. Gophermaps are, in fact, a minimal markup. They are suitable for adding links to gopher documents. We ought to write new documents as gophermaps. Writing documents as gophermaps is in line with the general gopher philosophy of: if you’re not gonna do it cleanly and easily, don’t do it at all.

Any markup format that supports more features than just links is a waste, particularly if we build it from scratch. Gophermaps are an ideal compromise, because only links are supported, and because the line-based structure prevents the overhead & complexity associated with most forms of embedded markup (for instance, no complex escaping is necessary because links can only occur at the beginning of lines). Markdown would be a step down here.

The primary feature that the author suggests as a driver for this format change — protocol and media type selection — is already fully supported in vanilla gopher.

With regard to TLS:

I’m not sure whether or not encryption for gopher makes sense. Gopher is mostly static (though it needn’t be) & the absence of encryption means authentication is off the table as a driver for dynamic content. We should never send sensitive data through gopher.

Now, TLS doesn’t protect the bits of information that maybe might be sensitive in the context of a static retrieval: the endpoints. (It protects particular requests, and maybe if you keep a ‘secret’ document around on gopher TLS will protect you from man-in-the-middle attacks, but why would you do such a thing? In particular, why keep an unencrypted document on public gopher & expect to keep the key to access it a secret?)

Right now, nobody pays much attention to gopher traffic. If they start, it will be because all these weird politically-radical nerds are using it, & rather than being content-focused it’ll be blocks or monitoring of who is using the protocol at all (like bittorrent).

We know what happened when the web got crypto support: Extremely quickly, it also got for-profit sites (because you could enter credit card numbers), access-gating, registration-walls, and client-side scripting (to log people out so reg-walls and access-gating worked better).

My take on how to encrypt gopher is: Gopher itself remains plain-text, but encrypted proxies exist that can nest encrypted payloads in gopher requests & nest those payloads inside more layers of proxies (like TOR). Connections on either end are plaintext. This doesn’t protect content except insofar as content can be used to identify the path from origin to endpoint (and thus deanonymize traffic).

In general:

Folks only bother to use gopher because the web’s design philosophy doesn’t suit them. Those who would like to extend gopher ought to think critically about which elements of gopher’s underlying design philosophy are valuable. After all, the web is the way it is because of an absence of this kind of deep thought in favor of a seemingly-pragmatic short-termism — one that ultimately favors the desires of developers and the corporations that employ them over the needs of users.

Gopher is pragmatic in a different way: it does not favor what can be incrementally added to existing systems, but what could be useful without making it substantially harder to produce a new client or server from scratch. As a result, gopher has very few of the features that sound interesting in the short term but are nearly impossible to get right or make non-toxic in the long term.

Gopher is the forth of internet protocols not because the user community is the same as the developer community (since the same is true of basically every small platform), but because the developer community prefers to cut out conceptual and code complexity even when the result conflicts with the assumptions of casual developers — to favor making understanding the whole stack easier, even at the cost of initial difficulty for newbies.

This makes it harder for folks to unilaterally add features that users don’t need or want: lots of folks need to independently decide that a feature is worth implementing on the client or server they developed (or worth doing by hand if they use netcat or telnet to browse gopher). The ease with which gopher can be implemented keeps it small, and that smallness keeps it easy.

(This article is mirrored on gopher at <gopher://fuckup.solutions/1/enkiv2/avoiding-the-gravity-hole-of-webbiness-in-gopher>)