Why We Abandoned Matrix (2024)
Key topics
The dark truth about Matrix's user security and safety has sparked a lively debate, with some commenters defending the platform's efforts to improve its metadata footprint, while others remain skeptical. Arathorn, seemingly a Matrix developer, pointed to ongoing work to address metadata concerns, such as MSC4362, but faced criticism from chaps, who argued that explanations alone won't win long-term support. Meanwhile, the discussion veered into the broader topic of federated messaging, with pmlnr and tptacek engaging in a witty exchange about email being both the "worst available secure messaging system" and the "best widely available" one. As the conversation unfolded, transparency and prioritization emerged as key themes, with some appreciating Matrix's efforts to explain its decisions.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
44m
Peak period
126
0-12h
Avg / period
22.9
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 24, 2025 at 10:06 AM EST
14 days ago
Step 01 - 02First comment
Dec 24, 2025 at 10:50 AM EST
44m after posting
Step 02 - 03Peak activity
126 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 28, 2025 at 4:38 PM EST
9 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
For what it's worth, we've been working on improving Matrix's metadata footprint this year: MSC4362 (https://github.com/matrix-org/matrix-spec-proposals/blob/kay...) got implemented on matrix-js-sdk for encrypting room state (currently behind a labs flag on Element Web: https://github.com/element-hq/element-web/blob/develop/docs/...). Meanwhile more radical proposals like MSC4256 (https://github.com/dklimpel/matrix-spec-proposals/blob/mls-R...) go and remove senders entirely and encrypt room state via MLS.
The reason Matrix hasn't prioritised metadata protection earlier is:
* If you're particularly concerned about metadata footprint, you can run your own servers in whatever network environment you feel like - you are NOT surrendering metadata to some central or 3rd party server as you would in a centralised platform.
* We've had to focus on getting decentralised encryption stable, which turns out to be hard enough without also throwing in metadata protection - it's only this year that we've turned that corner.
* Unless you're using a mixnet, network traffic gives away a significant amount of metadata anyway.
Anyway, yes: Matrix can do better on obfuscating metadata on servers, and we'll continue improving it in 2026.
Meanwhile, if anyone's feeling nostalgic you can see a presentation I wrote preempting the challenge of metadata protection back in 2016 (on the day we first turned on E2EE in Matrix, ironically): https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E.... In some other world perhaps we would have got to this point sooner, but better late than never.
You're not going to win any long-term support with this attitude, even if you're technically right. Like, if we're still in this "why doesn't the pleb just become a part time sysadmin" way of thinking, it's hard to think it's not just DoA.
FWIW, I'm the kind of weirdo who gets annoyed by having to add a new noscript rule for every federated instance. So I'm not exactly Matrix's target audience.
That's the way Matrix goes, but that's not an inherent property of federation (XMPP doesn't leak nearly as much metadata as Matrix does, for instance)
Also, there is no free lunch in this space: p2p is slow and inefficient (bandwidth as much as battery) for modern mobile usecases, the workarounds generally consist of having edge servers to act as caches or preferred routing points, and that brings us back to the exact same set of tradeoffs found in the federation model, except with less control.
In short, I agree with the premise that Matrix is terrible, but not that federation is necessarily bad, nor that P2P is clearly superior.
https://www.reddit.com/r/learnjavascript/comments/qdmzio/dif...
or anything that touches array ops (concatenating, map, etc…). I mean, better and more knowledgeable people than me have written thousands of articles about those footguns and many more.
I am not a webdev, I don't *want* to remember those things, but more often than I would wish, I have to interop with JS, and then I'd rather use a better behaved language that compiles down to JS (there are many very good ones, nowadays) than deal with JS directly, and pray for the best.
Their arguments against the middle ground (federation) made no sense. Yes, some current implementations are flawed in that you can poison caches with spam and csam, but that's not inherent to federation. In fact, it looked more like they were upset that you can't censor federated communities sufficiently to their liking (nuke them out of existence on a whim?). Their main, and really only, argument against Lemmy was group think but...it's a consensus platform, that's its purpose. There is a time and place for communities to build group consensus organically and it's a viral part of society, so while I can understand chafing at that from time to time, I wouldn't call it a protocol failure.
They've lost me right here.
As a counter, Mastodon federation is pretty sweet.
But I really do wish we had doubled down on XMPP. It was nearly everywhere in the late-00’s early-10’s. If we could have just solved the mobile case (which, was solved, just not in popular server versions) then we would have been in a better place today.
Hatred of XML has cost us so many wonderful things, the one that hurts me most is SMF (the solaris init system) which obviated the major issues people have with systemd. Except because it’s using XML people would rather carve off a limb over seriously considering porting it.
I thought I was clear about that?
SMF also has not moved in 15 years.
There's something else hindering XMPP that it stands so still, alternatively it simply can't be improved.
XMPP doesn’t have those people, because there’s little nostalgia and an “ick” feeling about XML.
All those people would rather work on Matrix.
The web platform’s still (for now) really good and fast at working with xml. Kinda wild we ended up with json everywhere.
I am curious, how is this possible? Most non-techies seem to use the app that matches the app that is the most popular one in their area/demographics. For most, that would be Whatsapp i guess. How did you sell your app to your family?
State resolution is just a total mess. On the best of days it's a hideously complicated system that sucks crazy resources, and on the worst of days rooms get blown up and bricked. Supposedly it's not as bad as before, but the fact that rooms can get bricked in the first place is bonkers. Just computing the member list of a room is a disaster due to the complex resolution algorithm - I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
Also years later, we still don't have custom emojis, user statuses, user bios, invite links etc. - very basic things that literally every messaging platform has. https://github.com/element-hq/element-meta/issues/339 https://github.com/element-hq/element-meta/issues/573 https://github.com/element-hq/element-meta/issues/426
I'm interested in hearing if anyone has used simplex and what kind of experience it is. It seems like simplex is going for a similar audience as signal but using a very different approach. I don't think they've really had a breakout though and haven't heard it talked about much.
Not since https://matrix.org/blog/2025/08/project-hydra-improving-stat...
> I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
This is nothing to do with state resolution; it's due to Synapse's implementation deliberately cutting corners on storage efficiency while trading off for speed. I showed how it could be fixed a few months ago here: https://youtu.be/D5zAgVYBuGk?t=185, but we prioritised fixing state resets instead.
> Also years later, we still don't have custom emojis, user statuses, user bios, invite links etc
There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
If speed is a concern, why did you all stick with Synapse (essentially single-threaded due to the GIL) over moving to Dendrite? As far as I can tell, Dendrite is, for all intents and purposes, abandoned.
The hope was always that we would then get back to Dendrite and be able to invest in it and migrate over, but the cash situation got worse in 2022 due to Matrix being more and more successful (causing the available $ in the industry to be flow to integrators rather than the upstream project), and instead we had to essentially park Dendrite dev in 2023 other than for critical fixes.
Meanwhile, to try to fix the $ situation, we added Rust workers to Synapse as "Synapse Pro" to give customers a reason to actually route money to us, and nowadays Element is actually on a more economically sustainable path. However, at this point the likelihood is that rather than progressing Dendrite we'll instead look to add more Rust to Synapse and fix its resource usage. That said, others are of course very welcome to continue progressing Dendrite forwards, and I personally find it super depressing that we failed to progress both servers at the same time.
I thought the goal of Dendrite was decentralization done right? Namely, the ability to run a homeserver from the very phone one is using the client on?
Keep up the great work - your team should be giving you a raise; you’re a great reflection on them.
Also I got your name wrong last time - I apologize for that.
Good to hear. Keep up the good work.
It's specifically to increase the speed if *state resolution*. If it weren't for the convoluted state resolution system, there wouldn't be a need to store gigabytes worth of state groups in the database.
* https://element-hq.github.io/synapse/latest/usage/administra...
* https://github.com/matrix-org/rust-synapse-compress-state
Maybe there's a way to calculate state without state groups, but I sure don't see one that I can use if I were to run a matrix server.
> Not since https://matrix.org/blog/2025/08/project-hydra-improving-stat...
Simply fixes some of the many ways that rooms can explode or be bricked. Zero confidence that room brickings are totally fixed once and for all.
> There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
A funding crunch since 2023 yet those features have been necessary for many years before 2023.
You probably would do that even if there was no state resolution at all
> Simply fixes some of the many ways that rooms can explode or be bricked.
How many other ways are there? Afaik none is known
Before project hydra people didn't know about the room exploit either. They just knew that rooms exploded somehow every once in a while.
As an analogy, it's not dissimilar to how Git has added various different merge resolution approaches over the years in order to come up with more predictable and more "do what i mean" algorithms (resolve, recursive, ORT, octopus, etc). It's slightly different in that a bad merge in Matrix feels very unexpected and problematic, whereas manually unpicking collisions in a VCS is just part of the territory.
No, it's specifically to increase the speed of state retrieval. One of the uses for that is state resolution, but it could equally well just be calling the /messages API or any other point you need to know historical state. But what do I know :)
State groups aren't really a thing for messages in a timeline, there are many easier ways of doing it, for example, simply storing the message sequentially (impossible in matrix though, due to the convoluted tree structure it uses)
But when it comes to state (where state groups are actually needed) who actually needs a snapshot of the state at literally every point in history? Any other messaging app just needs to know the current state and maybe also an audit log of the change history for audit log purposes.
In any sane messaging app (e.g. discord, slack, telegram etc.) there is exactly zero relevance in knowing the member list, room configuration, permissions and room title at exactly 2024-06-19T15:23:45Z. Who the heck cares??? Yet the design of matrix somehow makes this an integral part of every single operation.
But before 2023, the funding was going to things like solving state resolution, a VoIP system that was not dependent on Jitsi, getting rid of "could not decrypt message" errors, and so on.
when compared with the other concerns throughout the thread.
You guys gave up on the national security threat and caved.
Dont want authorities knocking my door down for using an app
How?
Matrix is completely busted, for the article's aforementioned reasons, and others.
My complaints is that ive seen child sexual assault imagery on your primary servers, hours later (and thousands of CSAM images) finally the user banned. And still does it cause some federated server they are connected to still allows them to be half-joined to a room.
The only safer way to federate is to disable image caching and preloading, and ideally defed from matrix.org.
And combined are the laughable moderation tools. I'm sure for some gov deployment, they're not going to spread child sex images. But on the public internet, even basic tooling is a joke.
I recommend all Matrix admins to discontinue. Its frankly too legally dangerous to run it, given all the various failure modes and E2EE failures.
Its 1 size doesnt fit at all. And it being gone would allow others to potentially succeed.
What I don't understand is how multiple governments and militaries are able to make it work. Are they using a reduced core-features-only version?
As a result, the popularity of Matrix in public sector has resulted in focus there - which is somewhat different to the expectations of folks looking for a Discord replacement or a privacy-at-any-cost solution.
Unfortunately, a Discord replacement is the sort of thing that the free software world actually needs, because in its absence people are just using Discord, even for free software projects.
cinny.in
It's got all the downsides of both centralized and distributed chat systems. Matrix.org didn't have the username I wanted so I went through four different home servers before giving up.
Tried to install a cli app (Weechat). Homebrew wanted four or five scripting languages, a spell checker, and still no Matrix plugin (need to install an abandoned C library for that and then wrangle python). The web app is shit. I get hijacking Cmd+K (and despise it), but it also hijacks Cmd+`.
Makes me miss IRC really.
Maybe there was no migration?
https://keet.io/
The entire secure messaging app space is open source, why anyone would bother with writing a proprietary app and thus omit verifiability of the security claims is beyond me.
Do NOT use.
I joined the mozilla matrix, and ironically, this caused the auth system to completely break down for some reason since I would log in each time.
It suggested to reset the whatever login data cookie thing because it did not want to trust me anymore, displaying red warning or whatever.
I asked around, and apparently they disagreed about that strict cookie policy, which felt quite ironic coming from the mozilla community.
Switching to localStorage would help things, but until they do, you can avoid the known failure case for Element Web by not doing that.
Obviously though, they need to figure out a way to reestablish encryption when the keys are gone, as long as you are willing to accept no access to history, or keeping keys encrypted server side.
> They have to be stored somewhere. You want private keys on the public server?
Yes. Encrypted. The feature is called “dehydrated devices” and the Matrix team has been working on it for quite a while now.
https://youtu.be/DdM-XTRyC9c
Which, is fair, but if absolute control of the client is required then there’s no benefit to E2EE.
Also a major point in Signal's development philosophy is building a comms platform that doesn't require that you trust them, because the protocol is built in a way that leaks the absolute minimum of data about the user necessary to make the service usable for the general public.
Why federated protocols don't work (2016) - https://news.ycombinator.com/item?id=30314454 - Feb 2022 (130 comments)
The Ecosystem Is Moving [video] - https://news.ycombinator.com/item?id=21904041 - Dec 2019 (90 comments)
Reflections: The ecosystem is moving - https://news.ycombinator.com/item?id=11668912 - May 2016 (99 comments)
I go back and re-read this pretty much every time a decentralized thing has problems. It rings true.
Lies by omission. SimpleX doesn't mask your IP-address by default. It leaks to the server. The ENTIRE public SimpleX network is hosted by two companies, Akamai and Runonflux. Metadata of two conversing users running on the same VPS can be detected with end-to-end correlation attacks, so pray that the two are not PRISM partners or whatever has replaced that program.
I'd be fine with SimpleX if they
1) bundled Tor and had a toggle switch during initial setup.
2) were transparent about what the toggle switch does (lag/bandwidth vs IP masking)
This is crucial as they already have Tor Onion Service server infra set up, but they're not making it easy for a layperson to use those. Instead they lie by omission. Their
"SimpleX has no identifiers"
only means
"SimpleX does not add additional identifiers"
They don't give a damn about your router gluing your IP address to every TCP packet header.
Not exactly making their own "coin", but definitely involved with cryptocurrency, and if I understand correctly, the vouchers themselves involve blockchain.
We do not plan any coins.
We plain a private payment mechanism for the servers that will utilize blockchain for valid reasons - we call it Community Vouchers. But they are not coins, they are service credits that cannot be created out of nothing (as coins) and cannot be sold - they can only be used to pay for the servers.
It's covered here: https://simplex.chat/vouchers
Whitepaper on that design will be published in early 2026.
Disclaimer: I designed SimpleX network
I understand that servers need to be paid for but that's why I run my own matrix server. So I pay for that and for the users on it. Much nicer than having to trust another party to run them.
You're literally requiring people to buy specific cryptocurrencies to buy your community vouchers.
These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers. All other application-level networks have identifiers of their own, in addition to IP addresses.
The goal of the design is: - to prevent correlation of which IP address communicates with which, - to prevent IP address from servers not chosen by the users.
It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either, as Tor relays are servers too.
The reasons not to embed Tor are listed here: https://simplex.chat/faq/#why-dont-you-embed-tor-in-simplex-...
Disclaimer: I designed SimpleX network, and the founder of SimpleX Chat.
You are promoting SimpleX as an metadata-privacy improvement over Tor Onion Service based messengers like Cwtch, that hides the IP address by default. IP-addresses can be linked to users, and users will have to blindly trust the server is not collecting them. TelCos and ISPs keep logs of those as per data retention laws, so it's not hard to determine who a SimpleX user is if SimpleX wants to disclose that information.
>to prevent correlation of which IP address communicates with which
Which Akamai can do, and Runonflux can do. With 50% probability on per-target basis I might add.
>It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either, as Tor relays are servers too.
Tor relays actively mask the IP of previous node from the next node.
Tor relays do not have access to internal protocol of SimpleX queues etc. SimpleX servers do, so they can collaborate with better efficiency.
Tor relays are chosen at random by the user, and random collaborating entry/exit nodes expose 10 minute windows for ciphertext-only metadata collection without access to IPs. SimpleX has 50% chance same company runs the server of both users.
>I designed SimpleX network, and the founder of SimpleX Chat.
I know. We two have had a looong conversation about this, first in Reddit, then here, then in privacyguides forum, and now again, here. Every single time you run to the hills.
Link your open, honest, non-misleading threat model about you not protecting IP addresses to your front page.
I mean, look how professional https://tryquiet.org/ looks when the treat model is up there in the title bar, and not as a fine print behind menus.
Do that and we're done. I won't call you out anymore.
Isn't it more that they have different use-cases : Matrix is PC-first, while Signal (and Telegram, WhatsApp) are mobile-first, to the point of requiring a phone number ?
It may not be good enough for your grandma, but certainly can support your software dev team, and there are countless of those active most probably. I really like Matrix as a daily driver. Also using Discord and Slack, and to me these look like a UX Christmas trees full of blinking lights, and far from anything you can call 'calm technology'.
Thanks - the Favourites roomlist section will be back shortly; we just hadn't re-added sections to the rewritten roomlist (and in retrospect, probably shouldn't have launched without it). In fact I think they've already landed (experimentally) on the same roomlist component but in the Element X Web playground at https://github.com/element-hq/aurora.
> And then there's paragraph spacing between replies given one after the other, is to small. Setting margin to 10px (think its 4px now) makes a world of improved reading already.
Hm, is that new? Probably something to propose for the compact layout.
That's not a complete fix though. The split between users and groups was also really important. Because the old view showed the top X chats in both categories at the same time. I'm not sure about others but for me the group chats are less important but update more frequently and when they're bunched together the individual user chats get drowned out. Favouriting them all isn't really an option either as I have too many.
There's a filter now but then you don't see group chats at all unless you turn that off again, making it very restless to have to constantly switch.
The recent mandatory room version upgrade required a lot of real coordinated effort across our org.
E.g. technical (not PEBKAK) E2EE issues are rather common and can mean losing all of your messages at unpredictable and uncontrollable times. That's an instant, permanent deal-breaker for many and I've personally had it happen several times. I still get "verify your device" messages for things that haven't logged in in years, and I can't remove them because I just get error messages. So roughly every time I launch the app I have to dismiss multiple security UI things covering up the stuff I actually want to do.
I'm pretty confident I'm an outlier, probably partly because I have kept my account since early Riot days, and for the most part it does work just fine. I stick with it because there are some Matrix groups I jump in occasionally. But for normal personal use I've had a continual trickle of "there is no way I can recommend this to anyone"-level issues, many of them multiple years old now.
It seems like a lot of MSCs are implemented as experimental in Synapse while they are under active development, but sometimes it takes months or years for the MSC to be ratified in a way that is stable for other homeserver implementations to pick it up. One example that immediately comes to mind is sliding sync as well as threading and spaces. And in the case of sliding sync, the proxy deployment helped, I think only Synapse is the only server that actually supported (or maybe currently supports?) it.
My feeling on it maybe isn't backed up by reality or the actual data of development but it makes developing on the ecosystem feel difficult.
The other real blocker to being a Discord-killer imo is the permissions model. Having power levels 0-100 is a lot less flexible than the RBAC-style model that Discord uses. Once Spaces were rolled out, a feature that would have been nice is to restrict access to certain spaces or rooms that are children of that space based on a role, which afaik still is not possible to do with the current permissions implementation.
I can only assume our experience in private servers is way different than people logging into the matrix.org server or in extremely populated rooms?
(0): https://github.com/spantaleev/matrix-docker-ansible-deploy
My primary issue is that they changed the voice chat system, broke existing self hosted installs, and the new system was barely documented. I threw in the towel since I mostly hosted it for myself. Could never fix their livekit stuff.
I wanted to believe, but sadly privacy must be hard-coded or the people with a large set of technical skill, access to AI agents who will restlessly pursue their mission, and a dysfunctional moral compass will attempt to technologically dominate users.
There's no decentralized protocol as they're centered around their developers. Too much human effort and attention has been centered around software.
The ephemeral gibberish of software developers approaches religious like obsession with sigils and notation levels of absurdity. Believe in their scripture! It will see humanity to the promised land!
Meanwhile in meat space everyone I socialize with is tired of software engineers; "they over complicate everything!" is a common refrain.
This little filter bubble is probably fostering asocial mental illness's in many of its disciples
Upon this a roar from the Rubicon Cathedral; we shall make your line go up!
From the Pycon Papalcy; we shall make your line go up!
From the NoCode Choir; we shall make your line go up!
I disagree so much. Yes Federation is hard and it brings lots of new challenges. But with things like Chatcontrol it's the only way we can continue to communicate securely in the EU. Everything that is not federated has a single entity managing it which can be threatened with punitive actions. With federation everyone can run their own server meaning too many people to go after.
I understand these guys don't want it and they have good reason but federation in general should not die.
Anyway I'll read it tonight when I have more time.
(And in fact, discoverability on Mastodon is only less immediate because you don't a central authority making these decision for you. Nothing prevents you from checking out someone who follows and see who follows them and who they follow. It's more work, but you end up with a better result.)
Not everyone interested in doing detective work to find accounts related to their interests. It’s perfectly reasonable to expect social media platforms to help with that discovery.
If preventing centralization is important to you, then you should care about the product experience of the decentralized platforms.
In that case you're just using these platforms for free entertainment in exchange for being advertised to. You're the kind of person whose opinion I really don't care about.
If you run your own single-user fediverse server, you are the admin yourself so most of these aren't problems (although you still don't control your domain name). But it's difficult for most people to maintain their own social media server, so most people don't do this, meaning that they are still subject to the petty tyranny of their social media provider. It's just that instead of Mark Zuckerberg or Elon Musk, it's whatever random person runs the server that they randomly picked to put their account on.
And let me add: no model will prevent against everything. Yes, you're tied to an instance and XYZ - ok, so just pick one of the largest N instances to mitigate that. That's better than having 1 to pick from.
Yes, the fediverse ecosystem is strictly better than using one monolithic social media platform run by a world-famous corporation. The fundamental fediverse account model is still fatally flawed though, and can't be a final solution for self-sovereign social media.
> Yes, you're tied to an instance and XYZ - ok, so just pick one of the largest N instances to mitigate that. That's better than having 1 to pick from.
The fundamental problem isn't having instances to pick from, it's being able to switch instances if and when the people running your instance stop allowing you to use their compute resources to post. Your fediverse identity is tied to whatever specific instance you make the account on, and you effectively can't switch it to another instance - you just make a new account and tell people about it manually. Again, strictly better than having no choice other than Twitter, but it doesn't really free you from someone else's control over your social media posting.
Has anyone done a comparison between Simplex & any specific P2P systems (the P2P coverage in this article is extremely vague & handwave-y) - e.g. something like Scuttlebutt?
Happy holidays, HN… :)
28 more comments available on Hacker News