NIP-A2: Account delegation via kind-0

[1l0]

Read here.

[staab]

This used to exist (NIP 26), but was removed since no one supported it. Delegation puts a pretty big burden on clients which have to map accounts together. I'm not saying we should never do this, but someone needs to come up with a good design that includes key rotation/revocation/delegation before we start implementing it.

[AsaiToshiya]

FYI, unfortunately NIP-26 not yet deprecated: #1051

[fiatjaf]

This has been proposed a million times, and at first it sounds like it could work, but when you look more into it you realize it is fundamentally broken.

[mikedilger]

The only real problem here is that complexity is added. If I want hodlbod's notes I have to check his kind 0 to see if he has added a delegation. If he has, I have to check that pubkey's kind 0 to see if it is valid. Then I have to load all notes from both pubkeys and maintain this relationship between the keys in my local database somehow. When the delegation ceases I have to figure out what to do about notes signed by the delegatee... are the no longer hodlbod's notes? what if the delegatee keeps signing notes, do I say "everything after the timestamp when I noticed the delegation was no longer is not valid"? I may not notice right away. Also, the notes wont revert to being signed by hodlbod so I have to remember this delegation forever. Also, all code that currently just looks at event.pubkey will have to be revisited because sometimes the code is trying to yield the answer hodlbod, not the delegatee. So the complexity of such a change gets pretty deep.

Yet I am in favor of something like a master key and subkeys (which essentially are delegations) even though it brings about all of this complexity because I think key management is important and without it nostr might be self-limiting.
To do it right it has to be more fleshed out than this PR. For example, we would need multiple kinds (at least two) of key revocation that match up to what we mean: revoke everything signed by this key, or reject only events signed after a revocation date.