Mansfield mansfield at ondollo.com
Fri Feb 19 03:30:05 GMT 2021
- - - - - - - - - - - - - - - - - - -
Good evening!
(I know this is a long email - I'm excited to share some of what I've beenexperimenting with. Hopefully it's coherent.)
I've been experimenting with a non-standard status code and I wanted toshare some details. I am running this experiment to find a way for users tomanage content using only a Gemini client and server. No ssh, rsync, vim,emacs, nano, or anything else.
I see status code 10 as the server telling the client that the user can,"provide short input".
I see status code 11 as the server telling the client that the user can,"provide short secured input".
I've been using a status code of 12 for having the ondollo.com server tellthe Mansfield client that the user can, "provide long input".
The simplest conceptual adjustment is that there's no character limit onthe input a client might provide in request/response input cycle involvinga status code of 12. Status codes 10 and 11 have specified limits around 1kbytes (I'm fudging the details there). Status codes 10 and 11 also have thespecified behavior of putting the user input into the URL as the value ofthe query component. So... the simple part is that there's no limit to thenumber of bytes sent from a client to a server in a request/response inputcycle involving a status code of 12.
To escape the 1k limits of the URL in responses to 10 and 11, myexploration of status code 12 places the user input in the body. This meantI had to change my server from only understanding how to process the singlerequest line of standard requests to processing the request line *and* thebody when it sees a response to a 12. So I needed to tell the differencebetween requests with a body and ones without.
Since I then needed to be able to tell the difference between requests thatdidn't have a body and those that should, I modified the server to provideunique links to the client. These unique links use a UUIDv4 that is trackedon the server and expire after a day. These are, IMO, thegeminispace equivalent of server side sessions. I say thegeminispace equivalent since they do as little as possible and only for thepurpose of getting simple content from the writer to the reader. (Thecurrent spec says as much and explains additional privacy benefits of thisconcept of server-side sessions.) Because the goal is to help users managecontent (or resources) using only a Gemini client, internally the UUID ispaired with the clients certificate fingerprint and originally requestedresource. In practical details, the resource is the page the user isediting.
So. If a client provides a certificate and a URL that contain thefingerprint and UUID (respectively) that the server is tracking, the serverwill accept the body of the request as the value of the originallyrequested resource.
To make the impact of certificate fingerprints line up more with *all* ofthe content a user might want to manage, the user must create an account onthe ondollo.com server first. This account creation process is very verysimple. The only step is to visit this link [1]:
=
gemini://ondollo.com/internal/account/create
The certificate used when visiting that url is the certificate required tobe provided when managing content in that account, since it's thecertificate that will be paired with the UUID and originally requestedresource on any resource that provides edit or create links. (This conceptis also explored a bit in the current spec, and mentioned that it could bethought of as analogous to the .authorized_keys file on an SSH server.)
[1] - After creating an account you'll get a status code of 20 in response,with unique links as described above - if you use those links you'll get astatus code of 12 containing the current value of the resource as the bodyof the response and letting you manage your content as this email describes(assuming your client supports sending requests with a body).
This puts additional emphasis on the geminispace use of certificates. Wefeel we've lined up with the current spec quite well on this. If a clientcreated content with a certificate and then lost the certificate, thecontent would no longer be accessible for writing. If an account werecreated with a certificate and then the user lost that certificate, theaccount would no longer be accessible. If a client allowed more than onecertificate to be locked to ondollo.com, then the user could choose betweenmore than one account anytime they visited. If a user chose a certificatethat had never been registered with an ondollo.com account, the serverwould have no way of knowing that that user might already have an accountunder a different certificate.
There is an additional concern about 'leaking' the certificate. If acertificate is used to create an account, it becomes a form ofusername/password. If that same certificate were presented to other serversas a user were browsing through geminispace, the other servers would haveaccess to any resources in that account that had been limited to only thosewho can present the original certificate. (At least, I think that's truefrom my limited understanding of certificates. I'd *love* to be provenwrong on this.) IMO this means that Gemini Clients must allow and encourageusers to 'lock' certificates to specific sites (urls? hostnames? domains?).(Here, again, the current gemini specification seems to agree and mentionsthis as a concern that client implementers should watch for and enableusers to manage - by hostname+path, locking all urls with that pair as aprefix.) The Mansfield client was modified in two ways to support the above.
The first was simple - allow a user to lock a certificate to a hostname.Then, every time the client navigated anywhere, it would check thelockfiles to see if the hostname it was about to open a connection to hadalready been locked to a cert. If it had been locked to a cert, that certwould be used for all communication with that hostname, including theinitial connection. (We're still on the fence about locking to thehostname+path pair, but we lean on the side of considering it a'good-thing' that we'll probably implement.)
The second adjustment to support user privacy is that the Mansfield client,on start-up, generates an in-memory-only cert. This isn't secure memory, ormemory that can not be flushed to disk, this is just a certificate thatcan't be reused after the client is shutdown. This is done so that if theuser navigates to any hostname that is *not* locked to any othercertificate, the in-memory cert created at startup will be used. Thisremoves the possibility of leaking a locked cert. We think that arecommendation along the lines of generating an in-memory cert like thismight improve the current gemini spec.
One additional point - the account name used when following this cert-basedprocess is based on the subject-common-name element in the cert. To dealwith collisions, the first few characters from the certificate fingerprintare combined with the above common-name. We plan to eventually addfunctionality that allows users to register a pseudonym that takes theplace of that common-name+fingerprint-prefix pair and would be more humanfriendly.
Ah... and another point... how does the server know when to stop readingthe body of a request that pairs up with a 12? Well... there's a deadlineon the connection. You'll want to get all your data across before then. Wedon't really like that that's all we have... we've thought aboutimplementing something more, but other options currently feel just asarbitrary... some max byte size?
Finally - thanks for reading all this. I need to stop typing... I've beentyping this for the last hour and a half! :-D
If a status code of 12 makes it in to the spec or not is fine with us. We'dlove to see more servers and clients fight for the user. (Yes, I've beenwatching certain movies recently.) We believe creation of content should beas simple as consumption, and we're enjoying exploring this approach as anoption.
Thanks!-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210218/4fe7d26c/attachment-0001.htm>