Damus
ynniv · 1w
1. apps make random keys 2. an identity attests them 3. apps see this attention and include it on their events 4. all identity prefers an attested id over the signing id 5. if a key is lost, the ident...
inkan profile picture
I think that by

"an identity attests them"

you mean that the identity signs something saying that events signed by the attested keys should be attributed to the identity, right? If so, this is similar to what Inkan calls a "delegation of signing authority."

And when you say that, when a key is lost, the identity key publishes a disavow, this is similar to what Inkan calls a "revocation of signing authority."

All of the above is, I think, fully implemented in Inkan.

Now the part I don't agree with conceptually is (6): "In the presence of a disavow, all events with that attestation are considered deleted."

That's not what should happen. Only events that are signed *after* the disavow should be no longer attributable to the identity. Events that were signed *prior to* the disavow (while the attestation / delegation was still in effect) should remain attributable to the identity.

So I think Inkan is in many ways similar to what you describe above, except for the modification to (6). I think Inkan's handling of this is conceptually more correct.
1
ynniv · 1w
yes, they are very similar proposals. and the same family as DID, with much less ceremony but, nostr doesn't have a hard timeline. it's easier to accept this than to fight it. clients can rekey as often as is convenient – every week, every day, every message. this limits the blast radius of a key...