Inanity 3: Virtual Gardening
----------------------------

This is my final installment of my 3 part epic.  All posts which
follow this one will be well-researched, error-free masterpieces
containing only the most interesting and enjoyable words.

I promise.

But for now, let us continue...

* * *

Now that I had the new gemini server up and running, I wanted
something more interesting than a few old mirrored phlog posts on it.

I've been playing around with TLS client certificates over the past
few days because I've become increasingly self-conscious that elpher
lacks the capability to handle these.  Initially I thought that this
would be trivial, with the most complicated thing just being choosing
the best way to make it easy to for users to select an existing
certificate or maybe even generate a new one on the fly. After all,
the Emacs Lisp documentation for open-network-stream claim that all
one needs to do is add a keyword argument specifying the names of the
cert and key files.

Of course, nothing is ever easy when it comes to TLS.  (Just look at
the previous fiasco which was needed to get the server running - or
don't, I honestly wouldn't blame you.)

It turns out that, while the option is there, it doesn't actually seem
to do anything.  Several people have claimed (forgive me for not
including references, I'm tired and I've long forgotten where I found
them) that emacs isn't actually presenting the client certificate at
all.  Of course it's still possible to set this up by directly
spawning gnutls processes and supplying arguments manually, but (a)
that's bound to be clunky, slow, and platform-dependent; and (b) this
completely sidesteps all of network infrastructure that emacs has in
place meaning that elpher ceases to be a good citizen and will likely
produce surprising results when mixed with other packages that manage
the network configuration.

Thus, for now at least, it seems Elpher is unlikely to be able to
support client certificates.

This for me is a _massive_ pain in the arse.  Elpher is my client - I
don't use anything else seriously.  Partly this is just a discipline:
I'm forced to eat my own dogfood, meaning the collective pain of
Elpher users is also my pain, which encourages me to fix things
quickly. Secondly, as it's evolved, I've become very used to it and
extremely comfortable with it.  I work hard to make sure that it obeys
the specs for the protocols it accepts content for, and also to cater
to the edge cases that crop up when content deviates slightly from
these protocols.  Thus client TLS certificates for gemini connections
have always been an important entry on my todo list.

That said, until recently I haven't had the feeling that Elpher users
have really been missing out on anything due to this omsission.  After
all, the only server requiring client certificate's was Sean's [1],
which exists only as a proof of concept and test for aspiring client
implementors.

That is, until Mozz came along and ruined everything with his
*amazing* Astrobotany site [2].

Astrobotany, as the site explains, is a port of Jacob Funke's python
game Botany [3] which has its roots in the tildeverse.  Mozz's port
allows gemini users to request a signed client certificate which is
then used to access a virtual garden containing a new seed.  Honestly
you can't do too much, but you can water it and check in on it every
so often to watch it grow.  And that's the beauty of it!

So now, due to my failure to convince emacs to present certificates,
my poor long-suffering elpher users were being denied the simple
pleasure of tending a garden.

I have decided that I cannot let this situation continue!

Therefore, I have implemented my own (minimal) "port" of Jacob Funke's
masterpiece that avoids the use of client certificates all together.
You can still create an account and use this account to check back
daily on your plant, but authentication is done far more crudely by
using the query portion of the URL.

That is, when you select the option to "Register a new account", the
server queries you (via gemini's "10" response code) for a user name,
which is sent back to the server in the query part of the url.  The
server then creates the appropriate data file, then sends back a
redirection "30" to a URL with a SHA-1 hash indicating the unique
identifier of the account in the query portion.  The page tells the
user to save/bookmark this URL, which is necessary to visit the garden
in future.  Any and all subsequent navigation within this portion of
the site preserves the query string, maintaining the illusion of a
persistent session.

Of course it really is just an illusion of persistence, but this is
nice in a way.  All of the state is maintained by the messages
themselves.  Any and all pages in the "logged in" section of the site
can be visited directly, provided one has the link with the
appropriate query string.  Similarly, different users can be accessing
the site simultaneously, despite the fact that the server is
single-threaded and has no notion of state.  (I suppose the client
side certificate implementation also shares this feature.)  It reminds
me of the interleaved factorial calculations I wrote about in my post
on the actor model [4].

I know this approach is probably considered terrible from a security
standpoint.  After all, we're basically talking about using a "secret"
URL as a password.  However in this case I don't think it's too big of
a deal.  Firstly because, hey, it's just an ascii art plant game.  But
secondly, these query strings are _only_ being transmitted over
(ostensibly) secure TLS connections. And thirdly, the use of an SHA-1
hash of a username + random salt should make them pretty hard to
outright guess.

Anyway, the port is called μBotany and it's up at
gemini://thelambdalab.xyz/microbotany/, so hop on over, plant a seed
and let me know what you think!  The artwork is all copied directly
from the original, but the the game logic is a reimplementation using
scheme scripts executed by the RAGS gemini server.  A link to the
source is provided from the start page. (Being a derivative work it is
of course licensed under the same MIT-derived license as Botany.)

Till next time!

---
[1]: gemini://gemini.conman.org/
[2]: gemini://astrobotany.mozz.us/
[3]: https://github.com/jifunks/botany
[4]: gopher://thelambdalab.xyz/0/phlog/2019-08-16-Playing-with-Actors.txt