diff options
| author | Jon Staab <shtaab@gmail.com> | 2023-12-20 11:35:12 -0800 |
|---|---|---|
| committer | Jon Staab <shtaab@gmail.com> | 2023-12-20 13:01:12 -0800 |
| commit | 2b78cc9304f775b8391f62b7fe61e99a3fdc905b (patch) | |
| tree | 61fb7ece288c093c34cdb272d57657af198ce6d6 | |
| parent | 732b0ce0a49fbdfa35dfae164f25ee9db947f1c2 (diff) | |
Add clarification about not replacing nip 04
| -rw-r--r-- | 44.md | 6 |
1 files changed, 5 insertions, 1 deletions
| @@ -10,6 +10,10 @@ The NIP introduces a new data format for keypair-based encryption. This NIP is v | |||
| 10 | to allow multiple algorithm choices to exist simultaneously. This format may be used for | 10 | to allow multiple algorithm choices to exist simultaneously. This format may be used for |
| 11 | many things, but MUST be used in the context of a signed event as described in NIP 01. | 11 | many things, but MUST be used in the context of a signed event as described in NIP 01. |
| 12 | 12 | ||
| 13 | *Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard, | ||
| 14 | only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement | ||
| 15 | for NIP 04 payloads. | ||
| 16 | |||
| 13 | ## Versions | 17 | ## Versions |
| 14 | 18 | ||
| 15 | Currently defined encryption algorithms: | 19 | Currently defined encryption algorithms: |
| @@ -30,7 +34,7 @@ event. When applying this NIP to any use case, it's important to keep in mind yo | |||
| 30 | model and this NIP's limitations. For high-risk situations, users should chat in specialized E2EE | 34 | model and this NIP's limitations. For high-risk situations, users should chat in specialized E2EE |
| 31 | messaging software and limit use of nostr to exchanging contacts. | 35 | messaging software and limit use of nostr to exchanging contacts. |
| 32 | 36 | ||
| 33 | On its own, messages sent using this scheme has a number of important shortcomings: | 37 | On its own, messages sent using this scheme have a number of important shortcomings: |
| 34 | 38 | ||
| 35 | - No deniability: it is possible to prove an event was signed by a particular key | 39 | - No deniability: it is possible to prove an event was signed by a particular key |
| 36 | - No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations | 40 | - No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations |