> Matrix, at this point, is effectively proprietary.
Matrix is fully open [0] and fully spec'd by the MSCs [1], and stewarded by the Matrix Foundation [2].
> It's fully controlled by one for-profit company (Element).
2/5 people on the board work for Element [2].
> and the blockchain protocol (yes, it uses a blockchain)
It does not use a blockchain (there is no proof-of-anything). You might be confusing blockchains with Merkle Trees, but in that case you'd also have to think git is a blockchain.
> is complicated enough to prevent independent reimplementations
There are several independent client [3] and server [4] implementations.
> And it doesn't even work that well.
Maybe not, but it has pretty good adoption [5]
[0]: https://github.com/matrix-org
[2]: https://matrix.org/about/
[3]: https://en.wikipedia.org/wiki/Matrix_(protocol)#Clients
[4]: https://en.wikipedia.org/wiki/Matrix_(protocol)#Servers
[5]: https://en.wikipedia.org/wiki/Matrix_(protocol)#Adoption
Technically correct, but in practice the spec is complex enough that there are only 2 more or less working server implementations, both of them developed by the same org. I tried to implement it myself, but in comparison to IRC and XMPP it's just too complex. That's what "effectively" means.
> There are several independent client [3] and server [4] implementations.
Only one non-Element server is there is "Production ready", and it's dead. The website is down and the last commit is from 2021. There were many spec changes since then, including the infamous "sliding window sync", which is necessary for the next gen clients.
> It does not use a blockchain (there is no proof-of-anything). You might be confusing blockchains with Merkle Trees, but in that case you'd also have to think git is a blockchain.
They probably mean the DAG-like structure of rooms, which is a horror to implement, and even more horrifying to implement efficiently. It's a blockchain of sorts, with room events being linked to parent events.
> there is no proof-of-anything
It does not need to be "proof-of-anything" to be a blockchain, that's not why there are words "block" and "chain" are there. There is a consensus protocol between home servers, and it fails terribly, leading to room resets.
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.
The thing is, customers don't necessarily want a distributed messaging system, they might be perfectly fine with a decentralized one if it supports E2EE. Matrix went the way they did and it's far from obvious whether it was a good choice. I'm leaning towards no.
> but someone's done it three times
You can do it however times you want and it will be easy to do if you have access to one of the few domain experts of the protocol. It can be considered easy to implement once someone else successfully implements it and continues to support it for a significant period of time. Rewriting one thing three times inside a single org is not something of interest.
> Blockchains are Merkle trees
This is getting offtopic, but anyway. Blockchains are DAGs, they are not necessarily trees. The canonical chain and candidate blocks have only one genesis block, and non-genesis blocks could have multiple parents (e.g. one main parent and orphaned uncles), which by traverse still converge to the same genesis block.
Although Merkle trees are used in the underlying block data structure, this is orthogonal to the blockchain concept and any data structure could be stored there.
> MLS
Unless I'm missing something about MLS, you're mixing unrelated stuff here.
Maybe! You could argue that basically all the successful messaging systems except for email and IRC (if IRC still counts as successful) are centralized, so there's that.
> You can do it however times you want and it will be easy to do if you have access to one of the few domain experts of the protocol.
In fairness, I don't know how you implement a client/server for a protocol w/o being a domain expert in it. Try building an IRC server, an IMAP server, an ActivityPub server, etc. and remaining ignorant about the details about IRC, IMAP, ActivityPub, etc. This has felt like an odd benchmark to me this whole thread.
> Blockchains are DAGs, they are not necessarily trees.
Eh, I really think they're trees because they're Merkle trees. Each block contains the hash of the previous block, not some random other block as it would be if it were a graph. Even with uncle/orphan blocks, it's still a tree.
> Although Merkle trees are used in the underlying block data structure, this is orthogonal to the blockchain concept and any data structure could be stored there.
Definitely not, because the hashes prove the tree's correctness. You can verify any branch, which you want to do to ensure you're not getting scammed. The Merkle tree concept is essential to the verifiability of blockchains.
> Unless I'm missing something about MLS, you're mixing unrelated stuff here.
Sorry I was a little opaque. Matrix' handling of rooms is suboptimal for lots of reasons, but one is what you pointed out: they don't have great performance and thus desync a lot. MLS has a cool tree-based Ologn algorithm for fixing this. It's a process to get there [0], but I'm excited for when it happens.
So, exercising all due restraint, I say this: your statement is unmoored from reality. I thank @camgunz for chiming in and citing sources.
Tell us why your spec trails your implementation for months so you basically make sure no one can develop competing server/clients.
In terms of Matrix dying, killed by Element: I’m afraid rumours of Matrix's death are highly exaggerated. And Element spends its life helping Matrix come to life rather than death, for better or worse.
The reason the spec trails the implementation for months is precisely the same reason that the formal HTML5 spec trails the implementations for years. It's not some grand conspiracy that Mozilla ships CSS Flexbox behind a vendor prefix for years (decades?) ahead of the feature being finalised in the spec. Instead: the point is that you get to play with the spec change in the wild, prove that it works, iterate on the design, and then eventually propose it for merge into the spec itself.
Personally, I think this is one of the bits of Matrix that we've got right. The spec process doesn't evolve as fast as it could, but that might well be a feature (just like it's a feature that HTML5 moves slowly too, but doesn't stop folks experimenting all over the place on it). https://spec.matrix.org/proposals/ explains the full process and the workflow, in case you want to understand it.
This hardly feels like suffocating competition.