---------------------------------------- | |
re: The state of gopher | |
February 05th, 2024 | |
---------------------------------------- | |
IanJ of gopher.icu wrote a quick rant on things that bother him | |
about the current state of gopher[0]. In short, line length, | |
misuse of type i, and escape codes for things like color | |
deccoration. We run into this sort of gopher purism a lot in the | |
bitreich community. It's not new, and it's also a perfectly fine | |
opinion. I just don't share it. | |
[0] The state of gopher | |
Lets talk about the three mentioned things in turn: | |
First: Lines should be 70 charactes or fewer. | |
This is indeed in the spec, and it was the impetus for my choosing | |
sixty-seven as the line length I use here on gopher.black. But in | |
general a line length of 80 or fewer characters won't cause | |
problems for anyone on a desktop and a line length of 67 is still | |
far too wide to be useful on mobile. So what are we to do? | |
Some people forgo wrapping at all, assuming clients are capable of | |
wrapping if they're sosphisticated. Others pick a comfortable | |
middle-ground (often 80) and stick with it half out of convenience | |
and half because it's good enough. Still others who use gopher on | |
mobile choose to go crazy and use very narrow posts that fit those | |
screens. | |
To the spec it's wrong, but the spec doesn't have feelings. The | |
spec doesn't use gopher. If someone is on their phone and very | |
narrow lines make their use case better then that's absolutely the | |
right call. At the end of the day it just isn't very important. | |
Second: misuse of type-i | |
From a historical perspective type i wasn't even in the spec, but | |
it was already in widespread use in gopherspace within the first | |
year of its launch. Clients adjusted, use adjusted. RFC-1436[1] | |
never learned to time travel, though, and remains sadly silent on | |
the topic. | |
[1] RFC-1436 | |
Why use type i gophermaps for things like this phlog? It makes it | |
easy to link to things, like the RFC above. I could drop in | |
a gopher URL instead, but wait... those didn't exist when RFC-1436 | |
came out either. So should I instead list a selector, server, and | |
port? Oh, I better indicate a type as well. No, that's silly. Even | |
though the URL scheme came later it's a useful convention. It | |
makes it easier for other people. See where I'm going? | |
So why NOT use type i in this way? Well, two reasons. First, it's | |
harder to lay out. Working in gophermaps is nasty business. | |
I wrote a tool[2] to do it for me. Without that I wouldn't do it. | |
It's easy to screw up and awful to edit later. Easier just to | |
write plain text, and plain text is sufficient. | |
[2] Burrow | |
And the second reason? Very old clients like the original UMN | |
gopher client don't work well with them. | |
Thankfully very few people use that client anynmore because it's | |
pretty janky and has barely been maintained. Last I heard it was | |
in search of a new maintainer, actually. And these days we have | |
a wealth of new clients that are simply fantastic. We have the | |
near-ubiquitous lynx which does a fair job, though notably is | |
converting to HTML under the hood. But the bitreich community | |
mentioned earlier has led to the creation of at least two gopher | |
clients I know of that match that gopher purist philosophy. We | |
also have VF-1, a lovely python client that inspired a fork for | |
offline browsing of the whole small internet, and another fork for | |
gemini. Bombadillo is fun, and there's my most recent favorite, | |
phetch. Lots of options all with better features and better | |
handling of gopherspace. | |
For me, the benifits of being able to link within the documents | |
outweighs the negatives. The format is subverted with my tooling, | |
and I don't feel the need to lower my gopher content to an ancient | |
client when there's so many easy alternatives available. | |
Third: escape codes | |
Here's I'll agree partially. gopherspace shouldn't assume terminal | |
environments. Remember the phone users earlier? Generally speaking | |
it's safer not to do so. But that being said, some places in | |
gopher space are not just gopher holes. They're not just phlogs. | |
They are art installations. They are pushing the boundaries of | |
what's possible and what's decent because that's what art does. | |
I am of course thinking primarily of cat's baud.baby[3] here, but | |
there are some other gems around as well. They blow my mind when | |
I see what can be created in this long forgotten corner of the | |
internet. | |
[3] baud.baby | |
But it's only visible in certain ways! Yeah, that's true. You | |
might stumble on there and go, "AHH! What a mess!" and miss out on | |
the awesome. That'd be too bad. If that's the case you should grab | |
phetch and try again. It's worth it. Maybe not for all of gopher, | |
but for this particular thing. Keep doing what you're doing, cat. | |
Gopher is a pretty cool thing. It's got limits that make it | |
awesome because it forces us to focus on content most of the time. | |
Those limits aren't the point, though. The place it leads us to | |
are the point. If we disagree on some of the details getting | |
there, so be it. After all, this is in UTF-8, not Latin-1 as the | |
spec calls for which lets me do some great things, like share | |
music for the shakuhachi[4]. | |
[4] Shakuhachi Music Guide |