Nostr Web Client

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.”

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.

Reply to this note

Please Login to reply.

Discussion

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?

Vitor Pamplona 11mo ago

Yep, but most people will find out their key has leaked after the attacked already created all their events. It would be impossible to distinguish unless the user goes through one by one to check.

Also, now clients need to do even more in checking each event id if it is part of the signed filter or not.

Eric FJ 🪬⚡️ 11mo ago

I’ll have to think about the first two points, thank you. I don’t have a good idea how to answer those at this point in my journey here.

On the third- sorry if I was unclear, yours is obviously a lot simpler and easier to implement on the tech side. And having the network saying the profile is dead is good. But doesn’t provide much assistance for recovery of original social graph and wouldn’t it require people to associate their nostr identity outside of the network? I was thinking under the conditions that someone might not have that. I guess yours requires people to be social which is not a bad thing. When I said scalable should probably have used a different word there.

I really would like to find a way to recover the social graph, at least effectively, but maybe this is an intractable problem?

I also don’t understand what you mean by “server” in this context, but that’s a me problem, not a you problem.

Vitor Pamplona 11mo ago

I am not opposed to investigating if we can reliably recover the social graph, but I don't have a lot of hope anymore. Everything that has been proposed falls short of a simple kind 1 warning message to your friends. But maybe one day we will figure this out.