NIP-A2: Linked account

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

[1l0]

@mikedilger
Thank you, sir. I was only considering an all-or-nothing approach for the revocation. Please create the NIP that aligns with your suggestion. Subkey-like functionality is a MUST HAVE for Nostr since ordinary users don’t use amber or bunker. Browser extensions can handle this, but most users don’t use desktop in the first place. Moreover, popular clients don’t even support ncryptsec and instead let users utilize nsec directly, which is dangerous. Let me keep this NIP open for a while until I find an alternative.

[1l0]

Here is Mike's proposal.

[1l0]

Forget about delegation, it is now a persona.

[fiatjaf]

What does this add that couldn't be done with just creating a key and writing in the description: "this is <someone>'s account"?

[1l0]

What does this add that couldn't be done with just creating a key and writing in the description: "this is 's account"?

The discoverability and the ability to be validated. There might be others that I just haven't noticed yet.

[1l0]

might be related: mikedilger/nostr-next#63

[mikedilger]

Persona doesn't have to be a separate keypair. There are other ways to scope things, like with some kind of scoping tag. Clients that don't support it just see all your posts, and clients that do support it can scope into personas. With the keypairs, clients that don't support it don't see your new persona's posts. I'm not sure which behavior is desired by the op.

[1l0]

With the keypairs, clients that don't support it don't see your new persona's posts.

That's a good one. Someone who follows a persona doesn't necessarily want to follow the base account. By separating the keys, each key can develop its own WoT (aka cluster).