[CONTACT]

[ABOUT]

[POLICY]

At the want to be clear

Found at: sdf.org:70/users/ratfactor/phlog/2019-06-07-gopher-2.0-protocol

                    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


AD: