founder of simplex chat on why he is not integrating mls:
https://www.poberezkin.com/posts/2025-08-12-mls-the-naked-king-of-end-to-end-encryption.html
Discussion
Isnt nostr chat apps are as secure if not more
nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qyv8wumn8ghj7mn0wd68ytngv9ekscnpdenjumnv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcwlfhcq nostr:nprofile1qqst0mtgkp3du662ztj3l4fgts0purksu5fgek5n4vgmg9gt2hkn9lqpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7qglwaehxw309aex2mrp0yh8gmmhv9exgumvd93x2un50yhxxmmd9uqsuamnwvaz7tmwdaejumr0dshsy7xvzx
I am curious about this statement: A notable exception here is Nostr-based WhiteNoise that avoids the need for an authentication service, relying on user identities being their public keys. The main downside of WhiteNoise remains the lack of participation privacy, as relays have knowledge of all groups where the user participates.↩︎
But the beauty being you can infinite identities, or use a repay by a memeber of the group. Everyone in a group knows you are in a group after all, if you don't one someone knowing you're in a group, use a different identity. Does whitenoise have invite only groups? You could trampoline hop into an anon group and use public relays if you were lazy.
Only happens on relays that require auth?
In nip-ee, both the sender and the receiver can be random pubkeys.
Can't relays sniff something from the combination of auth, welcome event, group ID, and IP address?
If a relay requires auth, then yes — it could sniff some information. As for the other points:
– The welcome event is wrapped in a NIP-17 DM, so it’s not linked to the MLS group.
– Group IDs can be rotated, even per message.
– IPs can be hidden by using the Tor network.
Also, some information can be obtained from the req, but auth is required to identify the sender.
Thanks for elaborating. Ultimately, it means each group should use its own relay.
So - we don't have the AS issue because Nostr is our AS. We use pubkeys verify authenticity and you're trusting the key package events signed by those keys when you're adding someone to a group.
AFAICT, the participation privacy question is about relays being able to see what groups you're in by seeing what group IDs you're requesting. I believe that we've mitigated this pretty well since we're using random (and rotating) identifier(s) for each group (yes, it can be more than one).
We also want to eventually break up the requests into lots of different reqs/subscriptions (probably done over Tor or something similar) to further obfuscate this info.
Well he does have a point. MLS seems a bit over the top compared to simpler solutions.
For anyone who wants a summary:
In retrospect, I should have just copypastaed 😂
**Summary of "MLS: The Naked King of End-to-End Encryption"**
The article critiques the Messaging Layer Security (MLS) protocol, a widely-adopted solution for end-to-end encryption in large groups. The author argues that MLS fails to effectively solve the problem of end-to-end encryption in large groups due to its reliance on a trusted authentication service, which can be compromised by the communication provider.
**Key Points:**
* MLS requires trust in the communication provider, which contradicts the purpose of end-to-end encryption.
* The authentication service in MLS can be compromised, allowing the provider to read messages between members.
* The author suggests that simpler alternatives, such as Signal's approach, are more effective and secure for medium-sized groups.
* MLS's complexity and high development costs make it less practical for widespread adoption.
**Conclusion:**
The author concludes that MLS, despite its adoption by many technology companies, is not a reliable solution for end-to-end encryption in large groups. They recommend considering alternative solutions that prioritize user security and privacy.
Would you like me to elaborate on any of these points?
nostr:nprofile1qqsrmd72g25ws0qyh4fvaqm2nqvtd6g9960r42zaytpt83c47ysljmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshs540lpz
is the provider the relay, in the case of mls on nostr ?
Nope, the entire nostr network is our authentication service.
He makes a very fair point, both protocols can coexist for different purposes and maybe evolve towards more interop much later.
Neither has cracked the most important aspect of protocols: adoption
Also how many groups are going to be of a size that Signal cannot handle with ease?
For those wondering about my thoughts on nostr:nprofile1qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqgdwaehxw309ahx7uewd3hkcqpqexv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csna6fpr 's latest article about MLS. tl;dr - I think it's pretty balanced and describes something that we (and the MLS folks) have known from the start. If you have a centralized identity/authentication service telling you who is who, you are trusting them with a pretty important part of the system.
As he points out, NIP-EE (the spec about how to use MLS on Nostr) and, by extension, White Noise doesn't have the authentication service problem because Nostr is our AS. We use pubkeys for identity in groups and you're trusting the key package events signed by those keys when you're adding someone to a group. ✅
In general, this is an issue for other MLS implementations though. The authentication service is a "trusted" third party, with all the trappings.
AFAICT, the "participation privacy" question is about relays being able to see what groups you're in via the group ID values you're requesting events for.
There are two points to make here. First, relays can see what group IDs a given IP address is requesting events for. I believe that we have mitigated this pretty well since we're using random (and rotating) identifier(s) for each group (yes, by design, a single group have more than one visible ID value at a time). Obviously, this is also mitigated by using a VPN or Tor to make requests to relays. We don't yet but White Noise will eventually break up these requests into lots of different reqs/subscriptions (probably done over Tor or something similar) to help here.
One thing that he didn't mention but is worth talking about; relays see events with a given "h" tag (the group ID I talked about above). Practically, this means that watching a given group ID value gives relays some idea of the relative amount of activity for a given group. Critically though, they can't see the number or identities of it's members, since all those messages are published via ephemeral keys. It's just a relative amount of activity (at least until the group rotates it's group ID).
Happy to answer more questions from folks on the article or on MLS.
well written response — thank you
But please note the comment in the post (and Nostr post), that Whitenoise smartly avoided authentication service problem.
What is the most annoying is that this problem is never mentioned in announcements of companies rolling it out and in media publications about MLS.
Whitenoise didn't "smartly" avoid it. Pubkeys and the identity in nostr, as they are in nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhkummnw3ezummcw3ezuer9wchsx06t26
The AS is a hack to bridge legacy systems that are based on string/"human readable" identifiers into the modern world of pubkey identities.