re:State of Gopher 02/07/24
----------------------------------------------------------------------
You saw that post on the State of Gopher, right?[1] This response
provides some meandering thoughts on the subject, and should be taken
with the lightness which ought to accompany participation in ancient
internet protocols. I use gopher for pleasure and on my own terms, and
am grateful that others do the same. It's more fun with more people!
So in spite of the subject at hand, I hope you'll do whatever you like
with Gopher; I look forward to seeing the results.
***
IanJ spoke about rules and etiquette, which was a little confusing
to me. I understand that our RFC 1436 serves as the de facto standard,
but I'm not sure it defines as many rules as we think (we'll have to
get to etiquette later as a separate issue), and I'm certainly not
convinced it should be taken as immutable or sacrosanct. Take the "70
Columns" (more properly 70 characters) debate as an example; the RFC
mentions this twice, it seems, and in both cases it uses the word
"should". But let's look at the spec word for word:
----
3.9 User display strings and server selector strings
User display strings are intended to be displayed on a line on a
typical screen for a user's viewing pleasure. While many screens can
accommodate 80 character lines, some space is needed to display a tag
of some sort to tell the user what sort of item this is. Because of
this, the user display string should be kept under 70 characters in
length. Clients may truncate to a length convenient to them.
----
"Typical screen" and "viewing pleasure" stand out to me, the first
being a very fluid concept, and the second being wholly subjective.
The observation about 80-character screen lines is a relic from the
date of publication, which peer-review should probably have eradicated
if the protocol were to be future-proofed. But section 3.9 matters
very little, ultimately, since all it does is suggest that display
strings "should be kept under 70 characters in length". There are no
demands, and no consequences.
Tomasino said this on the subject: "...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."[2]
I agree with him. I'd argue that the RFC ought to be updated, but as
it will not be updated, I'd suggest reading 3.9 as-is, and not
interpreting it as a specification, only a suggestion.
Of course all of this is null and void when you're talking about files
that are accessed using gopher, such as IanJ's .md file... the spec
doesn't suggest that a text file retrieved using gopher should be
limited to 70 characters in length! Only user display strings.
Consider that... this .txt file and IanJ's .md file are entirely
outside the scope of RFC 1436, which never sought to control every
file accessed through the protocol.
Moving on, the arguments about "gopher maps" and "info lines" were
interesting, given that the RFC doesn't talk about such things. At
best, the 'i' item type is a "local experiment" in the scope of the
RFC. Or, you could view it as an experiment that was adopted into the
practical standard, along with URL schemes (as Tomasino pointed out);
One would be foolish to argue that 'i' should be ignored, given its
ubiquitous nature in modern clients, so the question becomes its
proper use. The practice of keeping content in gophermaps is not
universal, but it's not rare either--there I also say, let people suit
themselves. There are no actual rules around 'i'.
In several places, IanJ references the behavior of "the original
client" as if it were part of the standard. This appeal to antiquity
doesn't make much sense to me. The original client was what introduced
me to gopher--but I don't see the value in using it as a standard
today. And though I enjoy retro-computing on old hardware, I don't see
much point in attempting to create a culture of limitations around it.
Even on my 8088, I wrote a new DOS client that works better with
gopher as it presents itself these days.
Let's finish by returning to etiquette, or the "conventional
requirements as to social behavior; proprieties of conduct as
established in any class or community or for any occasion" (from
dictionary.com). Social conventions are as burdensome as they are
vague. Why take offense at some perceived slight, when the other party
may have absolutely zero notion of having offended? Recall also
that internet-connected societies span real-world cultures; that
multi-cultural reality means patience and understanding are paramount.
The responsible and proper gopher citizen doesn't demand that everyone
view things their way, rather, they enjoy the vast connectivity and
the creative outcomes that our differences produce. That, to me, is
proper etiquette.
Thank you IanJ, for bringing the subject up.
[1]
gopher://gopher.icu/phlog/Computing/The-state-of-gopher.md
[2]
gopher://gopher.black:70/1/phlog/20240205-re-the-state-of-gopher
