I recently made several simplifications to the draft NIP and implementation on key revocation and migration.
I think it's very close!
In particular, having a way for users to verify another user's profile either privately or publicly, should be very useful. If a profile ever becomes compromised, the user's profile name, image website, NIP-05 and other user metadata can all be "pinned" and remain uncompromised.
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.
Where would the verification of an npub from another npub be stored?
All attested to values of another user's metadata are duplicated and stored in the attestation event. The event is either encrypted or public. For a user's own attestations, a lock icon could appear on the profile image; this would be awesome, I think.
Alright, then one could even have backups on a local relay. This certainly aounds like a NIP worthy of some discussion :)
very interesting btw :)
