I finally feel like making another blog post! This marks the first for 2024! Crazy!
If you haven’t heard of Gopher before, you aren’t alone. Gopher competed against FTP and HTTP during the race for the web, and as you can guess, lost. Gopher is an interesting hybrid between the two. Like ftp, it is designed primarily to share files and organize itself like a directory, but unlike HTTP, it offers no markup language to make descriptive pages. Gopher instead decides to send a single character before the name of the file, this character denoting the type. They range from 0 as “text file”, to 7 as “request for text query”, to more modern additions like I for “image” and are always treated as links. There is one item type that stands out though, and that is the i selector.
i is a nonstandard item type which was added to Gopher’s common vernacular at some point between its inception and the current year. It is not specified in the RFC, but is unanimous enough to get a spot on the Wikipedia page. It has become one of the most widely used item types and appears on most modern Gopher sites, including my own. It stands out from the other item types however, as its not meant to be displayed as a link, but rather a line of standard text. This makes it very confusing as to where it fits into Gopher as a whole.
HTTP is a protocol about sharing files and documents, however somewhere along the way, it became a platform in its own right. The days of serving static documents over the wire has given way to fully fledged applications running over what amounts to a network connected virtual machine. A program capable of downloading and running code from anywhere, and doing so in a (mostly) platform agnostic manner. With its meteoric rise and ever expanding feature set, many people have decided to go back and give Gopher another shot. These people however, intentionally or not, are bringing HTTP habits with them.
If you look at any Gopher site created in the early days of the protocol, you’ll notice something. It effectively acts as just a public FTP service. You are simply presented with a file index and a list of files and directories. Despite this, like on FTP, people still hosted informational content, programs for download, and a facsimile of what would become blog posts. To view these files, one would simply download it to their computer, and open it with a dedicated viewer.
If you juxtapose that to a modern Gopher site, created within the last 10 years, one thing will stand out almost immediately. The mixing of content with directory listings. Just like HTTP has evolved in its time, Gopher has also evolved and changed, and this change has fundamentally altered how Gopher sites look and act. If one navigates to a Gopher site now, they are able to read information and follow links directly under or above them. They are able to see a message of the day, or a brief introduction to what is stored in a directory. Gone are the days of “README.txt”, presenting information to the user is now easier and more commonplace. This is partially the reason for the i item type’s widespread popularity, it is a really useful tool.
The i item type’s use however, varies from site to site. As of recent, I’ve noticed an uptick in sites using the i item type in place of a traditional text file for relaying information. This is an interesting change for multiple reasons. Traditionally, Gopher relied on the client just for getting files, not viewing them. When HTTP became the universal protocol, most browsers implemented some way to view various files in the browser, and suddenly it became a requirement to read text files in a browser. When many went from HTTP to Gopher, they seemingly brought this sentiment with them, and would rather have the client display their information than rely on a client to download and read it.
Another interesting idea becoming common place in Gopher is adding links to text content pages. Gopher has no concept of a “page”. Instead of a page, when you view a Gopher site, you are viewing a “Directory”, functionally no different than typing “ls” in FTP. Any other item type is simply a file or redirection to another service (or in the case of item type 7, a request to a directory). The introduction of the i item type allowed directories to suddenly start acting as files, but with more features. In a directory, you can link somewhere; in a text file, you can’t. Some modern Gopher blogs I’ve seen completely forego the humble text file all together, opting instead to use directories for posts since they can curate a collection of clickable hyperlinks, or even just to have the option to do so. Now what would traditionally be a directory listing has turned into a pseudo-document-markup-language, an interesting shift.
This of course begs the question “is this a good idea?” The only major downside of doing this is just that older Gopher clients won’t be able to render your page. Anything from Internet Explorer 6 to NCSA Mosaic will think your page is full of broken directory links, since they predated the i item type. However, modern Gopher browsers like lynx or even Firefox 3.5 can display i types just fine. The most interesting dilemma is simply “is this intended?” On one side, the i type has become the second most used item type, therefore it has cemented itself in the protocol. On the other, Gopher is a protocol for sharing files, writing blog posts in it is not intended behavior. If we stick to intention to dictate what we do with a protocol however, most of modern HTTP would need to be thrown out, since HTTP was designed to serve documents, not applications.
In my humble opinion, the Gopher “i” type is alright. I like and use it actively. In my eyes, it acts more like an FTP server’s MOTD, or Message Of The Day, than a markup language, but it is very helpful for demarcating sections of files, or introducing a common theme they have. However, I also see the limitations of this item type. I do sometimes use older browsers on older systems, and Gopher makes a really nice transportation layer between older and newer systems, since it doesn’t use any form of encryption what so ever. These older browsers do not typically handle the i type correctly, and usually display the entire page as a mass of links. While the content is still fully readable, it suddenly becomes harder to distinguish what a real link is and what a broken i type is. For blog posts and longer form text content, I feel the simple text file is still the best option. In this way, you don’t break your content on older browsers and it remains accessible for everyone. Ultimately, I don’t care what anyone does with their Gopher site. The vast majority of people use modern Gopher browsers that can handle anything. Most modern Gopher users use it as a refuge from the modern web, but still want the mixed media features that come with it. Who’s to say they can’t use Gopher as their own mini-HTTP.
In conclusion, Gopher has lived a pretty interesting life, and with that life has come many changes. While the i type was not specified in its original RFC, it has cemented itself as one of the most widely used types. The use of this type however has seen some fundamental changes to how Gopher sites were intended to be designed. While it may not be supported historically, it has transformed Gopher from a file transfer protocol to one with a de-facto document language. A change that says more about how our use of the internet has changed more than anything.