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?

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 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.