Thanks for your work. I still have poor understanding of what the reliability issues were, yet I hope this release will be more competitive with Cordn in terms of reliability.

Replies (10)

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...
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.
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.
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.