Shared Event Ownership through DVMs

[vitorpamplona]

Creates a new flow to use Trusted DVMs to collaboratively control events without having to share the private key for that event between authorized individuals.

Use cases:

• Collaborative document writing tools generally allow several users to change the same document.
• Group metadata events must be updated by a set of admins, including adding and removing people from the group.

We might add another Job request with a DIFF-type of payload.

Read: here

[staab]

It's a good idea, but I think the spec needs work. It could also probably be done without DVMs, since all they are is a trusted signer, which isn't really necessary. Here's a different approach:

• Create signatory group: a normal event with a list of pubkeys as the initial signatories, not necessarily including the original pubkey.
• Following nip 18's version of wrapping, any event could be stringified and placed in a wrapper event's content. The wrapper would have a kind request_signature with an e tag pointing to the signer group.
• Signnatories would look for those events, and publish a kind confirm_signature with a sig tag that signs the wrapped event.
• Optionally a final event with a different kind and all the signatures added to the tags could be published for easy retrieval.
• It would be useful to define a quorum for adding/removing admins, or signing an event. If you have 8 admins, they don't all need to approve something in most cases. The quorum could be anywhere from 1 to all admins.
• An event with a different kind could be signed using the same process for adding/removing admins. You could avoid a linked list of events by just creating an entirely new group and updating whatever the admins are supposed to be signing for (I imagine a community would have a signer_group tag pointing to the e tag of the signer group event).

You could also do this with replaceable events, but I think they add more complexity than they solve. It seems to me that the original DVM approach was probably intended to solve the ownership problem of replaceables (because they need a persistent pubkey).

[vitorpamplona]

Although I agree that this could be done with any trusted signer, the goal is to remove the need for specific implementations of those signers for each NIP and create a way that any NIP can simply use one of the DVM signers if all they need is a simple access control policy like the one defined here.

This will not solve for every use case, but It could solve for many cases that simply need an anchor event that is collaboratively modified over time.

[staab]

I see, so this is an adapter between something like my idea and "I just want an event signed by a normal pubkey"?

[vitorpamplona]

It's more like a: I need this replaceable event to be modified by three keys and I don't want to design a whole secret/private key -sharing scheme to get that.

[staab]

Ok, but doesn't my scheme accomplish that without a trusted signer? It doesn't really seem any more complicated and avoids a dependency on a particular DVM's pubkey.

[vitorpamplona]

On your idea, something still needs to do this:

Signers would look for those events, and publish a kind

Who are these signers? Are they people? DVMs? Webservices? Either way, you are still trusting them to sign correctly.

[staab]

Sorry, I meant signatories — that's just the people collaborating to sign the event being collaborated on.

[pablof7z]

A third option would be to use NIP-46 for this (which was actually my original motivation behind starting to work on nsecBunker).

A key is stored in a bunker and the people who can collaborate on the document are authorized to perform actions on the document.

Collaborators make modifications and send them via NIP-46 to the bunker to get a signature.

[staab]

A third option would be to use NIP-46 for this

This has always been my vision as well. I think it's very simple, but it does require both a key (which may change hands) and a trusted third party (the signer). I think it's a good trade-off, but this PR does gain security through additional complexity.

[vitorpamplona]

If you can specify an interface for standard access controls in NIP-46 (who is approved to sign what) so that any implementation of NIP-46 would also have the signers discussed here, that would work as well. I thought DVMs would be better for this because you don't need to set up the nsec bunker or equivalent service. You can just use any existing DVM to control your group.