GOPHER 2.0 - THE PROTOCOL
At the outset, I want to be clear about one thing: I like Gopher
machines. I hope we'll be able to visit Gopher sites *as they
are now* for many more decades to come.
Having said that, I have some fanciful ideas about what Gopher
*could* be if it were born today.
tent delivery system: developers, content creators, and end-users
(I would use the term "consumer", but that feels negative):
cations)
The current Gopher protocol is very developer friendly. I'm not
There's not much about the Gopher protocol itself that either
The only thing about the protocol which I think really affects
end-users at all is the selector string format.
The Gopher RFC, 1436 says this about the selector string:
The selector string should mean nothing to the client
software; it should never be modified by the client.
This is interesting. As the end-user of Web browsers, I often
manipulate URLs to navigate websites when the site's own naviga-
tion scheme has failed me.
nipulation, particularly since they also encode the item type at
the beginning of the selector (so you have to think about whether
you're trying to get a directory listing, text document, etc.).
Changes
=================================================================
What would a utopian Gopher protocol look like?
Stateless is easy to build, easy to debug, easy to think about,
and good for privacy.
actions with a single dot '.' on a line.
ng a document with actual single dots on their own lines is to
How would you ever be sure this document had completed success-
fully:
..................
... Hello, .......
... I like .......
... dots .........
..... '.' ........
..................
Further, Gopher uses no '.' to end binary files, so the client
Nope, I prefer just closing the connection when we're done with
each transaction for *all* types.
Simple is GOOD.
sn't the right protocol for sending "big" files. There's no
content length header, no resume feature, no peer-to-peer. You
text content, (huge) images, song-length audio, and even short
video.
Again, the idea being that there are *far* better ways to trans-
fer large files than Gopher.
gopher://example.com/1/my_rantings
gopher://example.com/0/my_rantings/rant001
gopher://example.com/7/veronica9000
But in practice, I find it annoying to have the most specific in-
formation about the selector at opposite ends of the string.
As a newbie, I initially found Gopher selector strings to be far
less intuitive and discoverable than a *good* Web URL.
URI style: [0]
scheme:[//authority]path[?query][#fragment]
sftp://example.com/big_files/huge.tar.gz
And as to whether I'm viewing a menu (1) vs document (0), well, I
you've got at that location and assume I know what to do with it.
(Mind you, I *do* care what you're linking to at the docu-
ment/client level - so more on that later.)
And the server is already going to have to check what it's serv-
ng at a given path - so having it double-check the type is
adding no benefit on that end.
Simple is GOOD.
Finally, I do think the next generation protocol would not just
No certificates - just public keys! SSH works without central-
zed certificate authorities. Use a known_hosts file just like
SSH. I might remember to speak more of this when talking about
the client, later.
That's it for the protocol. Less is more!
format and next-gen client.
Summary
=================================================================
Still stateless.
Remove Selector 'type' from selector string.
Simply close the connection after a transfer is complete.
Consider a file size cap.
Require public key encryption to preserve privacy and guard
against man-in-the-middle manipulation of data.
[0] https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
