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.
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.
The web platform’s still (for now) really good and fast at working with xml. Kinda wild we ended up with json everywhere.
I thought I was clear about that?
SMF also has not moved in 15 years.
Your experience seems to mirror my own. I still use matrix very little, but have defaulted to use xmpp. Well, really returned to it after so many, many years away from xmpp. I tried prosody, but then after a multi-server cleanup killed it off. I think it was fine. Up next, i'd like to try either self-hosting my own ejabberd server, or if i don't want manage yet another host might consider the paid option of Snikket...or maybe go through jmp.chat which if i recall correctly includes xmpp hosting with some jmp chat paid plan, etc.
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=1853, 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 as the upstream project, 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.
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
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 :)
You guys gave up on the national security threat and caved.
Dont want authorities knocking my door down for using an app
Its funny, I was such a matrix fan boy, and now i'm looking at a chat tech (xmpp) that has been around for tons of years - figure that!
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.
Maybe there was no migration?
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.
EDIT: Also, no proxy settings, meaning your IP address can't be masked with Tor/SOCKS5 proxy.
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.
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.
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, that's increasingly becoming a unique IPv6 address, to every TCP packet header.
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.
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.
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.
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'.
Update: Seeing who I respond to, taking opportunity to mention these recent UX musings.. there used to be 'favorites' in one click in Element, now it is in a drop-down of filters not shown by default (I make distinction of 3 groups 'favorites', 'people', and 'rooms' for all/other. Not using spaces at all (except for the record)). 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. Element web UI in firefox. Oh, I might add very long UI (re)loading times of a browser tab refresh of Element, as somewhat annoying and to avoid.
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.
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
No new complaints: The standard it badgers you to authenticate, then doesn't let you due to errors. Slow to load messages, inconsistent whether edits will show or not, inits channels to an arbitrary time in the past, then you have to click the arrow a few times and wait to get to the latest, the page won't load on mobile, etc.
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
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.
Happy holidays, HN… :)
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?
Arathorn•2h ago
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.
EDIT: I can't face going through all the other points in this post, but it's worth noting that some of it is just entirely false - e.g. the hackea claims of "an impressive collection of private data being sent to Matrix central servers, even when you use your own instance", or the fact that media isn't authed (it has been since Jun 2024). Meanwhile the abuse situation has evolved significantly in 2025, with stuff like https://matrix.org/blog/2025/02/building-a-safer-matrix/ and https://matrix.org/blog/2025/12/policyserv as well as hiring up a larger trust & safety team at the Matrix Foundation.
jdonaldson•2h ago
chaps•2h ago
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.
Arathorn•2h ago
chaps•2h ago
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.
Arathorn•2h ago