Currently, the 6x (CLIENT CERTIFICATE REQUIRED) status code range is used to maintain states between gemini client and server. An example is Astrobotany, which uses self-signed certificate and the certificate's CommonName as username: "Register a new account by sending a self-signed certificate ... Your certificate's CommonName will be your username..." https://portal.mozz.us/gemini/astrobotany.mozz.us/ Initially, it was even using certificate signing request, for good measure: https://portal.mozz.us/gemini/astrobotany.mozz.us/register This allows Astrobotany to both authenticate & maintain states across gemini requests. Very nice, high grade authentication and state management to securely attend to all our sativa-indica cravings. An alternative, elcheapo, workflow, without any need for client certificate fiddling, could entail just the userinfo authority bit of an URL: (1) Request a named token: C: gemini://astrobotany.mozz.us/.well-known/token?anon -- request a named token, at a well known location S: 30 gemini://anon:token at astrobotany.mozz.us/ -- the server associates an opaque token to validate the named user C: gemini://anon:token at astrobotany.mozz.us/ -- the user-agent authenticated with the provided userinfo to maintain its state (2) (Re)use the named token later on: C: gemini://anon:token at astrobotany.mozz.us/plant S: 20 text/gemini; charset=utf-32; lang=tlh-Kore-AQ-fonipa -OR- S: 40 Unauthorized. Access token required. Get one at gemini://astrobotany.mozz.us/.well-known/acct. The token can be anything sensible, given what's at stake, e.g. short base58 hmac of the name, random number, whatnot. Workable? Heresy?
---