Read the specification at:
https://github.com/braydonf/nips/blob/beaa4f6971c313612ff5c4c1a0d9d30ecd4908d3/xx.md
Implementation of two new events:
https://github.com/braydonf/go-nostr/tree/d7e124ea994ffa4c17f6561c15bf81deb355b353/nipxx
Pull request for the NIP:
https://github.com/nostr-protocol/nips/pull/1452
Seeking feedback and comments!
I like your proposal. I have been thinking about this a lot lately as well.
Do you think it’s possible to treat this as a sort of password reset? The phrase is not ideal, but it’s descriptive. Users sometimes have a hard time with any sort of secret keeping. In that case, I would imagine they would appreciate it, if the chain of keys remained and was linked as one identity. So the revoked keys remain read-only, as you already have planned, but some relays might opt to keep the events and clients might include them as part of the profile/history of a user and have that as a feature.
I don't think so. It's to recover from a compromised private key rather than a lost private key.
I see both as closely related in that you want to utilize a reference to the previous npub. I know I might be going off on a tangent, but I can see cases where you might want to preserve an identity over multiple key rotations. Should I consider that a completely separate topic?
I am not sure how the linking would work between the previous npub and the next npub for clients or relays for all previous events.
Especially considering that everything from the previous key can't be trusted anymore, as an attacker could post with any timestamp on notes/events.
Perhaps the next npub could make a merkle tree of all the valid events from the past, and sign the root and provide proofs — this might get complex quickly though.
An npub could have a bootstap archive of events to "spawn" a new identity?
I like the bootstrap archive notion. We can keep it out of the general relays. I’m mostly interested in content creators who have invested major effort and would be willing to go an extra mile to set this up on a self-hosted or paid relay. I don’t expect it to work with zero input from the user.
For the clients, maybe they can offload the task to a DVM so they don’t independently have to implement the same lookups. The DVM provider can also supply the archive and then use it to inform the clients on demand.
Yeah, a self-hosted paid relay could still store archived versions of old notes even if the private key from it has been compromised by having another key "sign" for them, essentially.
