Readit News(Do they have a podcast or just the YouTube videos?)
The cynical side in me thinks that Matrix was invented by big social media companies trying to keep Open Source from dominating the chat space.
I found Zulip pretty interesting because it’s made a lot of smart UX decisions that let it double as a kind of inbox/task system and serve needs like customer support pretty well.
My main worry would actually be that even though I prefer its UX, the complexity and 2010s-style design would churn some first time users. If anybody has used it for engaging with external users I'd be very keen to learn how that went
This is a bit like saying “CVS works fine; how the hell did they manage to make git/mercurial/monotone/etc so complicated?”
The point of Matrix is to replicate conversation history across participating servers without a single point of control. To make it impossible for a Facebook or similar to act as a gatekeeper on a conversation. It’s decentralised just as a DVCS is.
Just because we haven’t executed well enough yet on the implementation (due to getting stuck between Element and Element X on the clientside, and having to focus on govtech featuees on the serverside to try to keep the lights on) doesn’t mean the underlying idea of replicated chatrooms is bad. It just needs a git-equivalent implementation, where the perf and benefits mean folks stop fixating on the underlying complexity.
For example, if you’re active in any FOSS channels, you’re likely to receive spam invites to rooms containing illegal content (with disturbing room images and names that appear on the invite). This has been a known issue for years, and a high visibility issue about it (with responses from Matrix’s managing director) from last summer remains open and largely unaddressed.
This issue link is for the Element client, but it contains links to several related proposals for home servers, clients, and the protocol, many of which are still open/completely unresolved. Notably, the MSC related to invite blocking via policy servers or suggestions about ignoring invites via client settings.
dang: is HN really the place for competitive marketing crap like this?
This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
Matrix has been in development since 2014 (which is around when I first started using it) so pointing to solutions only just implemented in 2024 or "still being addressed" in 2025 as proof that this is a "hit piece" seems disingenuous to me (especially since this blog post is from 2023, and thus was correct at the time of writing according to your own comment). I understand that you are protective of your project, but having read your comments over the past decade, it seems that you feel the need to reply somewhat dismissively to any criticism.
I don't want to rehash the entire E2EE history here, but that decade-long saga has always bothered me.
The fact I then went through point by point to acknowledge that a few of the other points are still relevant shows that I’m not dismissing it.
Yes, I’m protective of the project, but I’m also irritated at folks who push fake information against it (especially if it’s padding out valid points).
p.s. sorry if this comes across as dismissive of your complaint O:-)
Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues.
Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.
I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
>Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys.
This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed.
The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.
The only scenario i can think of here is either you logged out of all devices on your account (so nobody could encrypt for you as you didn’t exist any more) or the room is impressively corrupt (state resets) or the server is impressively buggy (eg a beta) or the servers can’t actually talk to each other (eg messages are being replicated transitively but keys aren’t).
Please can you report with details so we can actually investigate?
As per the linked conference talks, we went on a gigantic mission to fix this, which based on our telemetry was successful.
Without getting into a point-by-point rebuttal of this, the thing I don't ever seem to see from the Matrix team is a recognition that they need to undo bad decisions they have made, or make major changes in mindset/practices, rather than just saying "Well we're working on fixing Feature XYZ." The responses always seem to be of the form "Yeah, this is bad, but here's how we're working on it" rather than "Here's how we're going to ensure this doesn't happen again."
I think this may be part of why there's a perception that the Matrix/Element team is "defensive". They "listen" in the sense that they recognize people have problems, and to some extent they try to fix those problems, but they also keep moving forward in a way that creates more such problems that they then have to fix. And they don't seem receptive to the idea that it's that underlying modus operandi that should change, rather than just needing more work on this or that specific bug.
The biggest example of this for me is that in all these reflections from Matthew I don't see any recognition that maybe what's needed is not more delivering but less promising. Like there's this:
> And then really finally, I think a large part of it is just disappointment where people have been fans, expecting and hoping Matrix to move faster. We have basically over-promised and then failed to deliver in a fast enough manner. They've been waiting for two years for Element X to become the default, and it isn't, so they haven't started using it themselves, and so it might as well be that Element X stuff hadn't even happened in the first place.
Maybe people would actually be satisfied with Matrix moving slower, if that were done in a clear and deliberate way. But the attitude I always see is "well we're going to move on and get through this and excelsior and so on", and never "We are going to slow down and make sure everything is fully working before we start touting it as a big improvement". It's what happened with communities becoming spaces, it's what happened with enabling e2ee by default, it's what happened with the Element-vs-ElementX transition, it's what happened with various smaller updates that required room upgrades or server upgrades or whatever.
The problem I see with how Matrix/Element are operating is they are unwilling to make sure the system is good before they try to make it popular. They want to roll out update after update, each time proudly declaring how wonderful it is. And yeah, it is wonderful, it's remarkable how much progress has been made. But average users don't want to use a system that is this much in flux. So maybe just wait until it's been stable and working before you tell everyone how great it is? And gradually expand out in larger and larger circles of early-adopter nerds instead of trying to present it as something for use by the general public until. . .it's actually working and stable enough for the general public?
It's not just about "doing more" but about lowering expectations and being willing to grow slowly.
The line you quote from Matrix Live then directly contradicts this, though:
"We have basically over-promised and then failed to deliver in a fast enough manner."
Similarly,
> But the attitude I always see is "well we're going to move on and get through this and excelsior and so on", and never "We are going to slow down and make sure everything is fully working before we start touting it as a big improvement".
The reason that threads & spaces are taking a while to ship in EX is literally because we have slowed down, and made sure everything is fully working before we ship it.
Meanwhile, we killed everything we were working on apart from Element Server Suite (Synapse), Element Web, Element X and Element Call - focusing on moving slowly and getting it right rather than shipping a tonne of experiments.
So yes, in the past this was definitely a massive failure mode. But it should be obvious that precisely the stepchange that you're asking for has already happened.