GOPHER 2.0 - THE PROTOCOL
I think this is going to be post 2 of 4.
At the outset, I want to be clear about one thing: I like Gopher
just fine the way it is and I value that it still works on old
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.
I think there are three main perspectives when considering a con-
tent delivery system: developers, content creators, and end-users
(I would use the term "consumer", but that feels negative):
1. Developers (the person who writes the client and server appli-
cations)
The current Gopher protocol is very developer friendly. I'm not
sure I can improve upon it *much*.
2. Content creators
There's not much about the Gopher protocol itself that either
helps nor hinders a content creator.
3. End-users
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.
I find that Gopher selectors are far less friendly for manual ma-
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?
Pretty similar to what we have now:
It would still be stateless - one connection per transaction.
Stateless is easy to build, easy to debug, easy to think about,
and good for privacy.
I'm not convinced there's any need for Gopher to end text trans-
actions with a single dot '.' on a line.
It's not super reliable or definitive. The workaround for send-
ing a document with actual single dots on their own lines is to
send two dots! (Do you then send *three* dots if there are al-
ready *two* and so forth?)
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
simply receives until the connection closes.
Nope, I prefer just closing the connection when we're done with
each transaction for *all* types.
Simple is GOOD.
In fact, I might go one step further and say, look, this simply
isn't the right protocol for sending "big" files. There's no
content length header, no resume feature, no peer-to-peer. You
should really be using something else like HTTP, SFTP, or BitTor-
rent for big files.
In fact, I wouldn't be opposed at all to capping all content to
some limit like 1Mb, 5Mb, maybe 10Mb. That would allow (huge)
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.
I'm a little torn on the idea of having the selector type in the
selector string. In *principal*, I do see the value in saying
here's a directory ("menu"), here's a document, here's search:
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.
I also much prefer non-Gopher protocols to be specified in the
URI style: [0]
scheme:[//authority]path[?query][#fragment]
s
ftp://example.com/big_files/huge.tar.gz
And as to whether I'm viewing a menu (1) vs document (0), well, I
don't really care *at the protocol level*. Just give me whatever
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-
ing 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
support encryption, but would require it at the outset for sim-
plicity's sake.
No certificates - just public keys! SSH works without central-
ized 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!
I find that I have a *lot* more to say about a next-gen content
format and next-gen client.
Summary
=================================================================
In my imagination, a next-gen protocol is:
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
