Nostr Web Client

My 102 proposal uses a single identity key, and the ability for any key to sign on behalf of the identity if it has an attestation. When you get an event, you immediately know whether it's authorized to impersonate the identity key, so you just treat it as the identity pubkey. If it's revoked, you delete the event, just as you would with a deletion request. So, everything operates as it did before (following one pubkey), except you can issue new keys without telling anyone, events signed by them look like you, and if you get burned, you delete all those events.

Vitor Pamplona 1y ago

That's exactly the problem I described. I think you are underestimating your proposal's real impacts on clients.

For instance, what happens if a replaceable event has an attestation that keeps changing to different identities every second? If you add those attestations to NIP-51 lists, now apps are immediately reacting when the list options change, all relay filters change, the whole web of trust ranking keeps switching.

Reply to this note

Please Login to reply.

Discussion

ynniv 1y ago

That's an interesting case. I don't think this will happen in correct implementations because either the replaceable event will be treated as the identity key (having implemented 102), or the signing pubkey (having not). Either way the identity of the "current" event won't change, even if the signing key uses rotating attestations.

Key management is definitely a big deal, and in distributed systems rather intimidating. But having worked on SSO in the past, the current situation is risky and holding nostr back. Fixing it won't be easy, but doesn't need to be complicated if we work out the details.