# Gopher and the Lynx Web
April 20, 2019 ยท 7 minute read
Posted in: gopher web lynx retrocomputing
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][0]. 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][1]. 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][2] 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][3]. 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][4], 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][5] 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][6], 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][8] 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][7] 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][9].
### 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.
[0]:
gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/pondering-whats-inbetween-gopher-and-the-web.txt
[1]:
gopher://fuckup.solutions/1/enkiv2/avoiding-the-gravity-hole-of-webbiness-in-gopher
[2]:
gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt
[3]:
https://lynx.browser.org/
[4]:
gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/on-gopher-conservatism.txt
[5]:
https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
[6]:
https://brutaldon.online/
[7]:
https://www.dillo.org/
[8]:
https://tildegit.org/solderpunk/shizaru/
[9]:
https://intercoolerjs.org/
