The true spirit of gopher

What is the "true spirit of gopher"? Its "heart and soul", the deep,

conceptual commitment which distinguishes it from other protocols, in

particular from the web?

Chances are good you have the term "plain-text" on your lips right

now, and nobody could blame you for it, given the way that we all

(myself included) talk casually about gopher and what makes it so

great. But if you think about it, it's actually a bogus answer.

Every webserver I've ever used will very happily serve a plain-text

file. It'll include a "Content-type: text/plain" HTTP header in the

response, and your browser will recognise this and apply absolutely no

formatting or styling at all and just show you plain text.

You could build an entire website (would it be a website, in fact?)

out of plain text files. You could link between them with reference

numbers and URLs, exactly like we do in the phlogosphere, and your

readers could highlight those URLs and paste them into their browser's

address bar. The result would be a navigation experience very similar

to reading phlogs with a client other than VF-1 (which will extract

the links into a menu for you to avoid the need to highlight). You

could have no index.html file at the root of your webspace and rely

instead upon the server's automatically generated directory listing -

which is quite a bit like a gopher menu without the (unofficial, not

in RFC1436) i item type. If you did this using a webserver that

didn't serve cookies or any other objectionable stuff, then that's

pretty much a pure RFC1436 gopher experience right there, over HTTP

and using a web browser. There is no substantial difference in the

user experience.

The inverse is almost true, too. The h item type isn't in RFC1436,

but it is widely used and widely supported and has, I would argue, the

same de-facto standard acceptance as the i item type. Perhaps a

little less, but not much. With even a vaguely modern gopher server

and client, you could have a gopherhole full of HTML files. Some

clients might not handle it so well but lynx, say, certainly would.

You could almost avoid gopher menus entirely, and instead use

tags to link from item type h document to item type h

document - the gopher:// URL scheme has its own RFC (RFC4266), after

all. Plenty of phloggers use gopher to serve the occasional image or

sound file. Serving HTML is, from a protocol perspective, not one

iota less legitimate. You do need to have one gopher menu (if a

client sends an empty selector to a server, the response must be a

menu), which is why there are some "almost"s above, but everything

else could be HTML.

You could do either of the above, but nobody does (I might try the

first one using shizaru after a few beers some time...). At the end

of the day, this comes down to something like "community expectation"

or "social convention". Gopher = plain-text, HTTP = HTML is not a

technical requirement of either protocol, it's "just" a norm.

So, what is the real heart and soul of gopher? An actual,

honest-to-goodness, protocol-level conceptual distinction between

gopher and the web?

I would argue that the answer is "separation of content from

navigation". The first two gopher item types, type 0 and type 1, are

for documents and menus, respectively. They are, explicitly,

different kinds of things from the protocol's point of view. In pure

RFC1436 gopher, there is no i itemtype, so menus are just lists of

links to either documents or other menus. Documents fundamentally

• cannot* link anywhere, in anything other than a clunky manual way by

including URLs in a text document. This dichotomy is crystal clear.

This dichotomy also has no analogue on the web. Webpages combine

content and navigation via in-line hyperlinks. You can of course

build a webpage with no tags which is a navigational

dead-end, just like a "pure" item type 0 gopher document. And you

could build a web page which was just a list of tags

with no s or , which would be something like a "pure" item

type 1 gopher menu. But they would both actually be the same kind of

thing: HTML documents. The browser would request them both in the

same way, the server would serve them both in the same way, and they'd

get parsed in the same way - and all in exactly same way as you could

do something which was half way between these two extremes. There is

no conceptual distinction between content and navigation to be had,

there is only HTML.

This difference between gopher and the web is much more deeply

engrained in the actual protocol specifications than the plain-text

vs HTML difference which is so salient to the end user.

Now that we've uncovered the true spirit of gopher, the natural

question, for those participating in the on-going discussions about

new gopher-inspired protocols, is whether or not this idea is one that

the gopher community really cherishes and which should be preserved in

the Ultimate New Protocol of Truth and Glory.

I would argue that, in fact, the not-at-all-enforced-by-protocol

community norm of using only plain-text is much more precious to

most modern gopher users than the content-vs-navigation distinction.

The proof of this is that nowadays so many folks are deliberately and

unapologetically erasing that very distinction by using item type 1

for their entire gopherhole, serving all of their actual content as

item type i menu lines. Anybody who has read RFC1436 will tell you

that this is a flagrant semantic abuse of gopher; there's just no

wiggle room on that question. Anybody who has tried to write a gopher

client which treats items types 0 and 1 "too" differently (like very

early versions of VF-1) will tell you that this eventually causes

problems if you don't want to play hard ball and declare that

gopherholes doing this won't be properly viewable in your client.

But at the end of the day, building type 1 only gopher holes pretty

much just works, and it does offer a nicer user experience by

letting you embed immediately usable links right in the middle of your

phlog posts. So people do it, and that includes well-known and

well-loved gopher users and advocates like Tomasino, who is

unquestionably a great force for good in the gopherverse. There's

plenty of evidence out there that a lot of Gopher enthusiasts don't

actually want a protocol that divides sharply between navigation and

content. They just want to be able to serve plain-text with

hyperlinks anywhere they like, via a bare bones protocol that doesn't

support tracking and other unpleasantries. Something like "HTML with

only the tag, over HTTP/0.1". I think that's all I want.

But it doesn't exist, and gopher does, so we use gopher and the hard

line between menu and document comes along with it. Some people learn

to live with that hard line, some people fight against it, and some

people embrace it too much, creating overly-hierarchical,

user-unfriendly gopherholes where things live deep in

phlog/year/month/ sub-sub-sub menus which are inconvenient to casually

browse. Very few of us, I suspect, come here for this hard line.

Most probably don't even actually give it much thought.

Arguably, a protocol without this hard line has a stronger claim to

being minimalist and simplistic than one with it, all else being

equal. What could be simpler than everything being the same kind of

thing?