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