NIP-44 limitations plan

[ferantivero]

I've just gone through the cure53 audit doc over NIP-44, and found that forward secrecy limitation could be somehow mitigated by introducing sender-side forward secrecy approach.

Personally, I'm envisioning a Nostr client that could not just share critical but sensitive messages in the future.

Therefore, my general question would be for experts in the Nostr protocol (those who has the big picture) whether you see this mitigation achievable as part of a NIP-44 v<next> or NIP-44 have delivered its most secured version by design already.

Please note Im not incentivizing/pushing for any change in any shape or form. Im just trying to discuss the future plan for limitations on this very NIP but more importantly for the Nostr protocol to some extent.

[staab]

There is some discussion about improving forward secrecy by using a time-based salt with nip 44 v2 (since it's backwards compatible). But I think the real solution is going to involve using some other architecture than relays. It would be possible in theory to wrap nostr in SimpleX or MLS to get all the privacy benefits those protocols offer.

[ferantivero]

Thanks for taking the time and sharing these details over here. Im starting to notice that I've just introduced more noise with this new general discussion on top of an already convoluted topic (so many issues, discussions, gists 😸 around the subject, and most probably the genesis #107).

I think you'd detailed some of reasons but more importantly around the licensing model why SimpleX is not the better call for this. Btw, thanks for writing such an amazing blog post on this subject, Im enjoying every word in there. For those who are reading this, please follow up the blog post over here as well.

It is interesting to read that it seems that without changing the architecture of nostr you don't see this problem being solved 🤔. I would love relays could get this around via some NIP.