4 ms·

> Matrix is fully open [0] and fully spec'd by the MSCs [1], and stewarded by the Matrix Foundation [2]. Technically correct, but in practice the spec is compl

• camgunz 3y ago
  > That's what "effectively" means. 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.
  • vilunov 3y ago
    > distributed E2E messaging system 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.
    • camgunz 3y ago
      > 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. 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. [0]: https://arewemlsyet.com/ https://arewemlsyet.com/