That use case is much simpler. To "verifiably connect 2 npubs" you should need to sign a note saying that you own the other npub and vice-versa.
If you want that relationship to be done automatically and detectable by clients we can come up with something too, but what would be the use case?
Another thing that can be done is to generate multiple pubkeys based on a single secret key by, for example, adding numbers to it, for example:
pubkey(nsec+1) = npub+pubkey(1)
pubkey(nsec+2) = npub+pubkey(2)
and so on
Such that if someone has npub and npub+pubkey(1) they can verify that they are indeed connected (or it could be any number, doesn't have to be 1, 2, as long as the verifier knows the number).
I think we should have a NIP for this because it's a cool way to have multiple identities that are nonetheless tied together, but I'm still searching for a use case.
I like the idea of having a central, controlling nsec as a way to group particular npubs together simply because that is what I am used to having in a legacy system context.
I can certainly function without it but it seems useful if I had say 3 different npubs that performed different functions. Maybe notes were written from those npubs by a person other than myself but she couldn't post the note because she doesn't control the nsec. Only I do which would give me the chance to "approve" or "disapprove" of any note because only I can execute the send. Expand this to an organization like a university and that's a shit ton of npubs (at least one from over 100 departments).
The horror of this is that if I had multiple well known npubs and the nsec was compromised . . . well, you can fill in the blank.
It is very likely that we don't really need this at all but my gut feeling tells me that I want this simply because having nsec/npub key pairs for multiple 'accounts' seems like a lot of management.
Thread collapsed
