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 .