Soweli Lukin


                   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.

  1. Content creators

There's not much about the Gopher protocol itself that either helps nor hinders a content creator.

  1. 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]

sftp://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.


Soweli LukinIssuesAlex Schroeder