For those wondering about my thoughts on @SimpleX Chat '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.
View quoted note →
Login to reply
Replies (27)
No, it's definitely not. We cover this pretty well already actually and it's easy to improve on it in the future.
View quoted note →
well written response — thank you
What does all of this mean in plain English?
trust me bro.
jk. It means that MLS over nostr is better than any centralized MLS implementation can be. and that we already know about the other issues that he surfaced and have a plan on how to mitigate them.
Ty Jeff
That's why WhiteNoise is explicitly called out as not having this problem. You could make it explicit in your docs, as some digging was required to understand that you use existing identity system instead of separate AS.
Thanks. Yeah - I saw (and appreciated) the footnote.
As for participation privacy, users don't seem to accept the lack of in-built transport level protection. As long as relays can track on the IP level who reads which groups, they would have a good enough picture of who participates where. That's why we design future chat relays that would handle group broadcasts as high-traffic messaging clients that don't have any network connections with group members (not even indirect connections).
Can you explain that last point a bit more? I'm not sure what you're saying there.
and auth
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.
View quoted note →
What I mean is that Nostr relays can track which IP addresses read messages from which group IDs, creating an association with transport level identities of the users. While it's indeed mitigated to some extent by Tor/VPN, which was SimpleX design defence early on, the valid criticism of this argument that either Tor should be built into the clients (which wasn't and won't be the case with SimpleX, and is not the case with Nostr clients), as most users won't use Tor, and will assume that declared security properties hold without any additional measures.
What's worse is that even with Tor or VPN, Nostr relays can associate the list of group IDs with client sessions that read them, and observing sessions over time they would be able to statistically "recognise" users by the list of groups they get messages from. To mitigate this risk clients have to use different connections (and Tor circuits) when reading from different groups, and it's neither practical nor part of the spec. SimpleX clients offered this feature (transport isolation) as opt in.
So the response of SimpleX network design that addressed this criticism was using two independent relays in the message routing path, where the first one can see client session and transport address, but cannot see destination message queue address. And the second relay can see destination queue address, but has no information that could identify the transport session of the client. And the clients are programmed to choose relays operated by different parties to mitigate collusion risks.
What I was saying about our future chat relays design is that they are the usual messaging clients under the hood, just high volume, and won't have any network connection to the group members, even an indirect one, as they will be communicating via the existing messaging network.
Also note that Keychat.io and 0xchat.com are additional Nostr clients running MLS implementation, and a little more battle-tested than White Noise. Keychat.io has its own spec and takes its own approach vis a vis some of the points mentioned, and as of now is more robust compared to White Noise (at least in my testing).
Makes sense, keep it simple, private, and free from middlemen. 🚀
There is a POC by @Arjen that implements a similar idea as a nostr proxy relay: 
GitHub
GitHub - Origami74/nostr-epoxy-reverse-proxy: Are operating a relay NERP yet? Use this Nostr Epoxy Reverse Proxy to allow clients to proxy through your relay and earn sats.
Are operating a relay NERP yet? Use this Nostr Epoxy Reverse Proxy to allow clients to proxy through your relay and earn sats. - Origami74/nostr-ep...
I enjoyed reading the article and your response added the remaining nuance. Beautiful!
Fingerprinting is easy, privacy is hard
@JeffG
Wonder if a bloom filter for ID's could help mitigate per connection fingerprinting?
Rlly appreciate this post
View quoted note →
Nostr as a authentication service (layer). I need to remember that one ;) Thx @JeffG
We were actually talking about this yesterday in the team. Short answer; maybe? But we're not going to look at it right now.
Make the thing work, then make it work better.
is @npub1tm99...xn72 in a different implementation of MLS from WhiteNoise?
Thank you - I read both the article and your comments and as a complete non technical I still could not find the answer to the question I’m interested in:
if a pleb just wants a completely private, sovereign and unhackable messaging app to chat with whomever he wants (mainly 1:1 chats and small groups): is simplex better than white noise, or the other way around?
MLS should add #nostr as default AS. 🫡
View quoted note →
MLS should add #nostr as default AS. 🫡
View quoted note →
View quoted note →
doesn't that means signal is also backdoored as it has a central identity server?
Great clarification, question: when is the next update/version released for testflight?
@Amethyst (a NOSTR client) has used built-in TOR for almost a year