Clean up NIP 44 #939
Clean up NIP 44 #939
Conversation
…aging), improve formatting and clarify encryption/decryption steps
|
LGDR: Looks Good, Didn't Read |
|
OMG!!! @fiatjaf is just approving stuff without reading it! Looks like a politician 🤣 |
|
I would move Limitations and the first section of V2 to near the end of the file as if it were an appendix. Give them the goods right away. |
|
@vitorpamplona perhaps, but those are limitations of v2 and not of some future v3 - which may be quantum-resistant and forward-secure. |
|
lgtm |
|
90% of people who read this are not going to care about the details, just that it exists and they can use it. Limitations are going to be much more relevant for them, since pretty much all an application developer can do with this spec is misuse it or not misuse it. I also think it's helpful to have the context in mind when getting into the weeds to orient yourself. To @paulmillr's point I put the limitations above the v2 heading because they currently apply to all versions, and many will always apply because they're limitations of nostr's architecture, not the encryption scheme. If we end up with a quantum-resistant v3, we can add a note under that limitation, or re-organize. |
|
We should merge this and keep going. |
| Nostr is a key directory. Every nostr user has their own public key, which solves key | ||
| distribution problems present in other solutions. The goal of this NIP is to have a | ||
| simple way to send messages between nostr accounts that cannot be read by everyone. | ||
| *Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard, |
There was a problem hiding this comment.
@staab apologies for commenting on a very old PR like this, but I'm curious if you could provide guidance on why NIP-44 shouldn't be used as a drop-in replacement for NIP-04.
I'm investigating the best way to replace the NIP-04 usage in NIP-47 (NWC), and I would love to understand the tradeoffs here (should messages be gift wrapped, etc).
There was a problem hiding this comment.
There is ambiguity between NIP-04, the encryption scheme, and NIP-04, the DM kind. NIP-44 is a replacement for the encryption scheme, not the DM scheme.
It should not be replaced in kind:4 DMs because of all the metadata leaks that are incompatible with the DM use case. On NIP-47, you can just use NIP-44 like you have been using NIP-04 encryptions.
There was a problem hiding this comment.
Thanks for the clarification @vitorpamplona!
There was a problem hiding this comment.
Right, nip-04-type dms with nip44 encryption would also be incompatible with all other messaging specs. Using nip 44's encryption for NWC/NC is encouraged, with the caveat that decryption support should happen before people start encrypting messages with nip 44 to avoid interoperability problems.
There was a problem hiding this comment.
That makes sense, thank you! I'm also thinking through how a migration path might work here.
One thing to note is I took out the language about putting an encrypted payload into
contentspecifically, since an encrypted payload could also be placed intags(probably a bad idea in practice, but up to other NIPs to specify). The important thing is that the payload is part of the event's hash and authenticated by its signature.