Linkification in Gopher clients ๐Ÿ”—

[โœ 2021-21-16] There is a 'slight flaw' โ€  with the argument in the following post. ๐Ÿ˜‰ That said, it might still be worth a read if you use (or make) a Gopher client that does not provide an easy way to follow links written in pure text documents.

โ€  I should learn to do more research


Every few years I have a look around Gopherspace, just to see:

Is was via one of these recent journeys that I discovered Gemini. ๐ŸŽ‰

My history with Gopher and Gemini

But Gemini wasn't the only thing I noticed. Something I saw a lot in (pure) text files served via Gopher, were links done like this:

You should check out this cool site[1] immediately!

[1] gopher://

or like this:

You should check out this cool site <gopher://> immediately!

or sometimes even just:

You should check out gopher:// immediately!

When you encounter these you need to select the URL and manually enter it into your client to navigate to the site in question (at least in the clients I have tried thus far). I can't help but wonder why I need to do this manual step.

To be 100% clear I am not really talking about making something like "[1]" in the first example clickable, and I am certainly not suggesting that the client should attempt to fully render (or understand) the highly variable possiblities of free-form, text based formatting. Noโ€ฆ I just mean finding links and making them navigable (i.e. "gopher://" above) using the same conventions the client uses for following links in gophermaps, without the need to "copy and paste" the URL back into the client. This (to me) is "Linkification".

I assume that pattern matching a URL is not that difficult. Or perhaps it isโ€ฆ but it is also clearly a problem that others have largely solved already. Many text heavy applications, such as mail or IRC clients (even some terminals), will automatically convert URLs found within plain text to navigable links for you. There are presumably libraries to do this or at the very least some example code. So that leaves me thinkingโ€ฆ why not Gopher clients? ๐Ÿค”

What is wrong with copy and pasting?

Having links in text documents that are immediately accessible via a click, tabbing, or typing a number, just makes things more fluid and easier to work with. It also does not require any change to the Gopher protocol itself. Automatic linkification is just a nicety that clients could optionally support (perhaps as a setting). Everything would still work without (as it always has). However I know that for myself, I would gladly pick a client that provided this convenience to avoid a few pointless, extra steps that add nothing to the experience of browsing gopherspace.

The way I see it, a Gopher client making URLs discovered in the text easily navigable, is not so very different from the client tweaking the display of fonts, or adding background or foreground colours. Underneath, Gopher remains Gopher. The client can allow the user to choose what to do with the data they have received. Good clients give users control and thus enhance the browsing experience.

Now I can guess what you might be thinking because I thought about it to. ๐Ÿ˜‰ However โ€ฆNoโ€ฆ I don't think this undermines gophermaps (or at least not completely). Unlike the web, Gopher has an expected structure. Gophermaps are primarily about navigation, with just a sprinkling of text to provide some context. Traditionally, they are a way to get to the content, rather than content themselves. Plain text documents on the other hand are primarly about expressing ideas, with only occasional links to help expand concepts or provide references. In essence they should largely be self-contained content.

Gophermaps will always be important to Gopher because by its nature it expects some level of hierarchy and this is provided (and continues to make most sense) by way of gophermaps or (raw) directories. This cannot really change, not least because it is unreasonable to expect all Gopher clients to suddenly support linkified plain text.

Put another way, linkifying plain text files does not change their primary role as content any more than having text in gophermaps stops them from being primarily navigation.

Feedback wanted

If you are the author of a Gopher client, please have a think about this. If you implement it (even as an option) let me know. Alternatively if anyone knows of clients that do this already, or you just have further thoughts you would like to share, feel free to tell me. Contact details are linked beneath the comment section below.



2021-12-14 14:37 (UTC+1)

Luke Emmet:

My client GemiNaut does its best to link up URLs it finds within the content, particularly at the end of the file, which seems to be the convention. It will even go as far as making the square bracket citations (e.g. "[1]") clickable, if these are used by the author.

For example the attached [below] image shows how the following URL is displayed. The blue links are clickable.

solderpunk (gopher) - Low budget P2P content distribution with git


Still, I much prefer Gemini to Gopher for various reasons.

You can also use GemiNaut to view most simple (so-called "small web") web pages in a similar way, which are converted to Gemtext. But mostly it is a Gemini client. For further info on GemiNaut, see

GemiNaut homepage

2021-12-14 15:21 (UTC+1)

Ruarรญ ร˜degaard:

Awesome, this great. You have even gone a step further. I do use Linux, macOS and Windows but the latter by far the least. I will certainly check this out next time I am in front of a Windows machine.

โ€œStill, I much prefer Gemini to Gopher for various reasons.โ€

Me too ๐Ÿ˜‰


๐Ÿ“ Comment

๐Ÿ”™ Gemlog index

๐Ÿ” Capsule index