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.
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!
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.