Very complicated but it's the only option for large (100+ppl) encrypted private groups. In theory, it requires two centralized services, which we don't have in Nostr. But I think nostr:nprofile1qqspwwwexlwgcrrnwz4zwkze8rq3ncjug8mvgsd96dxx6wzs8ccndmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qg3waehxw309ajhjetn9enrw73wd9hsqwhj0h found a way around these restrictions.
It would be great if it worked. I am still unsure what relays, the public and users can track from one another over time. But it will likely require a Tor-like IP hiding system to make sure relays can identify keys when the app is doing REQs with multiple filters.
What do you mean by “the relays the public and users can track from one another”?
Re: IPs, yes. Relays could triangulate to some degree but usually only for short periods because all the visible group ids change regularly. Tor and some trust in relays is inevitable.
Some relays are collecting and selling information about users, like their interests and so on. Its likely that they will want to collect any info at their disposal to associate accounts/keys/secrets and sell them to the highest bidder. Picture Chainanalysis, but on nostr.
If that breaks the privacy of MLS, then there might not be a reason to do MLS at all.
It doesn't break the privacy of MLS at all. All messages that are sent to relays are done so under ephemeral identities. All REQs that clients do to relays are for arbitrary group IDs that can (and must) change over time; or, in the case of welcome messages, they're REQing for NIP-17 style DMs.
The creator of the group also sets the relays that the group will use for these messages so ideally, clients will only allow users to select relays that support privacy features like the "-" tag to stop event rebroadcasting, etc.
Can the chosen relay link IP-emphemeral identities and start putting a sequence of messages together? Can't they just see when the group id has changed and link the two?
I am not doubting MLS, but I have seen too many people claim privacy until I run their server and start logging down everything every connection does to locate, track and identify each participant.
If the relay can do it. They can either sell that info for profit OR be required by court order to track and identify users. If they can do it, they will do it.
That's why I am using Tor when connecting to DM relays. Every app session is a new Tor exit node. Relays can't know where each message is coming from. It's the only way I found to keep things private.
MLS is certainly not a panacea and it doesn't have any opinions on the transport protocol. This is what I've spent a lot of time trying to come up with.
Yes, you're right, if you use just the MLS encryption aspect of the spec, you're leaving too much available to the relay and that could potentially lead to timing or triangulation/association attacks. Clients that implement MLS based messaging and care about privacy will need to use Tor (or VPNs or proxy relays at a minimum).
I'm implementing all this now and finding lots of little details that have to be managed by the client to do this correctly. Things like rotating your key material as soon as you're added to a group (for PCS), rotating group IDs, potentially using multiple group IDs concurrently, securely storing conversation data on the client, etc.
The reality, I believe, is that these are going to be pretty specialized clients. I'll have library code at the end of this that will make it easier but it's always going to be a significant lift to have strong privacy guarantees.
😳
