(2023-04-05) Why is Gopher important to me?
-------------------------------------------
If you end up here somehow, chances are that you already had read a famous
text hosted on Floodgap, named relevance.txt and titled "Why is Gopher Still
Relevant?" I'm not going to discuss all the points made in that document and
whether or not I agree with each of them, but I want to share my own vision
on the topic and tell you why it is not only relevant, but important to me
personally.
You see, I'm now working (as a contractor) for a multinational BigTech
company that, among other things, constantly babbles about transition to
sustainable energy. The thing is, when their employees actually find
themselves under power outages, it looks like an apocalypse to them as it
turns out every single time they weren't prepared for this themselves. We
here, on the other hand, have survived over half a year of bombings of our
power grid infrastructure, yet I was able to work remotely almost as if
nothing happened. Because my own peak energy consumption never exceeded
~80W, and I was able to provide this power with several portable charging
stations during the scheduled power downtime periods. Now, if only I had _a
bit more_ solar panels than one and at least one wind generator here, I'd
cover my own autonomous electrical supply needs by 100% even during the
winter time.
But what does Gopher have to do with all this? Well, it's about reducing
energy consumption. It doesn't take a friggin' Ryzen to serve hundreds of
gopherholes from a single embedded node, and it doesn't take a latest NVidia
to create a functional browser to correctly and neatly display them. Unlike
Web, Gopher is just as usable on the 1993 hardware as it is on the current
one. It is, in fact, usable on anything that can talk plain TCP/IP and parse
tab-separated strings. It just works there. Works without the TLS overhead
(hello Gemini), without complex XML parsers (hello WAP), without client-side
scripting, same-origin policies, cookies and other nonsense that made Web
engines impossible to reimplement from scratch (if you want to support
current standards, that is) and killed all competition. Meanwhile, a
barebones Gopher client, Bopher, was written in pure Bash for educational
purposes within half a day, using just Bash's own /dev/tcp pseudo-devices.
Everything else written on top of it under the Bopher-NG umbrella, was
created to adapt this educational prototype to the actual day-to-day usage.
And it, while being written in a purely interpreted command language, still
consumes much less RAM, CPU and disk space than any Web browser in existence
for the same OS. Needless to say, Gopherspace can be browsed with no trouble
on platforms like DOS, Win3.1, OS/2, Classic Macintosh (with MacTCP),
Commodore 64 (with Turbo232), AmigaOS, Acorn RISC OS, VAX, NeXT, PalmOS...
and even J2ME. Yes, if you still have J2ME-enabled phones that support
MIDP2.0 profile or higher (i.e. expose the raw socket API), you can install
a wonderful 15KB-sized PocketGopher.jar on them (btw, I have some plans to
modernize it a bit, and if I do, there's going to be a separate post about
this effort) and have just as much of fun experience as with browsing
Gopherspace from your PCs or modern smartphones. Unlike the difference
between HTTP and WAP where everyone served different content for one and
another, here the content is absolutely the same regardless which client is
requesting it. And, since the content is basically either a binary you
directly download or a text file you display (probably with some additional
TSV parsing if it's a map), you don't need to separate the PC and mobile
versions anyway: the client itself decides how to display it best.
Speaking of mobile experience and continuing the old cellphones topic, I
won't stop repeating one thing: Gopher actually is what WAP should have
been. It offers the same content delivery and basic interactivity features
while not requiring any transcoding servers, any complex XML markup or
scripting. I actually have the first WAP-enabled phone in the world, Nokia
7110, and one of the first GPRS-enabled phones in the world, Nokia 8310, in
my collection. And I can't imagine how much faster the 8310's browser would
have been and how much less battery charge it would consume if it just used
Gopher with its dead-simple request-response flow instead of
WML/WMLC/whatever else it has there. Same about the plague of the following
decade, Opera Mini. One could just avoid so much trouble with that
transcoding overhead and everything. Besides, having all my internet traffic
fully processed unencrypted with a centralized third-party proxy makes me
feel much more uneasy than knowing that only my mobile carrier can see it.
But then, WAP was just gone with (almost) all its WML sites and carrier
transcoders. And the number of WAP/WWW sites I can currently browse on my
Nokia 8310 (which is still working) is next to zero. With Gopher, this
planned obsolescence can never happen. My point is, any client (or even
server) device already considered useless for Web is still useful for
Gopherspace.
But why, may you ask, is Gopher the primary focus of my attention here, and
not FTP, IRC and other similarly ancient protocols? Well, unlike IRC and
Telnet, it doesn't require us to constantly maintain the TCP connection.
And, for instance, whenever GPRS disconnects on the phone I use Pocket
Gopher on, I don't need it until I make the next request (again, saving
precious battery life). Unlike FTP, it doesn't require setting up two
different ports for control and data transfer. Unlike email, it doesn't
require setting up a store-and-forward facility that provides two completely
different services to send and receive messages. The only other protocol on
par with Gopher I can think of is Finger... well, because technically it is
absolutely the same protocol, and any Finger query can be represented as a
Gopher selector. To me, Gopher looks like the perfect balance between the
human-scale level of implementation from bare TCP stack, frugal computing
and functionality for everyday usage under even the harshest conditions of
network connectivity.
This is why I consider Gopher important to me, as well as to everyone else
who wants to be prepared and to actually make some move towards reducing
their own energy footprint and overall consumerism. If you're reading this
via a webproxy, go ahead and install a proper client. Stop babbling, start
acting.
