The main difficulty in group messaging is consensus. How does a group of people agree on what key to encrypt the next message too. If people disagree, someone can't decrypt the messages of someone else. That's a fork in the group state, it's quite a similar problem to Bitcoin. Contrary to Bitcoin, in most group messaging systems you know exactly who the group members are, which makes things easier. The main hurdle for marmot specifically is that there is no central server whom you can trust with ordering messages properly. Every client has to be a "fully validating node" and create "the blockchain" of messages so that they're in the exact same order as everyone else. Cordn takes a different approach, each group has one central coordinator who is trusted with message ordering. This massively simplifies the consensus problem, and reduces the amount of complexity in the client. This likely means cordn is relatively more stable than marmot if the coordinator is honest. And cordn uses lots of fancy tricks to make this central coordinator as blind and trust minimized as possible, and easy to run even in a browser tab. This is somewhat similar to Bitcoin CoinJoin, almost impossible to do fully decentralized (only coin shuffle achieved it in theory) so everyone built centralized coordination models (even joinmarket) and then Wasabi optimized the coordinator to be blind and trust minimized. So to some extend Marmot is trying to achieve the impossible, decentralized encrypted group messaging, many wizards keep telling us this is too difficult and probably impossible to achieve. But let's see, it smells to me like we're close on actually making it work...

Replies (13)

Thanks for explaining in such a concise way 🙏 Looking forward, whether White Noise group reliability will in practice become reliable without introducing centralized coordination. Cutting-edge technology indeed. It appears my main misconception about Cordn was that it allows multiple coordinators per group at the same time (yet that would still be some kind of a centralized coordination but with a leader election, similar to what Cassandra-like databases do). @npub1qc8q...twss I don't know whether it's possible with the current Cordn design; just curious, have you possibly considered having multiple coordinators per group which can choose a leader (to make it less dependent on the reliability of a single yet switchable one)?
White Noise is still an experimental attempt to build fully decentralized secret group chats. Currently Armada (Discord-like non-secret decentralized private group chats) and Cordn (secret group chats, relying on coordinator nodes) should be more reliable; both are built on Nostr too. View quoted note →
Has a single coordinating key been implemented already in Marmot? I'd imagine that this is desired in some use cases and serves as a good starting point.
> i'm retarded Me too. It's crazy how this became so complicated. Marmot vs Concord vs Cordn, the way I currently understand them, specifically in relation to group chats: - Marmot—experimental attempt to make decentralized secret chats - Concord—reliable decentralized private non-secret chats (normally keeps storing messages on the relays; newly logged-in clients will retrieve them) - Cordn—reliable secret chats that rely on coordinator servers View quoted note →
> They haven't worked in 4 years > the nip repo has never had a focus on privacy I'm not happy with the reliability of NIP-17, when different implementations are used. Making it optional in clients would be a good thing. What about Cordn though? This one, in an exchange for reliability, doesn't attempt to invent truly decentralized DMs, yet this one is a competitor to Signal and SimpleX in terms of privacy and secrecy. View quoted note →
For example, if Alice creates a group, she can act as the admin without a need for consensus; coordinating messages can be distributed across several relays. No?
The list of group members, and admins, is part of the consensus state. Any member in a group knows exactly who's part of that group, and that only admins can make valid commits. Servers are only trusted for message delivery. Given that every group member somehow gets every commit message, they will converge on a shared state of the group. For now marmot uses nostr relays for message delivery, we're already thinking how to do this with fips, it should work.
The reliability of message delivery of commit messages is the main difficulty, even in the case of a single admin?
Correct, every member MUST have every commit message. (Regular chat messages can be dropped) Only admins can write commits.
A structured network strategy to sync Nostr relays I think can greatly help the persistance and reliability of messages. Negentropy is a huge help. For example, if all admins independently run relays and have write policies exclusive to members/admins, the relays can sync and secure only those messages between each other. Strfry has some support here with a router. However, last I remember, the features were new and could be optimized. I would need to look again.
Yes, and now do this with relays on the phone and fips connection between them, cypherpunk future is now.
Sure, in some cases! Though, the notorious flakey internet connection of phones adds complexity and difficulty. Local messaging use cases could also benefit from wireless connections (e.g., LoRa/Bluetooth/Wi-Fi). In other cases, relays with low latency and high availability would be useful to bolster reliability. For example, with redundant-powered SBC or VPS relay servers with multiple internet connections/transports.