# The state of gopher I've become a little frustrated with gopher recently. The feelings are mixed because I'm happy there is more content, created by real people. However, many people are arriving in this space and although they bitterly complain about the state of the web, they are bringing ideas and content from the web to gopher. If you want to come to a new space, presumably because you are looking for something different, then please leave the web on the web. It's still there, you can visit any time. Just fire up that fat browser and off you go! Just please don't pollute gopher with it. ## Standards and common practice When you start in radio, or many other disciplines, you are informed of the rules and are expected to listen, to get a feel for the etiquette before you participate. Because it's so easy to fire up a gopher server or get a tilde that provides space these days, it's easy to bypass the learning phase and to jump straight in. The rules, in our case, are laid out in the RFC for gopher[1]. [1](gopher://gopher.32kb.net:70/0/rfc/rfc1436.txt) ### 70 Columns Gopher is from a time where your average terminal had a physical limit of 80 columns. To give some space for the type indicator the RFC states "the display string should be kept under 70 characters in length". Now, modern terminals are capable of more, but by ignoring this standard you make things awful for people, with older systems, or those who view in split screens[2]. It's a slippery slope to becoming like the modern web, where developers don't seem to give a crap about standards, backward compatibility or accessibility. ![2](gopher://gopher.icu/I/images/sog1.png) ### Gopher maps are for navigation, not content There is a habit forming of people misusing maps to create content pages with pseudo in-line-links, like on the web. The problem is that pages become full of info lines, which the original gopher client ignores. So when your content spans multiple pages, the original gopher client cannot page down to see anything after the first page. Another side effect of this is that, if the content is a menu you can no longer press 'd' to download it, as was intended for files. You are breaking functionality of the original gopher client, written by the people who created the gopher RFC. Doesn't that hint to you that maybe it wasn't designed for that purpose and that maybe you shouldn't do it? *clause* - I consider it excusable only for creating applications requiring interaction, as there is no other way to do it, with the proviso that links must exist at regular intervals throughout the page to ensure it remains scrollable in the original gopher client. *Addendum 05/02/2024* The RFC position on non-core item types, which includes 'i', is that the client implementation may choose whether to display them: > 3.5 Building clients > > If a client does not understand what a say, type 'B' item (not a > core item) is, then it may simply ignore the item in the directory > listing; the user never even has to see it. Alternatively, the > item could be displayed as an unknown type. To put your content within a non-core type is therefore not advised. Additionally, there is a commit[3] to the client code which notes that it was a deliberate change to "Skip over type 'i' items". Maybe they foresaw the potential for misuse, or it was already being misused, and decided to address it in this way? [3](https://raw.githubusercontent.com/jgoerzen/gopher/master/doc/client.changes) ### Gopher clients are not terminals Please do not use terminal escape codes to attempt colours and artwork in gopher. They may work in your particular client but generally they don't and look horrendous to the casual user[4] [5]. ![4](gopher://gopher.icu/I/images/sog2.png) ![5](gopher://gopher.icu/I/images/sog3.png) ## Conclusion The saddest part for me is that many of these individuals appear to be in IT or technical disciplines and have some proficiency. Unfortunately they choose either not to read the RFC, blatantly ignore it, or adhere to best practice. Don't be that person ...