Shared replaceables via Event-owned keys

[vitorpamplona]

This is the 4th proposal to solve the shared replaceable problem. IMHO this scheme is the winner.

In this one, we create private keys for each shared event and host those keys in the event itself.

Read here

This was extracted from the #1189 PR because it serves many other use cases.

Live Demo: https://sheetstr.amethyst.social/
Code: https://github.com/vitorpamplona/sheetstr

---

As a reminder, the three other proposals are:

1. Using a shared d-tag scheme Shared Replaceables via Shared D-Tag #1192
2. Using a DVM to hold the shared private key Shared Event Ownership through DVMs #1015
3. Using a NIP-46 Signer to hold the shared key (undocumented)

[mikedilger]

I think the general idea of this NIP is fine.

But I think we may have some issues with how tags are defined.

1. Are they kind-specific? Do they have different meanings based on the kind? In this PR and many others, they are not kind-specific (another example would be the proof of work).
2. If the first field is not kind-specific, should we be defining kind-specific 4th fields? It seems strictly that we could, but also that this level of complexity is probably going to bite one or two developers down the road.
3. If that field isn't kind specific, are we sure all the other NIPs and PRs have not made a claim on that slot already?

[vitorpamplona]

Yeah, I went back and forth in that as well. I don't think anyone is using the 4th element for a p-tags but who knows.

We could duplicate tags with a new tag name. So, the event would p tag everyone, but the keys could be in a key tag, like:

val editingKeyPair = nostr.generateKeyPair()

{
  "pubkey": editingKeyPair.publicKey
  "kind": 3xxxx or 1xxxx,
  "tags": [
    ["d", "<unique identifier>"]
    ["p", "<pubkey 1>", "<relay url>" ],
    ["p", "<pubkey 2>", "<relay url>" ],
    ["key", "<pubkey 1>", nip44Encrypt(editingKeyPair.privateKeyHex, editingKeyPair.privateKey, "<pubkey 1>") ],
    ["key", "<pubkey 2>", nip44Encrypt(editingKeyPair.privateKeyHex, editingKeyPair.privateKey, "<pubkey 2>") ],
  ],
  "content": "",
  "sig": signWith(editingKeyPair.privateKey)
  // ...
}

Initially I thought the duplication could become wasteful in cases of large groups, but maybe it's ok.

[Semisol]

It is best to leave this up to the individual use cases. Some use cases may have a better way to transmit the private key than encrypt it + put it publicly, and sometimes you don't want to list all editors.

[vitorpamplona]

@Semisol there is a proposal to use #875's kind 24 to transfer the keys inside wraps. It's a little more cumbersome and there is an issue with rotating keys (how to know which version of the replaceable should use which version of the key kind), but it's possible as well.

I don't know.. I like the simplicity of putting everything in the main event as a base option and then exploring more private ways inside each NIP.