I'm so incredibly conflicted about whether to keep investing time and energy and hope around Matrix. I normally have good tech intuition and matrix is in this weird spot. I think the vision and direction and attitudes are amazing but they keep fking up badly.
I'm embarrassed at the thought that I would "soon" soft nudge my friends and family to matrix, years ago. With the state of synapse, matrix.org, and the project in general, I wouldn't consider trying that for another 12-18 months. Or more.
This current news just gives me more pause about leadership and vision. This is a huge "oopsie" to put it nicely. It feels like a massive loss for matrix (bad first impressions, negative impact on network effects, etc) and will undoubtedly be something that matrix detractors will point to for years.
I normally keep quiet about this and just huff more copium because I WANT matrix to succeed, but I wish using Element and matrix as it exists didn't make me feel so ... Idk. Normally by now a tech project with this transcripts hits a steady state but man, the protocol is lacking, element web is just passable at the most generous. Element on Android, I won't even speak about, refer to where I want element to succeed.
To balance this out - Element x has been pleasantly satisfying lately. I'm curious if the team is deliberately taking a different strategy. New Element is working on basically the intersection of what I think are going to be foundational future "stuff" but seem almost to eager. Meanwhile element x is missing for feature but is, still after months of using it, "blazingly fast".
Matrix, at this point, is effectively proprietary. It's fully controlled by one for-profit company (Element) and the blockchain protocol (yes, it uses a blockchain) is complicated enough to prevent independent reimplementations. And it doesn't even work that well.
Sorry I don't think anything you've written here is true:
> 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.
> 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 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.
> 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.
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.
Ridiculous. You joined a mere 6 months ago you didn't have any say in the decisions you are trying to defend now. You aren't even defending them you are just babbling and more emberassing playing personal attacked while deflecting. Matrix is dying and element killed it. Good riddance. I knew the stories were too good to be true but turns out you are just as corp as every other hired gun. There is a reason why they put a community manager in charge of matrix.
Tell us why your spec trails your implementation for months so you basically make sure no one can develop competing server/clients.
I think your vitriol is better directed at me (as Matrix project lead & founder) rather than Josh, whose role as MD for the Foundation is to ensure it gathers $ and distributes it as effectively as possible to support Matrix. The original post here is written by Josh because he took over diplomatics with Libera to give it a fresh start as an independent, given the breakdown in trust on both sides.
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.
If you're talking about Element switching its contributions to Synapse from Apache to AGPL, the rationale is that folks who want to commercialise Synapse will either have to a) opensource their changes, b) pay for an AGPL exception from Element, c) use a different server (e.g. Apache-licensed Conduit from https://conduit.rs) or d) write their own server.
I really appreciate you sharing your concerns, and for all the hope and energy you've put into Matrix to date. Very much to your point, we're not yet in a state where I recommend Matrix to friends and family. Right now I only use it with people in FOSS and other circles where folks are a little more patient with the tech.
Only time will tell, and of course I'm biased as the Matrix.org Foundation's Managing Director, but I think there's good reason to remain hopeful:
The spec continues to evolve with major improvements expected in feature set and performance in the next year as we get to the 2.0 spec release, the Foundation is staffing up and beginning to fundraise, we're on the cusp of holding our first ever community elections to seat a Governing Board, and adoption has continued doubling on an annual basis.
I invite you and anyone else who is invested and/or concerned to join us in the Foundation's new office room – it's a way to get a view into ongoing activities, ask questions, provide direct feedback, and celebrate all the little wins on our way to collective success: https://matrix.to/#/#foundation-office:matrix.org
Drop it. After all the shit they pulled last year (no oss server code anymore, killing bridges, bugged clients) and hiring a PR person you just know they are going for entshitification. I wonder if they will recognize that their commercial offerings are just not up to spec.
Check your facts. Matrix remains an open protocol, under open source license, with open governance, stewarded by a nonprofit. And there remain multiple open source server implementations and clients.
As useful as Cory Doctorow's concept of enshittification is, it has absolutely no utility in describing what is happening here.
Nobody is being locked in, the user experience is incrementally improving as the spec and the implementations evolve, and we're sure as hell not collecting ever more data and using recommendation algorithms to shove advertising down people's throats.
There are plenty of valid critiques. But what you're saying here is just patently absurd.
> with the state of synapse, matrix.org, and the project in general, I wouldn't consider trying that for another 12-18 months. Or more.
Synapse is very stable these days, and relatively resource efficient. Matrix.org (both the server, website, spec and foundation) is in a good place too, as is (from my biased pov as project lead) the project in general.
> This is a huge "oopsie" to put it nicely
We simply don't have the people to do a good job of maintaining the Libera bridge. We tried to jump forwards on it with persistent connections to improve the experience on the Libera side; this caused a tonne of instability; we couldn't move back (given it would have also been seen as a backwards step); we didn't have the manpower to fix it rapidly either; so this is not remotely our preferred outcome. We ran the bridge for almost 8 years; it wasn't perfect; it wasn't a total disaster either; but in the end we overstretched ourselves and Libera pulled the plug.
> It feels like a massive loss for matrix (bad first impressions, negative impact on network effects, etc) and will undoubtedly be something that matrix detractors will point to for years.
Matrix has around 5M native active users based on the phonehome stats, of which ~22k were using the libera bridge. I agree that it's awful for early adopter geeks who love IRC, and I despair that it has happened. But I don't think the sky is falling either.
> Element X has been pleasantly satisfying lately. I'm curious if the team is deliberately taking a different strategy.
Yes, it's a very different strategy. Element isn't working on the legacy mobile apps at all any more (other than for security updates), and rather than being spread too thin over too many projects and codebases (Element Web, Element iOS & Element Android all had zero code in common other than libolm) instead the intention is for Element to focus on one primary codebase (matrix-rust-sdk + Element X and Element Web 'R') and nail it. Meanwhile we don't have the manpower to do a good job of other projects (e.g. Libera bridge, P2P Matrix, Third Room etc.) and so they are on hold for now.
I agree that with 20:20 hindsight this hasn't been the most efficient route to get to where we are today.
Yeah, no. I run both a Matrix server (Synapse) and an XMPP server (Prosody). It is completely obvious when Synapse is running on my server. I don't need ps or systemctl status, I can tell if Synapse is running just by looking at the bars at the top of htop.
Meanwhile my XMPP stuff is as invisible as any other system service.
I appreciate the reply. I just want to repeat, since I feel I was so negative, I like what I know of the matrix folks and I've always appreciated your willingness to dive into these threads. I'll be rooting for y'all until it's clear once again that Matrix is the likely long term future of interoperable chat. If only the world cared to invest in y'all like well, lots of other things.
Re-reading my posts, I guess I could be more specific. Y'all seem like you have great technical vision but are having a hard time with success, growth, and revenue. While I can appreciate some technical bits of Matrix, I would never dare to think I could do better than anyone at those real challenges. It hurts to read about y'all struggling for dev funds, in spite of success. And I feel like that probably weighs on you, it would weigh on me. Godspeed, good luck, I look forward to tomorrow's TWIM :).
Did you solve the funding issues after that Christmas (?) post about not having enough funds? I assume probably not fully given you don't have enough manpower?
No, we didn’t - as the Libera mess demonstrates. We are stuck in a nightmare situation where Matrix is successful, but most commercial projects building on it don’t contribute back either financially or otherwise. We’re now trying to fix that via https://news.ycombinator.com/item?id=38162275.
I'm embarrassed at the thought that I would "soon" soft nudge my friends and family to matrix, years ago. With the state of synapse, matrix.org, and the project in general, I wouldn't consider trying that for another 12-18 months. Or more.
This current news just gives me more pause about leadership and vision. This is a huge "oopsie" to put it nicely. It feels like a massive loss for matrix (bad first impressions, negative impact on network effects, etc) and will undoubtedly be something that matrix detractors will point to for years.
I normally keep quiet about this and just huff more copium because I WANT matrix to succeed, but I wish using Element and matrix as it exists didn't make me feel so ... Idk. Normally by now a tech project with this transcripts hits a steady state but man, the protocol is lacking, element web is just passable at the most generous. Element on Android, I won't even speak about, refer to where I want element to succeed.
To balance this out - Element x has been pleasantly satisfying lately. I'm curious if the team is deliberately taking a different strategy. New Element is working on basically the intersection of what I think are going to be foundational future "stuff" but seem almost to eager. Meanwhile element x is missing for feature but is, still after months of using it, "blazingly fast".