Nostr Web Client

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.

Eric FJ 🪬⚡️ 11mo ago

I agree:

“4. Unified Identity View

Historical events remain immutable but are re-indexed by relays to associate with the secure key for continuity.

Clients display a unified profile view, differentiating old and new events.

5. Seamless Transition for Existing Accounts

Existing Nostr users can integrate Excalibur by broadcasting a set_secure_key event linking their current primary key to a secure backup key. While historical events and metadata associated with the primary key remain unchanged, all new events after activation of the secure key are seamlessly associated with the updated identity. Clients should provide user-friendly tools to guide existing users through this setup process.”

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 11mo ago

So, if the user rotates 30 times, do Clients need to require users to sign with 30 private keys (so that I can decrypt the old messages) and then proceed to download data from those 30 users at the same time to build the interface?

Also, historical events cannot be trusted when the key rotates. There is always a reason for the rotation and all of them means that the key cannot be trusted anymore. Merging them together, you might be merging events signed by an attacker that found the key years later. Remember, anyone can write in the past.

I don't know.. you said my idea will be hard to implement and scale, but yours is even harder. They now need to use your server and a client to play with Nostr. And the client needs to do a lot of the merging itself. Mine is just, give up the old, move to the new and never trust the old one ever again.

Satoshi Coffee Co. 11mo ago

So could you hash the prior events and sign with new key when rotating keys so if any data in older events are changed, it's identified and well known?