Generation 1 of #Spritely Crystal read-only URLs are approx 142 characters long. Not short. Can get shorter in generation 2 though, I think.
Conversation
Notices
-
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:26:34 CEST Christopher Lemmer Webber -
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:32:48 CEST Christopher Lemmer Webber Here's what a "generation 1" Spritely Crystal read-only URL looks like: quartz:RXgTjiyAAxKGLsuAbrF1TFlD4n0gpFqphMvHHu5eTUk.Idrv4eCJtEdurDia6ked8mwU5-UtwOFXChF45tAbZLA?rok=yyd5b_Ez0bpiDAllOHEkbZosKMqYCwZnnYGJApCeqMc
Pretty long. :) Here's how it works:
quartz:<verify-key-location-urn>.<verify-key-decryption-key>?rok=<read-only-key>
One reason it's so long is that the verify key is stored in a magenc CAS store, which means that it also needs a decryption key!
-
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:34:51 CEST Christopher Lemmer Webber Technically, the verify keys barely matter, and you could really just store them in a CAS store unencrypted... it's about as useful of info as you get from looking at a public keyserver (even less than that, but you know they're for the root of ~files). There's some additional metadata but it's "mostly just the key".
(cotd) -
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:36:14 CEST Christopher Lemmer Webber BUT, I wanted to reuse the CAS store, but I want to instill a policy that nothing should be stored in those stores unencrypted (it's a risk for CAS hosts to get in the habit of doing that... you should know as little as possible about the data you're storing that isn't yours).
Might be able to get around this by storing the key directly on there in V2.
-
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:36:43 CEST Christopher Lemmer Webber (If it's an elliptic curve key, it could be small enough to store on a URL.)
-
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:39:07 CEST Christopher Lemmer Webber For every new file you make, you create a *new* public/private key pair. Why?
That's because the "name" of the file IS the fingerprint of the key (sort of), so that key is used to sign off on "updates" to the file. That's how we accomplish writing updates.
-
Christopher Lemmer Webber (cwebber)'s status on Sunday, 12-May-2019 15:40:09 CEST Christopher Lemmer Webber These aren't new ideas btw, this is all taken from tahoe-lafs.
And I'm probably not being very clear here, I'll aim for much more clarity when I get to the documentation... the usual "write docs as a narrative" approach I love so much :)
-