(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.

--- Luxferre ---