Nostr Web Client

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.

Dr Maxim Orlovsky 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

nubis 2y ago

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"