Re: The state of gopher This is in response to a post that recently made the rounds in the gopherspace and generated some interesting discussions - see the end for some links to replies by other folks. gopher://gopher.icu/0/phlog/Computing/The-state-of-gopher.md Note: the below are merely my own thoughts and opinions on the subject, and I'm not trying to discount others' or force mine onto them. Also, I won't repeat the original post here, so if you haven't read it already, please do so, then come back for the remainder of this post. Like most of us folk who are into gopher, small net/web, etc., I share the author's frustration with the modern web of nonsense. Though I, too, have previously found myself a bit frustrated at folks bringing web-isms to gopher land, I think it's important to remind ourselves that the web may be all someone has known so far, and seeing things done a certain way for years on end definitely skews/influences one's frame of reference, and it may not be immediately obvious or imaginable how to do things differently. We should welcome people, and perhaps point them to some gopher resources to learn more about it. Then, given time and exposure, they will most likely develop that intuition for how to do things "the gopher way". Still, we are all different humans living our own lives, so there will ultimately be variation and diversity, which is part of what makes it all fun anyway! The original post argues for adhering to the letter of RFC 1436, and using it as a reference and treat it all as hard rules to be followed. While I agree that standards and rules are generally set to be followed, it needn't always be so 100% of the time. [Some] rules are arguably meant to be broken, and that's one of the things that makes art so great and makes life interesting. The Rule of Thirds in photography is a very powerful tool in a photographer's toolbox, but it should be just that: a good tool. Imagine if every photographer always composed all of their shots to strictly follow the rule of thirds. No artistic expression. Where would the fun be in that? As others said, RFC 1436 was sadly never extended/updated to meet the changing world and people's needs. For example, the RFC being written in the early 90s, it naturally only mentions the ASCII character set. Should we *only* use and permit the use of ASCII? How about people like me who speak languages other than English, whose alphabet is not in the ASCII range? Should they be required to use base64 encoding, quoted-printable encoding, or something along those lines when publishing documents so that they remain technically compliant with the RFC? Or perhaps have them serve their documents as type 4, 6, or 9, and thus no longer directly readable text otherwise ;-)? It seems more sensible to try to UTF-8 decode where possible, than demand someone use an absurd binary encoding or outright not publish text in their language over gopher if their alphabet isn't part of ASCII. That would sound a lot like exclusionism rooted in technological purism to me. UTF-8 being backward compatible with ASCII, it's possible to add support for it without breaking things for the users of the ASCII subset. I believe as long as something can be achieved in a reasonable, backwards compatible way, there is no reason we shouldn't at least consider it. Regarding 70 column lines, though my personal preference is also to hard-wrap lines at 70 characters or less, I wouldn't impose it as a hard rule. That said, considering many people like to browse gopher on their mobile devices with smaller screens, I believe a good mobile gopher client should have a toggle for treating hard line-breaks as soft ones in each paragraph, i.e. render text as unwrapped, to avoid the ugly wrapping on the smaller screen. Similarly, I don't object to use of 'i' item types for displaying text in directories/gophermaps, even though it does make it more challenging to deal with text. But there's no reason that gopher clients shouldn't make it possible/easy to interact with links in plain text files (type 0) by linkifying URL-looking text throughout the file. I think if most gopher clients implemented this, it could effectively eliminate the need for serving plain text files as type 1 just to get clickable links. Chief among the reasons why I love gopher is that it's simple, and puts clients in a position to be able to enhance the user's experience, rather than dictate the publisher/server's wishes onto them. This puts the power in the rightful hands of users. In fact, the early web and its browsers were exactly like this: > The beauty of this approach is that it allows maximum openness > and flexibility. All World Wide Web documents are similar, > but every World Wide Web reader, or browser, can be different. -- Gary Wolfe - https://www.wired.com/1994/10/mosaic/ > With the first version of Mosaic one could choose link colors. > Later, NCSA Mosaic allowed to decorate links in many different > ways and choose colors from an RGB palette. It was the highest > moment of "preferences freedom" a user could have. -- Olia Lialina - http://contemporary-home-computing.org/prof-dr-style/ I believe that if we could help more people discover and realize this, it could make for a catalyst for more widespread change. It's also worth considering that while gopher is an excellent medium for this, it does not have to be (and indeed is not) the only path to that destination. The idea of putting the power in the hands of users could well be applied to web sites as well. With the web, however, it would be crucially important to avoid imposing the use of JavaScript for users to simply read the page. A page should be a document to view, rather than an arbitrarily complex program sent to be executed on the user's machine. I think many people who discover gopher come to like it or at least some of its ideas, and for good reason ;-). For me, part of what makes gopher great is the community and the people. So why exclude others when we could happily have them? If we strive to be a welcoming community, we can foster a kind and positive space that people enjoy participating in, and also increase the odds of our community's longevity. It would be heartbreaking to not get to enjoy the contributions someone could have made because they were excluded. Let's work on making sure that doesn't happen :-). What do you think? I'd love to hear your thoughts and comments. Feel free to write to me at bandali@kelar.org - or better yet, write a phlog post about it and email me the link. Thanks to Jason Self for reading this post and providing feedback. Take care, and so long for now. -bandali, 24feb24. Other responses: gopher://gopher.black/1/phlog/20240205-re-the-state-of-gopher gopher://gopher.unixlore.net/0/glog/response-gopher-icu-state-of-gopher.md gopher://zaibatsu.circumlunar.space/0/~tfurrows/phlog/2024-02-07_reStateofGopher.txt gopher://sdf.org/0/users/gallowsgryph/phlog/2024-02-08_state_of_gopher.txt gopher://aussies.space/0/~freet/phlog/2024-02-11.3In_Defence_of_UMN_Gopher.txt gopher://tilde.institute/0/~screwtape/185236250-restate-of-the-gopher.txt