The event's private key MUST be shared with all editors through `p` tags. The key is [NIP-44](44.md)-encrypted to each editor and placed as the 4th element in a regular `p` tag.
Some use cases require separate editing and viewing permissions: the `.content` can be encrypted so that only users with viewing permissions can see the information.
1. find the ciphertext in the `p`-tag for their key
2. decrypt the ciphertext with `nip44Decrypt(tag[3], user.privatekey, event.pubkey)` to get the event's private key in hex.
3. calculate the public key of the shared key.
4. if the public key is the same as `.pubkey`, this is an editing key, if not this is the viewing key
5. if it is the editing key, decrypt all the other `p`-tag keys and find the viewing key
6. once both keys are known, decrypt the `.content` with `nip44Decrypt(event.content, viewingKeyPair.privatekey, event.pubkey)`
### Special Case: No Viewing Keys
If the group if users that only have viewing permissions is empty there won't be a `p`-tag to host the viewing key. In those cases, the `.content` MUST then be encrypted to the editing public key.
Similarly, when decrypting the `.content`, if the receiver client can't find a viewing key, it SHOULD use the editing key to decrypt: `nip44Decrypt(event.content, edittingKeyPair.privateKey, edittingKeyPair.publcKey)`
If any of the event's private keys are lost due to an encrypting bug or if there is a failure to add the ciphertext in the p-tags before signing, and if relays don't have previous versions of this event, the event might become permanently unmodifiable and undecryptable, which can also be a feature in some use cases.
The shared viewing key can be rotated at will but not the editing key
There is no proof that pubkeys are participating in this shared replaceable. The presence of `p` tags MUST not imply support for what's written in the event.