Look nostr:npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym seems someone already took advantage of the fact nostr uses schnorr to make multisig publishing. I haven't used it yet to know the shortcommings, but seems to be the right approach for community owned nostr accounts https://github.com/nickfarrow/frostr . We only need to make better management tools and probably integrate it to some clients, but if it all works as I think it will, no new NIP's are required.

Reply to this note

Please Login to reply.

Discussion

Interesting, will check! For me the main problem of multisigs on nostr: they are needed for orgs, but they can’t serve orgs needs, since people in orgs are get fired and replaced, while the npub of the org must not change. This makes impossible any serious use case around multisigs in the current way they are set up (with Schnorr signatures and not in a GPG style).

Frostr does seem to address this. Good podcast describing it: https://stephanlivera.com/episode/476/

After initial analysis I think this is an example of overengineering which doesn’t exactly covers use case needs - while simplier alternatives do.

What orgs need is:

1. “Genesis” key for the org held by current CEO or CMO;

2. Which creates dedicated even types (not usual posts) delegating org right to other keys (ppl in marketing team) - and revoking that delegation when a member of the marketing team is fired;

3. This “genesis”/control key may also be revoked in case of CEO/CMO change; and a new key is appointed.

Clients may present all events from all org-delegated key as a keys under the same “virtual” org account.

I like how musig is good enough for building federated bridges to blockchains like ethereum. but to add rotation, migration, recovery and more complex signing rules, I always end up with something similar to DID with taproot rules. that would require a new nip introducing those entities and their message validation rules, similar to the signature delegation nip. I'm not fond of genesis events b/c they may go missing as per nostr rules. But I agree that any concept that introduces time as a dimension to identity needs to outsource to a "timechain"