-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared Event Ownership through DVMs #1015
base: master
Are you sure you want to change the base?
Shared Event Ownership through DVMs #1015
Conversation
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:
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). |
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. |
I see, so this is an adapter between something like my idea and "I just want an event signed by a normal pubkey"? |
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. |
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. |
On your idea, something still needs to do this:
Who are these signers? Are they people? DVMs? Webservices? Either way, you are still trusting them to sign correctly. |
Sorry, I meant signatories — that's just the people collaborating to sign the event being collaborated on. |
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. |
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. |
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. |
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:
We might add another Job request with a DIFF-type of payload.
Read: here