I just read through the Matrix protocol documentation, coming to it from never having heard of Matrix before, and I have to say, it is hot garbage, reading like someone with no distributed systems background and hasn’t heard of lamport clocks or virtual synchrony vibe-coded a shonky mashup of IRC and XMPP and then tried to copy-paste Signal’s crypto in the middle. There are early warning signs in which it extensively reinvents endpoint name resolution, by the time you get to the twelfth attempt to build consensus over group state by sorting a DAG you may, like me, realise their entire project is a lost cause.

Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.

I think you're looking at the outcome of attempting to design a secure open federated system for 12 different major kinds of user, not so much a lack of understanding of distsys stuff. The real problem is federation.

Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.

Well, you’re a little kinder than me, but I also agree entirely; and notwithstanding that it’s certainly a hard problem, I’d hoped/expected to find end-to-end behaviours at the heart of distributed consensus in a modern protocol, and instead it was “the servers are in charge” all over again, cue disappointed frown.

I think I'm being less kind and more pointed, in that I think security is too much to hope for from any federated group secure messenger.

Is that on theoretical or practical grounds? I would love to learn how you would approach the challenge (no snark). I feel lots of developers miss the needed background, pour in a lot of work and then be stuck with it. How can we avoid that?

Is there some settled science, some principles and patterns in distributed security? Like, you want A, now you can only have option 1 or 2. But if you want B too, this only leaves you with option 2, provided you satisfy D too. But the combo D+B rules out any E.

No, there's no science to it at all; it's just a collective action problem. You saw it in Matrix's effort to get all their clients encrypted by default (they were hamstrung by an installed base of popular clients that didn't work that way), and again in the response to Nebuchadnezzar.

That sounds like a social problem again. What foundational materials would you recommend to read though for anyone trying to build something secure and non-centralized? It is a pity that everyone spends a lot of effort in this area, only to learn they did it wrong and having to deal with unfortunate design decisions. That is, if they are honest about it.

You can build secure and noncentralized! What you can't do is build secure and federated, where everyone lives in a shared, broadly reachable namespace comprised of independently operated instances.

I simply wouldn't build a secure group message system to begin with. It's a treacherously hard problem and the very few people who have done it well accomplished that with major UX compromises that put them at long-term disadvantage against schlock like Telegram, and survived mostly due to force-of-nature word of mouth.

If you're going to try, and you want to be rigorous about it, I'd say you need to start by reading the whole history of cryptanalyses of secure messaging systems, even systems you don't care about. Read the papers carefully and work out the attacks for yourself. It's a little like math in that you're only going to figure it out by actually working the examples yourself.

Perhaps you put your finger on it before, in that given the current state-of-the-art, the range of needs is simply too diverse to be met by a single paradigm. Nevertheless I still retain that hope, being disappointed by one effort didn’t break my faith in progress.

I think it's hard to overestimate how much Matrix is doing this on hard mode, in circumstances where they can't iterate or clean things up as they go, because they deliberately set themselves up to have a heterogenous installed base almost from the jump. Seen in that light, what else could they end up with but a ball of mud? Since I think that's basically priced in, I think the right thing to do is try to read between the lines and home in on the "good parts" of the design, rather than reflexively rejecting the whole thing because there are "bad parts" they'll never be rid of.

That, or adopt a "nothing federated can be good" stance. I'm sympathetic to that!

Combining something like FOKS (https://foks.pub) to a messaging system would be pretty neat