Replies (34)

“This essay is purposefully provocative. It has no intention to offend anybody” lol
I have ZERO understanding of the topic, it's just my conclusion from footnote (3) 😅
the axiom's avatar
the axiom 4 months ago
MLS is garbage made by retarded academics that have lost their touch with the real world long ago
the axiom's avatar
the axiom 4 months ago
large groups should be assumed to be public anyway, MLS is much worse than the signal protocol
frphank's avatar
frphank 4 months ago
It seems the AS is a mapping from some other identity to a pubkey. This is a worry if there is an "other" identity. @SimpleX Chat just like nostr already has pubkey identities, so what's the problem.
Keychat's avatar
Keychat 4 months ago
—the lack of participation privacy If you understand that in Keychat ID are decoupled from sending/receiving addresses and addresses are continuously rotated, you’ll realize it’s almost impossible for a message relay to identify the participants in a group.
Keychat's avatar Keychat
Evolution of Receiving Addresses in Signal, Simplex Chat, and Keychat A receiving address is indispensable to any chat application—just as an envelope needs only the recipient’s address. Because this address is exposed plaintext metadata, its design determines how much metadata privacy the user enjoys. Signal each user has a single receiving address that is also their ID. For Bob and Carl alike, Alice’s address is always the same—simply A—and it never changes. Simplex Chat Here, the receiving address (smp://<queueKey>@<relay-host>/<queueId>) is different for every contact. Alice has one fixed address for Bob, A(b), and another for Carl, A(c). Having separate—but constant—addresses for each contact is already a significant improvement over Signal’s single, global address. Keychat Keychat goes a step further: the address not only differs per contact but also rotates over time. Alice begins with A(b1)for Bob and A(c1) for Carl; after she replies, they become A(b2) and A(c2), and so on. Each time Alice responds to Bob, her address is refreshed. This dynamic, per-contact rotation provides even stronger privacy than Simplex’s static per-contact addresses.
View quoted note →
Keychat's avatar
Keychat 4 months ago
Because sending addresses are decoupled from IDs and constantly change, a message relay cannot reliably infer who is in the group.
hoppe2's avatar
hoppe2 4 months ago
I'm not sure if I understand correctly. Anyway, this is how I understand it. In a typical messenger with MLS: I can't know if the person being added is really the one I invited. In Nostr with MLS: I can know
If a Nostr relay requires AUTH—as based on a paid subscription—it would be one way a pubkey/npub could be associated with a group ID (the only metadata available, afaik). The other would be based on an IP, but that is similar to Signal et al (and mitigated with VPNs and etc). E-cash 'blind signatures' seem to be the best solution for relay 'subscriptions' without knowledge of a pubkey. It was designed for this scenario, even if from 1981.
White Noise and ANY application using nostr for identities can completely ignore this article. It simply doesn't apply, since nostr IS the "Authentication Service" mentioned here.
We don't have an "Authentication service" that issues and verifies a user's identity. We use nostr pubkeys for identity. I also think that we avoid the "participation privacy" issue that he mentions in the article but want to clarify what he means with him before claiming anything. 😉
This has the same problem that was drawing criticism with early design of SimpleX network - while there is no persistent/observable identity on the protocol level, there is a fixed transport identity - relays can see which IP addresses communicate with which IP addresses. So it would require a similar solution to what we did with SimpleX network to mitigate it.
As for address rotation, it's currently possible manually, so they are not completely static, and this feature is used a lot, and it will be automatic next year. The challenge with automatic rotation is reduced usability - data backups do not allow restoring connections, so it requires smarter approach to make sure that the solution is usable.
frphank's avatar
frphank 4 months ago
Yes that's what I'm confused about. @SimpleX Chat identities are pubkeys too so what's the problem adopting MLS.
frphank's avatar
frphank 4 months ago
What's not mentioned is how @SimpleX Chat is different from Whitenoise. Both use pubkeys as identities so both can use MLS without AS.
Keychat's avatar
Keychat 4 months ago
Keychat’s receiving address is updated using the Signal double ratchet, and so far rotating the receiving address has had almost no impact on the stability of message reception.
You've established yourself as the secure chat. No refute there. But you're not usable. -Notifications are shit. -No cross device support. -A sea of technical settings. -Backups are a disaster. -Delivery is iffy. Put the SIMPLE back in SimpleX, and make it as easy to use as Session. Pre-set all settings, clean the UX, make notifs work, add multi-device support, make backups easy and use a seed phrase to unlock them. Then you will be my go to. Till then, it's Session for me.
Honestly they should make it where if only one device can carry the chat database, then a desktop or server should be the primary device and then a phone or other devices can link to it. Their current solution of linking a mobile to a desktop doesn't really work (at least on iOS) because mobile devices have issues running background processes. I've never tried Session, and I don't know many people who use SimpleX. I do like SimpleX's idea of no accounts though (Session has accounts).