Sometimes hard things are hard, and it turns out a distributed E2E messaging system is one of those things. Same goes for writing a fit-for-purpose C compiler. Doesn't make GCC or the C standard any less open.

> Only one non-Element server is there is "Production ready", and it's dead.

Yeah I think reasonably you're looking at Synapse, Dendrite, and Conduit -- all Element-written. I think the argument was "it's too hard to implement", but someone's done it three times, so it still seems like that's wrong.

> They probably mean the DAG-like structure of rooms, which is a horror to implement, and even more horrifying to implement efficiently.

Op used "blockchain" as a pejorative, which is why I was responding "if you think Merkle trees are blockchains (and I would argue you shouldn't), you think a lot of perfectly fine software is a blockchain." If the argument is that implementing a distributed database is hard, well yeah, it is.

> It does not need to be "proof-of-anything" to be a blockchain

Not strictly, but you need a way to suppress fraudulent chains. Blockchains are Merkle trees with the requirement that the deepest tree is authoritative. They attempt to ensure this by requiring proof-of-*, which makes the creation of a fraudulent tree very computationally intensive, and therefore unlikely to ever catch up to the "real" tree. Matrix has nothing like this.

> There is a consensus protocol between home servers, and it fails terribly, leading to room resets.

Yeah, I think probably a lot of this goes away w/ the switch to MLS. But not all of it, they chose AP out of CAP (correct IMO) so this is just gonna be the way it goes. Your other options are deal with the service being down while it becomes consistent--which would happen constantly--or welcome back IRCs netsplits.