-
Notifications
You must be signed in to change notification settings - Fork 564
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 Replaceables via Shared D-Tag #1192
base: master
Are you sure you want to change the base?
Shared Replaceables via Shared D-Tag #1192
Conversation
I feel like it would be much simpler for everybody involved if this was done with a shared private key or a FROST key. |
I went there but I was way more complicated to manage the key than I initially thought. Each Doc with a different group creates a key, which then the user has to manage all of these keys. It's a lot of work. And you lose track of who did what change in the doc. Of course, you can have a separate system that takes a signed payload from each user and resigns as the shared key, so that you can keep track of the changes, but that is even more work. |
Frankly, I wish we had a way to build 1 of N signatures, in the sense that the |
I see, it makes sense that this would be a hassle.
I'm pretty sure FROST can do that. But you wouldn't know who signed. |
You could create a new kinder group for events that need to keep a history of all changes. In the case of kind 3XXXX, only the last change would be kept. Another advantage of this approach is that the list of owners is public. Which would not happen in the other implementation suggestion. |
How do we test this? Do we know anyone with experience on FROST to create some Nostr events? :) |
Here's an alternative approach. Benefits:
this is how the |
Haven't you seen https://github.com/nickfarrow/frostr? I thought everybody knew about this. Some people played with it at the time, but it was a very manual process. I couldn't myself. So not great, but it was just an experiment. Still it proved it was possible. |
Oh yeah, I remember seeing that. At the time, there were a lot of questions and people weren't sure if the way it was coded was secure. Do you know if anyone is using that version? Also, should we store all those FROST secrets inside Nostr? And can we reuse those secrets into many keys? (many shareables in our case here). |
It's a similar scheme used by docstr.app The issue there is the mess created by intermittent relays while validating updates to the
Now if the event 2 is unavailable at the receiving time (relay is busy, UserB deleted it, userB is using a separate relay or something else), the client has a problem: It looks like UserC added himself to the replaceable's owner list. There is no way for the client to verify that UserC was authorized by previous owners to update the record and the client SHOULD just reject UserC's change because the same state would exist if UserC is an attacker and is inserting a phishing link to rug pull people. Either way, in that scheme, the client SHOULD perform owner change verifications. Versions coming from each of the owners should have a matching owner's list OR rebuild a sequence of events that verifies new owners were accepted by at least one of the previous owners. Nostr Replaceables do not allow owner change. This PR would be similar with the only difference that it would be multiple owners and not a single one. In that sense, Clients can trust what's coming in the |
@nickfarrow can you enlighten us? |
Yeah that frostr repo.. I'd love to make a good UX for it but am focusing on making that happen in the @frostsnap app. I've been signing nostr events like crazy on burner accounts ( i need to add a way to take an existing nsec and shamir share it for FROST use). A
As in, posted within events? I guess could be done if encrypted and you trust relays to persist them..
Yeah you can add tweaks to get subkeys for different purposes, like bitcoin taproot address derivation. Recently proven secure |
I am thinking on a regular kind 10xxx event that holds FROST public keys as tags and private secrets as a NIP-44-encrypted JSON-stringified tag array and in the
We could add a |
The idea here is to add replaceable events that can be changed only by a list of pre-defined keys without changing relay implementations and without using a separate key to sign the event on behalf of the owners, like how #1015 suggested.
Imagine a Google Doc/Spreadsheet that is constantly being updated by a list of users.
Read here