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]

  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.

  [0] https://en.wikipedia.org/wiki/Uniform_Resource_Identifier