More on gopher and crypto
-------------------------

My recent post[1] about "why gopher needs crypto" received a very
well-considered response[2] over at The Boston Diaries.  The author
(do I call you "the conman"?) rightly points out that the true
challenge is not in actually conducting a gopher request/response
transaction over a TLS connection, which in relatively trivial and has
been done before.  Rather, the core difficulty lies in the absence of
any way to represent in a type-1 response that a particular gopher
resource is accessible via TLS.

A simple convention, following the lead of the web (*involuntary
shudder*) would be to have e.g. port 70 correspond strictly to
plaintext and port N (7070, 4370, or whatever else you like - there
have been plenty of suggestions on the gopher-project mailing list
over the years) correspond strictly to TLS.  TLS-aware clients could
use the appropriate connection depending on the port.  The problem
with this is that non-TLS aware clients will likely suffer some kind
of breakage when following a menu item which points to a TLS port.
This means in order to avoid breakage of old clients, one must only
ever publically link to port 70 (Gophernicus has a hack in place to
automatically generate server-internal links on port 70 or a
designated TLS port depending on what kind of connection is being
used, but this doesn't work for outgoing links).  But if we do that,
how do the newer TLS aware clients ever know that a server also
supports TLS?

This is by no means insurmountable - an off-the-cuff suggestion on how
to work around would be to establish a convention that servers which
also support TLS connections over port N will answer requests on port
70 for some well-known selector with a machine-readable response
indicating "Yes, indeed, this server speaks TLS, on port N".  TLS
aware clients could request this selector from each server before
following a link to that server for the first time, cache that
response to disk and use TLS or not forever after.

But solutions like this are a long way from being elegant or robust,
and as long as gopherspace remains a mix of TLs aware and unaware
servers and clients (and, to reiterate, I do not want the non-TLS
servers to go away) we're going to be limited to hacks like this.

That's part of the reason that I am increasingly advocating not for an
actual attempt to upgrade gopher (which, after all, is not any more
likely to succeed than Gopher+) but for some new protocol (heavily
gopher-inspired, but unquestionably distinct) so that backward
compatibility is not a concern and we can just make things simple and
clean.  I'm under no delusion that this new protocol would ever see
widespread use, but who cares?  Half as much use as traditional gopher
has today would still make a small and interesting community viable.

The conman suggests that creating a new protocol is to risk that we
"start falling into HTTP territory".  This is of course a very real
risk, but I also very strongly believe that it is perfectly avoidable
if we are sufficiently determined from day one to avoid it.  To this
end, I hope to think and write (and read, if anybody wants to join
in!) more in the future not just about the shortcomings of gopher but
very explicitly about what is right and what is wrong about HTTP and
HTML.  It's vitally important to identify precisely what features of
the web stack facilitated the current state of affairs if we want to
avoid the same thing happening again.

[1] gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt
[2] gopher://gopher.conman.org:70/0Phlog:2019/03/31.1