Looks good, but I dont put much faith on this master key idea. I think a much simpler approach can be done with key rotations like on https://github.com/vitorpamplona/nips/blob/key-rotation/22.md
Discussion
Simpler yes, but I’m stuck on manual verification step.. doesn’t seem feasible IRL / at scale… lots of headache to implement an actual recovery.
Also doesn’t seem to solve re-association of past data. User loses a lot in transition. Lots of expectation for other users to do manual steps to recover the social graph. It’s still too damaging.
Yes, our proposal would require a lot of different parties to get behind it to make it work. Inherent complexity there- but activation by the user would be a lot simpler once this is implemented across most clients+relays.
Also, the Excalibur-as-insurance-policy model provides client/relay revenue therefore an incentive for them to implement and make it seamless. I’m certain they could use the revenue from premiums paid by all users who want a recovery option.
I’d pay sats to know my account is recoverable across x number of relays and keep my secure key completely offline until needed, god forbid.
I don't think there is a good way to move data between keys. For instance, you can't get your friends to resign for all DMs they encrypted to you. Same for moving likes, replies, etc to the new key. I think the user will always lose all the data regardless of which key migration we implement.
It's simpler, but with the same private key everywhere you'll end up burning more than you need to. Why not have a separate, cold, identity key?
The concept of splitting keys is fine. But I have never seen an proposition that actually works and it is at least as safe as having just one key everywhere. Once multiple keys are at play there are lots new attacking possibilities, especially on the social engineering side.
I don't follow. My proposed NIP-102 uses one key to attest other keys, so it could be cold and offline. If one gets lost, you disavow it the same as NIP-22, and issue a new one. Your friends don't need to validate the rotation though.
That's not how nostr works. The key's friends will still be following the old key regardless of your "disavowing". Their clients must each implement your thing and help that user migrate to the new one. Until then, they are following the old one not knowing anything about the change.
Which means that your user will inevitably have to declare the key as stolen in a regular kind1 and ask people to manually migrate to the new key, which duplicates the work and thus defeats the purpose of any automated system or key migration.
Not really? Think of session management: there are many tokens sessions for one user. You use your credentials once to get a new credential with the same authority as the password, but if it stolen it can be revoked without compromising your password. All operations behave as if the session token is the same as the root identity, and the only work that happens when a session is disavowed is that messages signed by the session should be deleted.