upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJon Staab <shtaab@gmail.com>2023-12-20 11:35:12 -0800
committerJon Staab <shtaab@gmail.com>2023-12-20 13:01:12 -0800
commit2b78cc9304f775b8391f62b7fe61e99a3fdc905b (patch)
tree61fb7ece288c093c34cdb272d57657af198ce6d6
parent732b0ce0a49fbdfa35dfae164f25ee9db947f1c2 (diff)
Add clarification about not replacing nip 04
-rw-r--r--44.md6
1 files changed, 5 insertions, 1 deletions
diff --git a/44.md b/44.md
index 5093acd..8bc4038 100644
--- a/44.md
+++ b/44.md
@@ -10,6 +10,10 @@ The NIP introduces a new data format for keypair-based encryption. This NIP is v
10to allow multiple algorithm choices to exist simultaneously. This format may be used for 10to allow multiple algorithm choices to exist simultaneously. This format may be used for
11many things, but MUST be used in the context of a signed event as described in NIP 01. 11many 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,
14only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement
15for NIP 04 payloads.
16
13## Versions 17## Versions
14 18
15Currently defined encryption algorithms: 19Currently defined encryption algorithms:
@@ -30,7 +34,7 @@ event. When applying this NIP to any use case, it's important to keep in mind yo
30model and this NIP's limitations. For high-risk situations, users should chat in specialized E2EE 34model and this NIP's limitations. For high-risk situations, users should chat in specialized E2EE
31messaging software and limit use of nostr to exchanging contacts. 35messaging software and limit use of nostr to exchanging contacts.
32 36
33On its own, messages sent using this scheme has a number of important shortcomings: 37On 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