“All of the core decisions here are solid (pub key identities…”
I agree, except for the bit about public keys as identities.
I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.
We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.
I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.
I was reading about algorand rekeying today, as well as DIDs and atproto/bluesky.
Both seem to use a “signed rotation” approach. Algorand keeps your public key stable while adding metadata that your spend key has changed and links the two. Atproto similarly uses the recovery key to sign a rotation op which can regenerate your signing key, additionally readjusting the tree to preattack state (by setting prev of the rotation to the last precompromise state).
This seems like an improvement of some kind, but still leaves gaps for lost keys. Keybase style approach, or multisig social recovery may also help.
Until Algorand can remove the CGO requirements and libc JS dependencies then I hope it won't ever be considered for something like this. Let's not also forget about their terrible management.
I wasn’t suggesting either of the technologies wholesale. The “signed rotation” commonality seemed interesting, with subtle differences. I’m curious to see where DIDs go, I’ve seen those crop up a few places.
UCAN also seems interesting, JWT with extra steps and attenuation. But orthogonal to this issue for the most part.
Is there a way to do what you're suggesting with identities? I don't think there is. How are you going to rotate keys without a master key?
And even if you're ok with the master key, the only way to solve this without centralized providers is with blockchains. A blockchain for rotating keys doesn't make sense.
But I do want to know if you're ok with a master key and subkeys that can be rotated.
“Is there a way to do what you're suggesting with identities”
There are certainly solutions, but I don’t know what the best solution is, hence why I called it an open problem.
An example solution would be something like having your identity be a hash of your initial public keyset, making each key have a set expiration date, adding new keys by signing them with one of the existing keys, and then storing all of the rotation operations in a transparency log.
“the only way to solve this without centralized providers is with blockchains”
That’s not true; you probably want a transparency log, but that doesn’t require blockchains.
How can you rotate that? No one knows the second key is related to the first. You still need to publish your second key somewhere along with an invalidation certificate for the first key.
Rotate keys: old key signs an event indicating that it is being rolled into a new key.
Multiple keys: nothing to change. Works like that now.
Recover your identity: Well, if you want a well-known identity use NIP-05/NIP-35 and just change your .well-known/nostr.json file to point to your new identity, the one that hasn't been stolen. Hopefully nostr clients of your followers will respect that (who knows what programmers actually will do).
I think these problems are easier than you think they are.
I agree, except for the bit about public keys as identities.
I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.
We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.
I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.