nip4e: decoupling encryption from identity

4e.md

@@ -0,0 +1,82 @@
+NIP-4e
+======
+
+Decoupling encryption from identity
+-----------------------------------
+
+`optional` `draft`
+
+This NIP describes a system for users to share private data between their own devices that doesn't rely on all devices holding the user account private key.
+
+### The problem
+
+Currently many NIPs rely on encrypting data from the user to themselves -- such that the data can be accessed later on a different device -- using NIP-04 or NIP-44 and the users as both the sender and the receiver, e.g. [NIP-51](51.md) and [NIP-60](60.md). This works fine, but it assumes all devices have direct or indirect access to the same secret key. This assumption cannot be fulfilled in the case of approaches where the key isn't known, such as when using FROST or MuSig2 signers.
+
+Also, in some use cases having the encryption key be on device can drastically increase performance of encrypting and decrypting stuff, and such a thing is not possible to do while also using [NIP-46](46.md) for keeping the user's main Nostr key safer. It's also not possible to perform any encryption while offline if the encryption keys live in a remote bunker.
+
+There are probably other advantages to not tying the user's identity to the keys used for more mundane things such as encryption, which we can write here later.
+
+### The solution
+
+1. Every client on every device can generate a new _device key_ and store it locally, while making its public key public in a Nostr event.
+2. The first device to come into the world will generate a random _encryption key_.
+3. When another device's _device key_ is spotted, the device that knows the original encryption key encrypts that key to the target device's _device key_ using [NIP-44](44.md) and sends it out.
+4. Encryption and decryption are performed using the _encryption key_ using the [NIP-44](44.md) algorithm, skipping the first step and proceeding with _conversation key_ set to the shared _encryption key_.
+
+### Specifics
+
+All events should be signed by the user's pubkey.
+
+- encryption key announcement (`kind:4330`)
+
+The purpose of this event is for a client to tell other clients that a global encryption key exists (and what is the latest). Each _encryption key_ has an ID given by the first 16 chars of its hex-encoded sha256 hash output.
+
+```jsonc
+{
+  "kind": 4330,
+  "pubkey": "<author pubkey>",
+  "tags": [
+    ["p", "<device pubkey>"],
+    ["latest", "<sha256(encryption-key).take(8).hex()>"]
+  ]
+  // other fields...
+}
+```
+
+- device key announcement event (`kind:4331`)
+
+```jsonc
+{
+  "kind": 4331,
+  "pubkey": "<author pubkey>",
+  "tags": [
+    ["p", "<device pubkey>"]
+  ],
+  "content": "device key for client X on platform Y"
+  // other fields...
+}
+```
+
+- encryption key sharing event (`kind:4332`)
+
+These should be deleted after they're read and used.
+
+```jsonc
+{
+  "kind": 4332,
+  "pubkey": "<author pubkey>",
+  "tags": [
+    ["p", "<device pubkey>"]
+  ],
+  "content": "<nip44_encrypt(encryption-key)>"
+  // other fields...
+}
+```
+
+- Usage
+
+  - clients can rotate the latest _encryption key_ for a user anytime -- any time they do it they should publish a new `kind:4330` event then a new `kind:4332` event for every other client they know of.
+  - clients can rotate their _device key_, which is equivalent to them being a totally new client from the point of view of the other clients.
+  - clients may exclude _device keys_ from other clients known to be compromised by just blacklisting them and then rotating the _encryption key_.
+  - since every new iteration of the _encryption key_ has a natural ID, whenever it is used to encrypt something (for example, a NIP-51 list), the ID should be added to the event as a tag `["ekey", "<id>"]`.
+  - clients should keep track of past _encryption keys_ until they're confident that all the possible events that may have used the previous _encryption key_ were properly decrypted and updated to the latest key.