I really wanted matrix to succeed, but I've completely and entirely given up on it now.
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.
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.
I also wanted - and still want - matrix to succeed! But, i've also semi-given up. I still use it because there a small number of folks i still chat with; though that's dying off. I managed a synapse home server very early in matrix's life, for a few years, and yeah it was complex back then...and for me the security is fine. Sure, there are gaps and things to be address for security...but, overall the thing that grinds my gears are the heavy resources needed. I started returning to xmpp. Is xmpp "simpler" or "more secure"? I would reply: no. But, you know where xmpp is really great? Ridiculously low needs for resources for a server! I understand that in this day and age we have far more access to so much more computing power...But, why should we allow bloat just because we can? Sorry, nowadays if I'm just trying to provide for chat, I'm looking into xmpp. I have no experience with simplex, but i think i'll wait til it bakes a bit more (and also see the resources usage story in a year or so).
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!
At this point I just want them to die off completely so we could get something better. They have been unable to make real improvements that make using Matrix a nice experience. And their existence somehow inhibits other solutions from emerging in the OSS community chat space.
People new to the system think that Matrix can work. So FLOSS devs spend time trying to lipstick the pig. Takes time away from other areas.
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.
They're typically operating in private or semi-private federations, and so aren't so worried about spam/abuse issues like the one in question here. They may also not care as much about serverside metadata footprint (or indeed they may actually require serverside metadata in order for the server admins to enforce who can talk to who).
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.
> 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.
I think you could get pretty close with OAuth2. You could also have the frontend be a centralized app, but allow people to host their own servers. If the entity controlling the frontend goes off the rails you still have a pretty simple exit strategy.
This is an astute comment, despite "Arathorn" CEO of Matrix LLC's downvote ring pushing down the score. (Hey bud you know you can just read without commenting, right? Sit and listen for awhile)
ActivityPub has the same problem. Browse a Japanese MissKey server and it'll start loading yours up with questionable drawings. I turned off my server FAST
This is a big, big problem for federated software that I have not seen addressed or even frequently discussed. Arbitrary file upload by the public is not something small operators can reasonably allow on their servers.
Even large operators of non federated systems with controlled access like Facebook struggle with this. It's impossible to protect yourself as a server operator on Matrix or ActivityPub from malicious actors that want to use your server to distribute illegal material, and you'll be the one found liable!
Hosting any publicly uploaded content is a bad decision and a problem since e-mail. IRC and MQTT with QoS 0 do not have this problem. They have others though. At least criminals won't use them because of how easy is to snoop.
half baked solutions often "crowd out" potential better solutions. If something works enough, someone is less likely to make one that works well. Especially when there's a network effect involved.
As someone who wants to care not at all about the implementation details: last week I tried to sign up and use Matrix. I just want it to die.
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+`.
> 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.
Because we didn't have enough people or cash to do a good job of simultaneously writing two servers, and as Synapse had gone into production across *.gouv.fr and other critical deployments, we instead frantically backported Dendrite's main novelties to Synapse - adding instead worker processes to Synapse so it could easily scale beyond the GIL: https://matrix.org/blog/2020/11/03/how-we-fixed-synapse-s-sc...
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.
Matrix team is doing a solid job of running - Keep it up and keep eating the Slack/Teams marketshare up with competitive features and pricing. Additional business considerations like HQ location costs, tax liabilities, and talent pool availability on paper also affect what you have to work with. London tax, talent, and labor pay versus Austin for example.
Also I got your name wrong last time - I apologize for that.
What’s the best way to fund development of this stuff? I’m aware of donating to the matrix.org foundation, but as far as I can tell none of that goes towards funding server and client implementations since those are Element instead of the foundation.
> the likelihood is that rather than progressing Dendrite we'll instead look to add more Rust to Synapse
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?
Dendrite did subsequently switch to powering the P2P Matrix work… which also got paused in 2023. We’re currently resurrecting it, but it’s not clear whether Dendrite will be the clientside server impl.
> 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.
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.
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.
> A funding crunch since 2023 yet those features have been necessary for many years before 2023.
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.
> 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.
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 :)
> it could equally well just be calling the /messages API or any other point you need to know historical state.
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.
Perhaps just watch the video and see that the proposed solution is just doing a temporal state table - just as Slack and Discord etc must have in order to know what the state of a room was at some point in time.
Slack and discord don't know the state of the room at any given time in the past. Show me anywhere in slack or discord where you can see the membership of a room at 2024-06-19T15:23:45Z. Or anywhere where you can see the historical profile picture and nickname of everyone in the room at 2024-06-19T15:23:45Z. You can't, because they don't know.
I am pretty confident that slack and discord know who has permission to read a message at a given point in time, which is all that state groups are achieving here.
No, they all need to know who had permission to read a message which was sent at a given point in the timeline. This is all state groups is: a track of the room state at the point a message was sent: e.g. who has permission to read it.
I repeat: I am pretty confident they only know who has permission to read it right now.
It works like this: their server gets a request to read messages, and checks if the client currently has permission to read messages. If so, it reads the messages. If not, it returns a permission error. If you don't have permission, it doesn't attempt to analyze history to figure out whether you had permission in the past.
In fact, Discord is pretty explicit about not letting you have any interaction with things you don't have permission to view. It doesn't even tell you you don't have permission. It just silently removes them from your menu, and if you try to access them with a link, it tells you "unknown error".
Most people actually working on Matrix have been aware of state resets for quite a while. Hydra is just the name of the project which addresses them. There are 3 phases, of which the 1st covers the most serious ones; the 2nd and 3rd phases should drop next year.
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.
I used it for a year or so, with the default servers, worked just fine. We tried to get a group chat over from Signal to SimpleX but were unsuccessful in the end for unknown reasons. It just petered out and I didn't reinstall it on a new phone.
I still wonder why my experience and the experience of my friends, community and family with Matrix has been so positive compared to what people describe all of the time. Maybe it's because something changed in ~2025 when I started using it again? Both Beeper (my main Matrix provider, the one that preconfigures WhatsApp, Signal, SMS etc. bridges) and Element (the new mobile app and EMS for hosting). I onboarded something like two dozend non-technical people to it, and they are all happily using it every day, mostly to use the bridges that come with Beeper. Haven't heard a single complaint, even switching devices just works now. Almost all communities I care about (GNOME and so on) have Matrix servers, and since the spaces feature launched it's been really competitive with Discord, even UX-wise thanks to the new apps on desktop and mobile. Yet all I hear on HN and elsewhere is people complaining about UX issues that just have not appeared a single time for myself. Maybe it's people using non-compliant clients, old servers, or some other strange configuration? It's a mystery to me.
My best theory here is that because Matrix is actually quite close to being really good, folks get very upset about the remaining flaws, especially when the last few years have had to prioritise development for public sector deployments over being a Discord killer, in order to keep the lights on.
Yes, that is my impression also. Extensively using for a couple of years, and only occasional quirks now and then, e.g. a profile verification issue (seeing the annoying red shields to each comment), but easily fixed. Or a UX update that doesn't necessary feel improvement (this is an Element thing, really).
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.
> Update: Seeing who I respond to, taking opportunity to mention these recent UX musings
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.
> 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.
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.
However it's great to see the favs are coming back.
Given the people / rooms section split was my idea in the first place, i can try to make a case to have it as an option. (Interestingly I haven’t missed it much)
I think you're partially correct. People are upset at the time it takes to land even the most basic of fixes. Replies being bright red might be one of the most indicative examples. So while the work towards public sector deployments has probably helped with some aspects, the user-facing side has stagnated and people dislike that.
My experience has been in an enterprise environment but Matrix still falls way short of common enterprise messaging suites like Slask or even Teams. The effort has mostly been in managing channels.
The recent mandatory room version upgrade required a lot of real coordinated effort across our org.
Yup, this makes sense. I host a Matrix server, and it's equivalent in quality to Discord or anything else. Except that I've had a single unread badge on my account on iOS for at least a year now. It drives me nuts.
yup. https://github.com/element-hq/element-x-ios/issues/3151 is a real wart; we're finally at the point now where the push notification process can synchronise with the main process to get the badge count right. Sorry it's taken so long to fix.
Self hosting experience went well, but it was very confusing for people moving from Discord about a year ago. If it's still the same, there's literally no way to simply send a registration or channel invite link to someone, and have them onboard through your home server by default without the need to explain "Oh, you have to change this URL to that" etc.
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.
Can also vouch for this ansible script. I just updated a very outdated homeserver, postgres, and switched from nginx to traefik, and it was extremely painless. I was dreading it, but it worked amazingly. I donated to the author yesterday because of how well it went.
For what it's worth, I have had zero issues with Matrix myself. Some friends and I use it to stay in touch and we have had a very smooth experience. I'm not trying to discount the issues people have had, but for me Matrix has Just Worked (TM).
It used to be much worse before Sliding Sync was in widespread use... often just logging in would be next to impossible for me depending on the exact client I used and how much old state there was to fast-forward to... many minutes would go by stuck at "logging in..." as it downloaded gigabytes of god-knows-what.
>Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users
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.
> "SimpleX has no identifiers" only means "SimpleX does not add additional identifiers"
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.
>These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers.
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
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.
>Tor does not achieve that either, as Tor relays are servers too.
This is ridiculous. You're effectively arguing, that because Tor isn't literally magical in being able to send TCP packets without IP addresses in headers, it's not significant improvement. As I showed you last time, the NSA itself has admitted they will NEVER be able to deanonymize all Tor users all the time, and that nor are they able to do that on-demand. Which is quite different from your "we run servers on two VPS companies ourselves, but pinky promise, they don't aggregate and correlate information."
>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 to your front page. Make sure it makes it extremely clear that "Unless you install and configure Tor, SimpleX client does not take actions to hide your IP-address from the server".
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.
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.
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.
Didn't knew. Do you have a source on that? Can't see any mention of coins in their blog. Are you maybe referring to the crypto exchange with the same name that normally appears on top of google searches?
Not exactly making their own "coin", but definitely involved with cryptocurrency, and if I understand correctly, the vouchers themselves involve blockchain.
I don't have opinions about Matrix (a more-secure version of Discord or IRC seems like a reasonable thing to want) but want to put a word in for reading the Nebuchadnezzar paper, which is kind of a master class in cryptanalyzing secure messaging protocols, and really drives the point home that the hard part of a group secure messaging system isn't encrypting messages (anybody can do that) but rather in securely managing group membership without trusting servers:
I just read through the Matrix protocol documentation, coming to it from never having heard of Matrix before, and I have to say, it is hot garbage, reading like someone with no distributed systems background and hasn’t heard of lamport clocks or virtual synchrony vibe-coded a shonky mashup of IRC and XMPP and then tried to copy-paste Signal’s crypto in the middle. There are early warning signs in which it extensively reinvents endpoint name resolution, by the time you get to the twelfth attempt to build consensus over group state by sorting a DAG you may, like me, realise their entire project is a lost cause.
Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.
I think you're looking at the outcome of attempting to design a secure open federated system for 12 different major kinds of user, not so much a lack of understanding of distsys stuff. The real problem is federation.
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.
Well, you’re a little kinder than me, but I also agree entirely; and notwithstanding that it’s certainly a hard problem, I’d hoped/expected to find end-to-end behaviours at the heart of distributed consensus in a modern protocol, and instead it was “the servers are in charge” all over again, cue disappointed frown.
Is that on theoretical or practical grounds? I would love to learn how you would approach the challenge (no snark). I feel lots of developers miss the needed background, pour in a lot of work and then be stuck with it. How can we avoid that?
Is there some settled science, some principles and patterns in distributed security? Like, you want A, now you can only have option 1 or 2. But if you want B too, this only leaves you with option 2, provided you satisfy D too. But the combo D+B rules out any E.
No, there's no science to it at all; it's just a collective action problem. You saw it in Matrix's effort to get all their clients encrypted by default (they were hamstrung by an installed base of popular clients that didn't work that way), and again in the response to Nebuchadnezzar.
That sounds like a social problem again. What foundational materials would you recommend to read though for anyone trying to build something secure and non-centralized? It is a pity that everyone spends a lot of effort in this area, only to learn they did it wrong and having to deal with unfortunate design decisions. That is, if they are honest about it.
You can build secure and noncentralized! What you can't do is build secure and federated, where everyone lives in a shared, broadly reachable namespace comprised of independently operated instances.
I simply wouldn't build a secure group message system to begin with. It's a treacherously hard problem and the very few people who have done it well accomplished that with major UX compromises that put them at long-term disadvantage against schlock like Telegram, and survived mostly due to force-of-nature word of mouth.
If you're going to try, and you want to be rigorous about it, I'd say you need to start by reading the whole history of cryptanalyses of secure messaging systems, even systems you don't care about. Read the papers carefully and work out the attacks for yourself. It's a little like math in that you're only going to figure it out by actually working the examples yourself.
Perhaps you put your finger on it before, in that given the current state-of-the-art, the range of needs is simply too diverse to be met by a single paradigm. Nevertheless I still retain that hope, being disappointed by one effort didn’t break my faith in progress.
I think it's hard to overestimate how much Matrix is doing this on hard mode, in circumstances where they can't iterate or clean things up as they go, because they deliberately set themselves up to have a heterogenous installed base almost from the jump. Seen in that light, what else could they end up with but a ball of mud? Since I think that's basically priced in, I think the right thing to do is try to read between the lines and home in on the "good parts" of the design, rather than reflexively rejecting the whole thing because there are "bad parts" they'll never be rid of.
That, or adopt a "nothing federated can be good" stance. I'm sympathetic to that!
I've been on Matrix for 6 years or so. Some of that time was painful (especially when the largest public server was overloaded by a surge of new users in 2020). It's better now. I can't remember the last time I saw a decryption failure.
I still have gripes about it. Improvements to the spec and software have been slow lately, due to funding issues. But they are still arriving. The official desktop client remains buggy, bloated, and cluttered. But there are lighter alternatives that do what I need 99% of the time. Much of the meta-data is not yet end-to-end encrypted. But that's still planned, and since it's not as important in my day-to-day chats as it might be if I were whistleblowing, I'm willing to wait.
I continue to use Matrix because there is nothing else offering the combination of features that I most value in it. Notably:
- decentralized
- 1:1 and group chats
- offline message delivery
- multi-device support
- end-to-end message encryption with well-understood ciphers and protocols
- easy enough that I have brought in non-tech-savvy contacts with very little assistance
- cross-platform, on every major desktop and mobile OS
- not tied to google services or libraries
- open-source
- free (in both senses)
- self-hostable
- reasonably anonymous; no need for a real name, phone number, or (depending on homeserver) even an email address
- (in development) scalable audio/video chat that looks very promising
Harder to quantify, but also worth acknowledging: The project lead seems very level-headed, demonstrating good judgment and tremendous patience, and consistently makes himself and the inner workings of this difficult project accessible to the public. This gives me the sense that Matrix continues to develop with sound guidance. Thanks, Arathorn!
Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use.
Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse.
(And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.)
I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
Also, STUN/TURN is not sufficient to handle scalable voice and video conferencing. It would take care of NAT traversal, but can't do anything about the bandwidth problem: Each participant would have to maintain a bidirectional A/V channel to each other participant. Many residential internet connections would struggle quickly, and mobile phone bandwidth even more quickly.
Adding a selective forwarding unit could solve the outbound bandwidth problem (each participant would then only need one outgoing A/V channel) but can't help with the incoming bandwidth problem (each participant would still need to receive the A/V stream of each other participant). It can't compete with the Matrix design as I understand it.
A sufficiently powerful multipoint control unit could solve the bandwidth problem in both directions. But as far as I know, MCUs capable of handling big conferences are not cheap.
In other words, I think pmlnr's XMPP endorsement underestimates what it takes to do scalable audio/video chat.
Moxie (Signal Founder) gave a talk about the issues with federation at CCC in 2020, he took a crazy amount of flak for it, a lot of it from the Matrix community. Lots of the issue highlighted are in this post.
Just gave it a listen. A lot of what he asserts seems pretty obvious with many examples e.g. the ones he give about IP, DNS, email etc. Centralized movers will always have the advantage of coordination, so decentralized systems have to have a damn good raison d'etre that's immediately obvious (e.g. Tor) or else be eventually consigned to niche use in highly idealistic communities.
The message I got was more "decentralized services have major coordination issues that prevent them from adapting to changing needs".
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.
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.
Fair enough I haven't had a chance to read the whole thing through, just had to skim eg the Matrix criticism. But if it's completely decentralised, why are there servers that must be paid?
Anyway I'll read it tonight when I have more time.
Same. Also, see how cool Mastodon is. Sure, it has technical problems, for example discoverability is harder. But so what? Preventing centralization of control is more important than more mundane things like "discoverability".
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.
People who says "discoverability on Mastodon is difficult" presumably also say "I don't want to have to decide who my friends are, I want a corporation to choose my friends for me"...?
My friends are in real life, not on Mastodon or Bluesky.
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.
> 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.
In that case you're just using these platforms for free entertainment in exchange for being advertised to. That's ok, but that use case is already solved by facebook, instagram, and twitter, better than Mastodon.
Mastodon doesn't do enough to prevent centralization of control - when you make an account to use the network, you're making that account on some specific server. This ties your ability to communicate on the network under that identity both to the server operator, and to the domain name of the server. A fediverse server can go down because its maintainers deliberately shut it down or lose interest and stop maintaining it; a domain name can be lost or taken by a government (see the queer.af debacle). The administrators of a fediverse server can also decide to censor your posts or remove your account if they don't like what you post - and it's hard to argue that they don't have the right to do so because they're the ones running the server and storing your account as a row in their database.
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.
Regarding your first paragraph. Everything you said is true, but that's better than centralizated platforms like twitter and facebook. Yes or no?
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.
> Regarding your first paragraph. Everything you said is true, but that's better than centralizated platforms like twitter and facebook. Yes or no?
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.
Like any opposition party, the anti big tech crowd is actually a loose coalition of different goals and interests. I've noticed that as these platforms get through the earlier stages of "will it even work" the differences in values are becoming more pronounced and controversial. The primary two groups seem to be those who value federation and see centralized control and algorithms as the threat and those who value encryption and see surveillance as the threat. Obviously these two things aren't mutually exclusive and we all want to see new platforms that can solve for both. But there's a quite distinct difference in the primary priority and consequent technical decisions.
I hope maybe if we can be aware that this is a broad set of technologies being driven by a broad set of goals then we can be a bit more gracious when a project isn't perfectly aligning with our personal values and find the common ground and values.
Thanks for this comment, you've said exactly what I've been thinking.
I'm definitely in the sect of people who have "detach from big centralised tech, be self hostable & interoperable" as the main priority, with E2EE being a nice extra. So it's always interesting when I read articles from the other side who see privacy, maximal E2EE & zero metadata as their #1 priority. They entirely dismiss protocols as junk for reasons I would never think or care about. But these things do matter to them, and they are just as important as me.
It strikes me as a near impossible balancing act for a project like Matrix to please everyone. They are clearly trying.
I will also note that there's a volume difference in the messaging being sent out. The privacy/security people are often very loud & critical, with good reason from their perspective. For example this article. That makes the discourse seem more negative than the overall sentiment probably is.
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.
People here always want to run the software themselves first, but then the next day they want to pay someone else to host it. If you're running into people throwing security flags, the silver lining is you're also a stone's throw away from offering a hosted option.
"If you're particularly concerned about metadata footprint, you can run your own servers in whatever network environment you feel like"
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.
Well, that's why the first half of the post spells out the work that we're doing to improve the metadata footprint. The second half that you're quoting explains why we didn't solve this back in 2014.
I found your explanation sufficient: obviously, you are going to find people who find fault in anything, but thanks for the transparency and the effort put into explaining the prioritization and/or workarounds which justify it.
Frankly, I'm not sure why explaining it (or the explanation) makes the situation any better.
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.
As the other guy pointed out, you would 100% experience the same issues if Signal was a web app. You're deleting your encryption keys. They have to be stored somewhere. You want private keys on the public server?
I know nothing about any of this and I am surprised to learn that something that is apparently considered to be permanent is stored in something as ephemeral as a browser cookie, and then causes problems if deleted. At least this is how I understand the exchange above.
Any web application really has access only to "ephemeral" storage like cookies or localStorage when used in this manner (you could be cleaning your localStorage for every session too).
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.
Element web and PC applications are still, in 2025, a mess. I have heard you have to use it on Mobile using the ElementX.
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.
Yup, work has been going into refactoring Element Web into MVVM components so we can switch out the ancient matrix-js-sdk underpinnings with the same matrix-rust-sdk that is a day-and-night improvement. https://element.io/blog/element-x-web-a-glimpse-into-the-fut... gives an idea.
We've been happy Matrix users. Apart from less technical folks losing their encryption keys every now and then and certain other users having issues with flatpak permissions it's been an uneventful experience... until now. We're losing a domain due to contractual obligations and it seems the only way to migrate to a new one is to start over.
I have to say, this comes across as incoherently babbling by someone with an axe to grind. The things they say are bad about Lemmy/Matrix are in conflict with the other things they want.
The person who wrote this just wants a centralized, moderated chat/social media system. Use Discord/Slack/Reddit if you don't like the resiliency of decentralized systems. There are some legit gripes in this massive list, but 90% of this reads as "I want Matrix to be centralized!" Good news, that exists already!
I don't know enough to comment on the accuracy, but almost all of the page is about security holes in Matrix, and then how their preferred service, SimpleX, is both decentralized and doesn't have those holes.
XMPP just works and has matured substantially in the last 5years or so. You may or may not like it, but that's all I've been using/needing for a decade, and because of that, I ended up onboarding a bunch of tech-illiterate friends and family members along the way. It just works for them, too.
I "need"/want more, Cross Signing, completely autonomous servers, not contacting 3rd party servers as a client, easy access to e2ee msgs including fresh sessions, non-centralized rooms, e2ee video conferencing, to name to most important aspects.
The table comparisons here of Simplex vs Signal, XMPP & Matrix don't seem particularly interesting (like for like) beyond demonstrating the general differences between decentralised & federated systems.
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?
I got bitten too many times by Matrix to still have any will to use it again.
Lost messages, impossibility to backup or recover, search not working and weird unexplainable bugs...
To try to fix a cache issue I once tried to look at the source code, it was an undecipherable hot mess like if it was encrypted and the key was loss also ... :p
Why I chose not to use SimpleX after investigating it last year:
- No multi-device support. I want to send and receive messages using any of my devices, independently, no matter where they are. (Being able to tether a phone to a computer is not sufficient.)
- Messages are dropped if not retrieved a timely manner. 21 days by default, which is shorter than some of my vacations.
- It was not clear to me what happens to undelivered messages when a queue server crashes, loses power, or reboots for maintenance.
- Establishing a chat requires sharing a large link or QR code through some out-of-band channel, which I often find inconvenient.
- Funded almost entirely by venture capital. This suggests to me that it is likely to either vanish or turn to some form of exploiting users, eventually. I don't want to build my contacts network upon that foundation.
- It was not clear to me who controls the queue servers, what incentives exist for their operators, or how their maintenance is funded. Absent that information, I must assume that most or all of them are run by the same people, making it a hair's breadth from a centralized service.
- Frequently repeated marketing claims of having no user IDs, when its message queue IDs are user IDs. The privacy improvement vs. a traditional service is through generating a distinct ID for sharing with each contact in 1:1 chats. (Group chats do not have this feature.) While I consider this valuable (it's like automatically giving you a separate email alias for use with each contact), I despise that it was presented as something that it is not. Perhaps they have stopped making the original claim by now, but even if so, the fact that they lied to people in the first place makes me unlikely to entrust my communications to them.
I prefer Matrix. I'll comment separately regarding why.
> [federation] offers a degree of censorship resistance, as the messages or images are replicated across multiple servers, making it difficult for any single entity to censor or control the content.
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.
I'll preface by saying that I would prefer fully decentralized/p2p systems to take over, that's said...
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.
Trying to build a secure system on top of email is a waste of time and energy. Even if you succeeded, it would only be by compromising all the things that make email useful.
Several years ago I was looking for something to use as a family chat server. Many of my friends/coworkers were using Slack/etc., but since my immediate family members didn't already have a preferred chat app, I was hoping to self-host something open-source. Matrix was under very active development at the time and I was pretty excited about the prospect of using it. Matrix didn't even have E2EE yet (I think it was under development), and that really wasn't a feature I needed or cared about (disappointing to read about all the trade-offs involved in this post though). The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run. Highly recommend.
I don’t really have a dog in the fight so to say (aside from running a relatively large IRC network for the passed 22 years)…
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.
Now that i'm looking back at xmpp, i agree that i wish we would have doubled down on xmpp - either to make some things easier for hosting, etc. And, yeah, its funny that you mention about the hatred of xml...i never loved it, but never hated it. Same with json, etc....To me they're just data formats...but so much dislike seemed the cool thing to do back in the day. Ah, well.
It’s so easy to host, and I once implemented a partial in-browser client (using, basically, a web bridge that I also wrote on the other side) in no time, starting from not knowing a single thing about it aside from having used xmpp chat clients in the past. Like getting to the point of status online/offline indicators showing up and messages passing was so easy. I get that I was a far cry from supporting things like encryption extensions, but it’s a great sign when going from nothing to having at least some of a protocol working takes very little time.
The web platform’s still (for now) really good and fast at working with xml. Kinda wild we ended up with json everywhere.
My point was that "lack of investment" doesn't explain the standstill. If that would be the determining factor IRC should not have seen or should not be seeing any progress either. But we actually do have IRCv3 extensions and quite a few new implementations here and there.
There's something else hindering XMPP that it stands so still, alternatively it simply can't be improved.
> ...The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run...
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.
> my immediate family members didn't already have a preferred chat app
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?
I disagree that federation must die. Federation has problems, but it solves the most important point which is to avoid that one company controls everything. Whether you have identities, or servers associated or bla bla bla all of that is secondary to preventing centralization of power.
As someone who has witnessed a malicious Matrix admin, it has become glaringly obvious that operating on a platform that hinges on any sort of trust in a human who can oversee metadata (even those who you consider to be good friends) is not viable.
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.
It was everything... after reviewing my original statement and the reaction to it, I think a better message is "be careful who you promote to admin"; we will need a human to review what is going on, but it is the classic spiderman tale of "with great power comes great responsibility".
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 wondered from the beginning why matrix was adapted so quickly. It's cryptographic protocol is so flawed. Most of the leaks could be easily prevented.
There were no good alternatives at the time. They were competing largely with Telegram and Whatsapp so basically anything was seen as an improvement. Since then Signal has gained popularity and set a much more robust standard for implementation, instead of hollow feature count.
That doesn't make sense : Signal is slightly older (both 2014), and was end-to-end encrypted from the start, while Matrix only got it officially in 2020 ?
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 ?
Yeah, it was kind of a case of both. Signal was strictly an sms replacement, it used to overlay and replace the sms app on Android. Matrix was designed to work more like telegram where it was supposed to be more standalone and fully featured. Signal later started to add more telegram like features and people started to view it as an alternative.
Not open source, you can't verify the end-to-end encryption or any other measures the client uses actually happen. This makes it trivial to hide backdoors.
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.
I really wanted matrix to succeed, but I've completely and entirely given up on it now.
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.
I also wanted - and still want - matrix to succeed! But, i've also semi-given up. I still use it because there a small number of folks i still chat with; though that's dying off. I managed a synapse home server very early in matrix's life, for a few years, and yeah it was complex back then...and for me the security is fine. Sure, there are gaps and things to be address for security...but, overall the thing that grinds my gears are the heavy resources needed. I started returning to xmpp. Is xmpp "simpler" or "more secure"? I would reply: no. But, you know where xmpp is really great? Ridiculously low needs for resources for a server! I understand that in this day and age we have far more access to so much more computing power...But, why should we allow bloat just because we can? Sorry, nowadays if I'm just trying to provide for chat, I'm looking into xmpp. I have no experience with simplex, but i think i'll wait til it bakes a bit more (and also see the resources usage story in a year or so).
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!
At this point I just want them to die off completely so we could get something better. They have been unable to make real improvements that make using Matrix a nice experience. And their existence somehow inhibits other solutions from emerging in the OSS community chat space.
> And their existence somehow inhibits other solutions from emerging in the OSS community chat space.
How?
People new to the system think that Matrix can work. So FLOSS devs spend time trying to lipstick the pig. Takes time away from other areas.
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.
> People new to the system think that Matrix can work. So FLOSS devs spend time trying to lipstick the pig. Takes time away from other areas.
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?
They're typically operating in private or semi-private federations, and so aren't so worried about spam/abuse issues like the one in question here. They may also not care as much about serverside metadata footprint (or indeed they may actually require serverside metadata in order for the server admins to enforce who can talk to who).
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.
> 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.
Rocket Chat, Mattermost, Zulip
These don't offer the core UX of Discord, which is being able to jump between many communities from a single app/login.
No open thing can ever do that. By virtue of openness, there are many copies of open things whereas your requirement requires there to be just one.
I think you could get pretty close with OAuth2. You could also have the frontend be a centralized app, but allow people to host their own servers. If the entity controlling the frontend goes off the rails you still have a pretty simple exit strategy.
Do you know Cinny?
cinny.in
This is an astute comment, despite "Arathorn" CEO of Matrix LLC's downvote ring pushing down the score. (Hey bud you know you can just read without commenting, right? Sit and listen for awhile)
ActivityPub has the same problem. Browse a Japanese MissKey server and it'll start loading yours up with questionable drawings. I turned off my server FAST
This is a big, big problem for federated software that I have not seen addressed or even frequently discussed. Arbitrary file upload by the public is not something small operators can reasonably allow on their servers.
Even large operators of non federated systems with controlled access like Facebook struggle with this. It's impossible to protect yourself as a server operator on Matrix or ActivityPub from malicious actors that want to use your server to distribute illegal material, and you'll be the one found liable!
No thanks!
Hosting any publicly uploaded content is a bad decision and a problem since e-mail. IRC and MQTT with QoS 0 do not have this problem. They have others though. At least criminals won't use them because of how easy is to snoop.
half baked solutions often "crowd out" potential better solutions. If something works enough, someone is less likely to make one that works well. Especially when there's a network effect involved.
As someone who wants to care not at all about the implementation details: last week I tried to sign up and use Matrix. I just want it to die.
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.
> State resolution is just a total mess.
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.
>trading off for speed
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.
Because we didn't have enough people or cash to do a good job of simultaneously writing two servers, and as Synapse had gone into production across *.gouv.fr and other critical deployments, we instead frantically backported Dendrite's main novelties to Synapse - adding instead worker processes to Synapse so it could easily scale beyond the GIL: https://matrix.org/blog/2020/11/03/how-we-fixed-synapse-s-sc...
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.
Matrix team is doing a solid job of running - Keep it up and keep eating the Slack/Teams marketshare up with competitive features and pricing. Additional business considerations like HQ location costs, tax liabilities, and talent pool availability on paper also affect what you have to work with. London tax, talent, and labor pay versus Austin for example.
Also I got your name wrong last time - I apologize for that.
What’s the best way to fund development of this stuff? I’m aware of donating to the matrix.org foundation, but as far as I can tell none of that goes towards funding server and client implementations since those are Element instead of the foundation.
It sounds like you were stuck between a rock and a hard place there. Hope the Rust integration goes well.
> the likelihood is that rather than progressing Dendrite we'll instead look to add more Rust to Synapse
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?
Dendrite did subsequently switch to powering the P2P Matrix work… which also got paused in 2023. We’re currently resurrecting it, but it’s not clear whether Dendrite will be the clientside server impl.
> nowadays Element is actually on a more economically sustainable path
Good to hear. Keep up the good work.
Been loving your well-placed comments for 5 years.
Keep up the great work - your team should be giving you a raise; you’re a great reflection on them.
https://kashmirlife.net/14-messaging-apps-blocked-in-jk-3163...
You guys gave up on the national security threat and caved.
Dont want authorities knocking my door down for using an app
> 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.
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.
> A funding crunch since 2023 yet those features have been necessary for many years before 2023.
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.
> 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.
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 :)
> it could equally well just be calling the /messages API or any other point you need to know historical state.
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.
Perhaps just watch the video and see that the proposed solution is just doing a temporal state table - just as Slack and Discord etc must have in order to know what the state of a room was at some point in time.
Slack and discord don't know the state of the room at any given time in the past. Show me anywhere in slack or discord where you can see the membership of a room at 2024-06-19T15:23:45Z. Or anywhere where you can see the historical profile picture and nickname of everyone in the room at 2024-06-19T15:23:45Z. You can't, because they don't know.
I am pretty confident that slack and discord know who has permission to read a message at a given point in time, which is all that state groups are achieving here.
I am pretty confident they only know who has permission to read it right now.
No, they all need to know who had permission to read a message which was sent at a given point in the timeline. This is all state groups is: a track of the room state at the point a message was sent: e.g. who has permission to read it.
I repeat: I am pretty confident they only know who has permission to read it right now.
It works like this: their server gets a request to read messages, and checks if the client currently has permission to read messages. If so, it reads the messages. If not, it returns a permission error. If you don't have permission, it doesn't attempt to analyze history to figure out whether you had permission in the past.
In fact, Discord is pretty explicit about not letting you have any interaction with things you don't have permission to view. It doesn't even tell you you don't have permission. It just silently removes them from your menu, and if you try to access them with a link, it tells you "unknown error".
The room state is cached to not need to recompute the current room state from the beginning of time.
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
> 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.
Most people actually working on Matrix have been aware of state resets for quite a while. Hydra is just the name of the project which addresses them. There are 3 phases, of which the 1st covers the most serious ones; the 2nd and 3rd phases should drop next year.
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.
Custom emoji also stood out to me as “who cares”,
when compared with the other concerns throughout the thread.
Have you tried XMPP?
I used it for a year or so, with the default servers, worked just fine. We tried to get a group chat over from Signal to SimpleX but were unsuccessful in the end for unknown reasons. It just petered out and I didn't reinstall it on a new phone.
Maybe there was no migration?
I have a room going on multiple years now.
I still wonder why my experience and the experience of my friends, community and family with Matrix has been so positive compared to what people describe all of the time. Maybe it's because something changed in ~2025 when I started using it again? Both Beeper (my main Matrix provider, the one that preconfigures WhatsApp, Signal, SMS etc. bridges) and Element (the new mobile app and EMS for hosting). I onboarded something like two dozend non-technical people to it, and they are all happily using it every day, mostly to use the bridges that come with Beeper. Haven't heard a single complaint, even switching devices just works now. Almost all communities I care about (GNOME and so on) have Matrix servers, and since the spaces feature launched it's been really competitive with Discord, even UX-wise thanks to the new apps on desktop and mobile. Yet all I hear on HN and elsewhere is people complaining about UX issues that just have not appeared a single time for myself. Maybe it's people using non-compliant clients, old servers, or some other strange configuration? It's a mystery to me.
My best theory here is that because Matrix is actually quite close to being really good, folks get very upset about the remaining flaws, especially when the last few years have had to prioritise development for public sector deployments over being a Discord killer, in order to keep the lights on.
Yes, that is my impression also. Extensively using for a couple of years, and only occasional quirks now and then, e.g. a profile verification issue (seeing the annoying red shields to each comment), but easily fixed. Or a UX update that doesn't necessary feel improvement (this is an Element thing, really).
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.
> Update: Seeing who I respond to, taking opportunity to mention these recent UX musings
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.
> 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.
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.
However it's great to see the favs are coming back.
Given the people / rooms section split was my idea in the first place, i can try to make a case to have it as an option. (Interestingly I haven’t missed it much)
I think you're partially correct. People are upset at the time it takes to land even the most basic of fixes. Replies being bright red might be one of the most indicative examples. So while the work towards public sector deployments has probably helped with some aspects, the user-facing side has stagnated and people dislike that.
My experience has been in an enterprise environment but Matrix still falls way short of common enterprise messaging suites like Slask or even Teams. The effort has mostly been in managing channels.
The recent mandatory room version upgrade required a lot of real coordinated effort across our org.
Yup, this makes sense. I host a Matrix server, and it's equivalent in quality to Discord or anything else. Except that I've had a single unread badge on my account on iOS for at least a year now. It drives me nuts.
yup. https://github.com/element-hq/element-x-ios/issues/3151 is a real wart; we're finally at the point now where the push notification process can synchronise with the main process to get the badge count right. Sorry it's taken so long to fix.
Self hosting experience went well, but it was very confusing for people moving from Discord about a year ago. If it's still the same, there's literally no way to simply send a registration or channel invite link to someone, and have them onboard through your home server by default without the need to explain "Oh, you have to change this URL to that" etc.
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'm in the same boat. I manage my own server with tons of help from the ansible script(0) and it's generally been great for years.
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
Can also vouch for this ansible script. I just updated a very outdated homeserver, postgres, and switched from nginx to traefik, and it was extremely painless. I was dreading it, but it worked amazingly. I donated to the author yesterday because of how well it went.
For what it's worth, I have had zero issues with Matrix myself. Some friends and I use it to stay in touch and we have had a very smooth experience. I'm not trying to discount the issues people have had, but for me Matrix has Just Worked (TM).
Much of the OP is about Matrix's security. What is your experience with that?
It used to be much worse before Sliding Sync was in widespread use... often just logging in would be next to impossible for me depending on the exact client I used and how much old state there was to fast-forward to... many minutes would go by stuck at "logging in..." as it downloaded gigabytes of god-knows-what.
>Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users
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.
> "SimpleX has no identifiers" only means "SimpleX does not add additional identifiers"
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.
>These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers.
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
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.
>Tor does not achieve that either, as Tor relays are servers too.
This is ridiculous. You're effectively arguing, that because Tor isn't literally magical in being able to send TCP packets without IP addresses in headers, it's not significant improvement. As I showed you last time, the NSA itself has admitted they will NEVER be able to deanonymize all Tor users all the time, and that nor are they able to do that on-demand. Which is quite different from your "we run servers on two VPS companies ourselves, but pinky promise, they don't aggregate and correlate information."
>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 to your front page. Make sure it makes it extremely clear that "Unless you install and configure Tor, SimpleX client does not take actions to hide your IP-address from the server".
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.
Simplex is also going down the crypto drain, they're starting their own coin.
That is untrue.
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
"Buy Community Vouchers. Initially you would pay with a stablecoin (USDT/USDC). "
You're literally requiring people to buy specific cryptocurrencies to buy your community vouchers.
Hmm that's still very 'crypto'.
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.
What’s wrong with being “very ‘crypto’” when you use a real use case crypto can solve?
Feels like a use of a ledger technology where everyone is a stranger in a way that isn't a credit and debit system in a relational databse.
Didn't knew. Do you have a source on that? Can't see any mention of coins in their blog. Are you maybe referring to the crypto exchange with the same name that normally appears on top of google searches?
I would guess they are referring to https://simplex.chat/vouchers/
Not exactly making their own "coin", but definitely involved with cryptocurrency, and if I understand correctly, the vouchers themselves involve blockchain.
[dead]
I don't have opinions about Matrix (a more-secure version of Discord or IRC seems like a reasonable thing to want) but want to put a word in for reading the Nebuchadnezzar paper, which is kind of a master class in cryptanalyzing secure messaging protocols, and really drives the point home that the hard part of a group secure messaging system isn't encrypting messages (anybody can do that) but rather in securely managing group membership without trusting servers:
https://nebuchadnezzar-megolm.github.io/
Combining something like FOKS (https://foks.pub) to a messaging system would be pretty neat
I just read through the Matrix protocol documentation, coming to it from never having heard of Matrix before, and I have to say, it is hot garbage, reading like someone with no distributed systems background and hasn’t heard of lamport clocks or virtual synchrony vibe-coded a shonky mashup of IRC and XMPP and then tried to copy-paste Signal’s crypto in the middle. There are early warning signs in which it extensively reinvents endpoint name resolution, by the time you get to the twelfth attempt to build consensus over group state by sorting a DAG you may, like me, realise their entire project is a lost cause.
Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.
I think you're looking at the outcome of attempting to design a secure open federated system for 12 different major kinds of user, not so much a lack of understanding of distsys stuff. The real problem is federation.
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.
Well, you’re a little kinder than me, but I also agree entirely; and notwithstanding that it’s certainly a hard problem, I’d hoped/expected to find end-to-end behaviours at the heart of distributed consensus in a modern protocol, and instead it was “the servers are in charge” all over again, cue disappointed frown.
I think I'm being less kind and more pointed, in that I think security is too much to hope for from any federated group secure messenger.
Is that on theoretical or practical grounds? I would love to learn how you would approach the challenge (no snark). I feel lots of developers miss the needed background, pour in a lot of work and then be stuck with it. How can we avoid that?
Is there some settled science, some principles and patterns in distributed security? Like, you want A, now you can only have option 1 or 2. But if you want B too, this only leaves you with option 2, provided you satisfy D too. But the combo D+B rules out any E.
No, there's no science to it at all; it's just a collective action problem. You saw it in Matrix's effort to get all their clients encrypted by default (they were hamstrung by an installed base of popular clients that didn't work that way), and again in the response to Nebuchadnezzar.
That sounds like a social problem again. What foundational materials would you recommend to read though for anyone trying to build something secure and non-centralized? It is a pity that everyone spends a lot of effort in this area, only to learn they did it wrong and having to deal with unfortunate design decisions. That is, if they are honest about it.
You can build secure and noncentralized! What you can't do is build secure and federated, where everyone lives in a shared, broadly reachable namespace comprised of independently operated instances.
I simply wouldn't build a secure group message system to begin with. It's a treacherously hard problem and the very few people who have done it well accomplished that with major UX compromises that put them at long-term disadvantage against schlock like Telegram, and survived mostly due to force-of-nature word of mouth.
If you're going to try, and you want to be rigorous about it, I'd say you need to start by reading the whole history of cryptanalyses of secure messaging systems, even systems you don't care about. Read the papers carefully and work out the attacks for yourself. It's a little like math in that you're only going to figure it out by actually working the examples yourself.
Perhaps you put your finger on it before, in that given the current state-of-the-art, the range of needs is simply too diverse to be met by a single paradigm. Nevertheless I still retain that hope, being disappointed by one effort didn’t break my faith in progress.
I think it's hard to overestimate how much Matrix is doing this on hard mode, in circumstances where they can't iterate or clean things up as they go, because they deliberately set themselves up to have a heterogenous installed base almost from the jump. Seen in that light, what else could they end up with but a ball of mud? Since I think that's basically priced in, I think the right thing to do is try to read between the lines and home in on the "good parts" of the design, rather than reflexively rejecting the whole thing because there are "bad parts" they'll never be rid of.
That, or adopt a "nothing federated can be good" stance. I'm sympathetic to that!
Btw, if anyone wants to read the flipside to this, I just posted the annual Matrix holiday update: https://matrix.org/blog/2025/12/24/matrix-holiday-special/
Happy holidays, HN… :)
I've been on Matrix for 6 years or so. Some of that time was painful (especially when the largest public server was overloaded by a surge of new users in 2020). It's better now. I can't remember the last time I saw a decryption failure.
I still have gripes about it. Improvements to the spec and software have been slow lately, due to funding issues. But they are still arriving. The official desktop client remains buggy, bloated, and cluttered. But there are lighter alternatives that do what I need 99% of the time. Much of the meta-data is not yet end-to-end encrypted. But that's still planned, and since it's not as important in my day-to-day chats as it might be if I were whistleblowing, I'm willing to wait.
I continue to use Matrix because there is nothing else offering the combination of features that I most value in it. Notably:
- decentralized
- 1:1 and group chats
- offline message delivery
- multi-device support
- end-to-end message encryption with well-understood ciphers and protocols
- easy enough that I have brought in non-tech-savvy contacts with very little assistance
- cross-platform, on every major desktop and mobile OS
- not tied to google services or libraries
- open-source
- free (in both senses)
- self-hostable
- reasonably anonymous; no need for a real name, phone number, or (depending on homeserver) even an email address
- (in development) scalable audio/video chat that looks very promising
Harder to quantify, but also worth acknowledging: The project lead seems very level-headed, demonstrating good judgment and tremendous patience, and consistently makes himself and the inner workings of this difficult project accessible to the public. This gives me the sense that Matrix continues to develop with sound guidance. Thanks, Arathorn!
thanks for sticking with it and the vote of confidence. totally agreed that Element Web has issues (i'm currently having to run a custom fork to stop it OOMing thanks to https://github.com/element-hq/element-web/issues/27983#issue...); hopefully switching to matrix-rust-sdk will be a huge improvement; https://github.com/element-hq/aurora is already looking promising.
XMPP can do everything you listed at a fraction of the resources. It'll also need stub/turn, like everything else for video and voice, but it works.
Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use.
Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse.
(And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.)
I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
Also, STUN/TURN is not sufficient to handle scalable voice and video conferencing. It would take care of NAT traversal, but can't do anything about the bandwidth problem: Each participant would have to maintain a bidirectional A/V channel to each other participant. Many residential internet connections would struggle quickly, and mobile phone bandwidth even more quickly.
Adding a selective forwarding unit could solve the outbound bandwidth problem (each participant would then only need one outgoing A/V channel) but can't help with the incoming bandwidth problem (each participant would still need to receive the A/V stream of each other participant). It can't compete with the Matrix design as I understand it.
A sufficiently powerful multipoint control unit could solve the bandwidth problem in both directions. But as far as I know, MCUs capable of handling big conferences are not cheap.
In other words, I think pmlnr's XMPP endorsement underestimates what it takes to do scalable audio/video chat.
Moxie (Signal Founder) gave a talk about the issues with federation at CCC in 2020, he took a crazy amount of flak for it, a lot of it from the Matrix community. Lots of the issue highlighted are in this post.
https://youtu.be/DdM-XTRyC9c
Here’s his original blog post from 2016: https://signal.org/blog/the-ecosystem-is-moving/
I go back and re-read this pretty much every time a decentralized thing has problems. It rings true.
Just gave it a listen. A lot of what he asserts seems pretty obvious with many examples e.g. the ones he give about IP, DNS, email etc. Centralized movers will always have the advantage of coordination, so decentralized systems have to have a damn good raison d'etre that's immediately obvious (e.g. Tor) or else be eventually consigned to niche use in highly idealistic communities.
These discussions look related. Others?
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)
Yeah, but it boiled down to “we want to move fast and modify the client on our whim”.
Which, is fair, but if absolute control of the client is required then there’s no benefit to E2EE.
The message I got was more "decentralized services have major coordination issues that prevent them from adapting to changing needs".
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 Federation Must Die
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.
It sounds like you haven't read the article. They're advocating for fully decentralised protocols over federated ones.
Fair enough I haven't had a chance to read the whole thing through, just had to skim eg the Matrix criticism. But if it's completely decentralised, why are there servers that must be paid?
Anyway I'll read it tonight when I have more time.
It seems to be relay servers as far as I can tell.
Same. Also, see how cool Mastodon is. Sure, it has technical problems, for example discoverability is harder. But so what? Preventing centralization of control is more important than more mundane things like "discoverability".
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.
People who says "discoverability on Mastodon is difficult" presumably also say "I don't want to have to decide who my friends are, I want a corporation to choose my friends for me"...?
My friends are in real life, not on Mastodon or Bluesky.
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.
> 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.
In that case you're just using these platforms for free entertainment in exchange for being advertised to. That's ok, but that use case is already solved by facebook, instagram, and twitter, better than Mastodon.
Mastodon doesn't do enough to prevent centralization of control - when you make an account to use the network, you're making that account on some specific server. This ties your ability to communicate on the network under that identity both to the server operator, and to the domain name of the server. A fediverse server can go down because its maintainers deliberately shut it down or lose interest and stop maintaining it; a domain name can be lost or taken by a government (see the queer.af debacle). The administrators of a fediverse server can also decide to censor your posts or remove your account if they don't like what you post - and it's hard to argue that they don't have the right to do so because they're the ones running the server and storing your account as a row in their database.
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.
Regarding your first paragraph. Everything you said is true, but that's better than centralizated platforms like twitter and facebook. Yes or no?
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.
> Regarding your first paragraph. Everything you said is true, but that's better than centralizated platforms like twitter and facebook. Yes or no?
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.
Like any opposition party, the anti big tech crowd is actually a loose coalition of different goals and interests. I've noticed that as these platforms get through the earlier stages of "will it even work" the differences in values are becoming more pronounced and controversial. The primary two groups seem to be those who value federation and see centralized control and algorithms as the threat and those who value encryption and see surveillance as the threat. Obviously these two things aren't mutually exclusive and we all want to see new platforms that can solve for both. But there's a quite distinct difference in the primary priority and consequent technical decisions.
I hope maybe if we can be aware that this is a broad set of technologies being driven by a broad set of goals then we can be a bit more gracious when a project isn't perfectly aligning with our personal values and find the common ground and values.
Thanks for this comment, you've said exactly what I've been thinking.
I'm definitely in the sect of people who have "detach from big centralised tech, be self hostable & interoperable" as the main priority, with E2EE being a nice extra. So it's always interesting when I read articles from the other side who see privacy, maximal E2EE & zero metadata as their #1 priority. They entirely dismiss protocols as junk for reasons I would never think or care about. But these things do matter to them, and they are just as important as me.
It strikes me as a near impossible balancing act for a project like Matrix to please everyone. They are clearly trying.
I will also note that there's a volume difference in the messaging being sent out. The privacy/security people are often very loud & critical, with good reason from their perspective. For example this article. That makes the discourse seem more negative than the overall sentiment probably is.
/me sighs; Merry Christmas everyone.
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.
People here always want to run the software themselves first, but then the next day they want to pay someone else to host it. If you're running into people throwing security flags, the silver lining is you're also a stone's throw away from offering a hosted option.
"If you're particularly concerned about metadata footprint, you can run your own servers in whatever network environment you feel like"
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.
Well, that's why the first half of the post spells out the work that we're doing to improve the metadata footprint. The second half that you're quoting explains why we didn't solve this back in 2014.
I found your explanation sufficient: obviously, you are going to find people who find fault in anything, but thanks for the transparency and the effort put into explaining the prioritization and/or workarounds which justify it.
Frankly, I'm not sure why explaining it (or the explanation) makes the situation any better.
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.
yup, unsure why i bothered too.
I use the strict cookie policy on firefox, and set cookies to be deleted at shutdown. I just save credentials and login to platforms each time.
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.
As the other guy pointed out, you would 100% experience the same issues if Signal was a web app. You're deleting your encryption keys. They have to be stored somewhere. You want private keys on the public server?
Don’t blame the user - blame Matrix for designing the system like this.
> 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.
With other private keys stored somewhere. You're just kicking the can down the road.
Yes, deleting your encryption keys every time you close the end to end encrypted chat app is definitely a great idea
I know nothing about any of this and I am surprised to learn that something that is apparently considered to be permanent is stored in something as ephemeral as a browser cookie, and then causes problems if deleted. At least this is how I understand the exchange above.
Any web application really has access only to "ephemeral" storage like cookies or localStorage when used in this manner (you could be cleaning your localStorage for every session too).
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.
Element web and PC applications are still, in 2025, a mess. I have heard you have to use it on Mobile using the ElementX.
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.
Yup, work has been going into refactoring Element Web into MVVM components so we can switch out the ancient matrix-js-sdk underpinnings with the same matrix-rust-sdk that is a day-and-night improvement. https://element.io/blog/element-x-web-a-glimpse-into-the-fut... gives an idea.
We've been happy Matrix users. Apart from less technical folks losing their encryption keys every now and then and certain other users having issues with flatpak permissions it's been an uneventful experience... until now. We're losing a domain due to contractual obligations and it seems the only way to migrate to a new one is to start over.
ugh, sorry. https://github.com/matrix-org/matrix-spec-proposals/pull/424... should help significantly with this, and is due to happen in 2026 (it's required for Hydra Phase 2). But it's not there yet.
I have to say, this comes across as incoherently babbling by someone with an axe to grind. The things they say are bad about Lemmy/Matrix are in conflict with the other things they want.
The person who wrote this just wants a centralized, moderated chat/social media system. Use Discord/Slack/Reddit if you don't like the resiliency of decentralized systems. There are some legit gripes in this massive list, but 90% of this reads as "I want Matrix to be centralized!" Good news, that exists already!
I don't know enough to comment on the accuracy, but almost all of the page is about security holes in Matrix, and then how their preferred service, SimpleX, is both decentralized and doesn't have those holes.
> Why Federation Must Die
They've lost me right here.
agree - it needs better immune responses, healthier community in some real ways
Matrix should rightly die. Its a terrible protocol in so many aspects.
As a counter, Mastodon federation is pretty sweet.
I have yet to learn about a federated alternative which is better than Matrix or at least on the same level
XMPP just works and has matured substantially in the last 5years or so. You may or may not like it, but that's all I've been using/needing for a decade, and because of that, I ended up onboarding a bunch of tech-illiterate friends and family members along the way. It just works for them, too.
I "need"/want more, Cross Signing, completely autonomous servers, not contacting 3rd party servers as a client, easy access to e2ee msgs including fresh sessions, non-centralized rooms, e2ee video conferencing, to name to most important aspects.
it's too bad running a mastodon instance is also a nightmare
GoToSocial and snac2 are both much simpler. https://gotosocial.org/ https://comam.es/snac-doc/
pleroma has em all beat
Lol. Mastodon is terrible, be the tech as it may. At least there's content I care about on Matrix, although Discord is still king.
The table comparisons here of Simplex vs Signal, XMPP & Matrix don't seem particularly interesting (like for like) beyond demonstrating the general differences between decentralised & federated systems.
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?
I got bitten too many times by Matrix to still have any will to use it again.
Lost messages, impossibility to backup or recover, search not working and weird unexplainable bugs...
To try to fix a cache issue I once tried to look at the source code, it was an undecipherable hot mess like if it was encrypted and the key was loss also ... :p
Why I chose not to use SimpleX after investigating it last year:
- No multi-device support. I want to send and receive messages using any of my devices, independently, no matter where they are. (Being able to tether a phone to a computer is not sufficient.)
- Messages are dropped if not retrieved a timely manner. 21 days by default, which is shorter than some of my vacations.
- It was not clear to me what happens to undelivered messages when a queue server crashes, loses power, or reboots for maintenance.
- Establishing a chat requires sharing a large link or QR code through some out-of-band channel, which I often find inconvenient.
- Funded almost entirely by venture capital. This suggests to me that it is likely to either vanish or turn to some form of exploiting users, eventually. I don't want to build my contacts network upon that foundation.
- It was not clear to me who controls the queue servers, what incentives exist for their operators, or how their maintenance is funded. Absent that information, I must assume that most or all of them are run by the same people, making it a hair's breadth from a centralized service.
- Frequently repeated marketing claims of having no user IDs, when its message queue IDs are user IDs. The privacy improvement vs. a traditional service is through generating a distinct ID for sharing with each contact in 1:1 chats. (Group chats do not have this feature.) While I consider this valuable (it's like automatically giving you a separate email alias for use with each contact), I despise that it was presented as something that it is not. Perhaps they have stopped making the original claim by now, but even if so, the fact that they lied to people in the first place makes me unlikely to entrust my communications to them.
I prefer Matrix. I'll comment separately regarding why.
Discourse "loading" screen is the worst user experience. It's long, non-informative and meaningless.
When they added it (probably a decade ago now), it signalled that they completely gave up on providing a performant forum software.
> [federation] offers a degree of censorship resistance, as the messages or images are replicated across multiple servers, making it difficult for any single entity to censor or control the content.
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.
I'll preface by saying that I would prefer fully decentralized/p2p systems to take over, that's said...
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.
Email itself is federated. Sort of the original federated messaging.
And the worst available secure messaging system.
And it's the best widely available, accessible, battle hardened, omnipresent messasing system.
I disagree and think rather that people have a parasocial relationship with it, like they do with IRC.
Incorrect - that would be WhatsApp.
What do you think of a system like Delta Chat built on top?
Trying to build a secure system on top of email is a waste of time and energy. Even if you succeeded, it would only be by compromising all the things that make email useful.
It cannot be the worst when it's not one.
Several years ago I was looking for something to use as a family chat server. Many of my friends/coworkers were using Slack/etc., but since my immediate family members didn't already have a preferred chat app, I was hoping to self-host something open-source. Matrix was under very active development at the time and I was pretty excited about the prospect of using it. Matrix didn't even have E2EE yet (I think it was under development), and that really wasn't a feature I needed or cared about (disappointing to read about all the trade-offs involved in this post though). The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run. Highly recommend.
I don’t really have a dog in the fight so to say (aside from running a relatively large IRC network for the passed 22 years)…
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.
Now that i'm looking back at xmpp, i agree that i wish we would have doubled down on xmpp - either to make some things easier for hosting, etc. And, yeah, its funny that you mention about the hatred of xml...i never loved it, but never hated it. Same with json, etc....To me they're just data formats...but so much dislike seemed the cool thing to do back in the day. Ah, well.
It’s so easy to host, and I once implemented a partial in-browser client (using, basically, a web bridge that I also wrote on the other side) in no time, starting from not knowing a single thing about it aside from having used xmpp chat clients in the past. Like getting to the point of status online/offline indicators showing up and messages passing was so easy. I get that I was a far cry from supporting things like encryption extensions, but it’s a great sign when going from nothing to having at least some of a protocol working takes very little time.
The web platform’s still (for now) really good and fast at working with xml. Kinda wild we ended up with json everywhere.
You say that but has XMPP really improved over the past 10-20 years? The same issues plague it still.
because all the investment (and, crucially: time) has gone elsewhere.
I thought I was clear about that?
SMF also has not moved in 15 years.
My point was that "lack of investment" doesn't explain the standstill. If that would be the determining factor IRC should not have seen or should not be seeing any progress either. But we actually do have IRCv3 extensions and quite a few new implementations here and there.
There's something else hindering XMPP that it stands so still, alternatively it simply can't be improved.
People are pathological about IRC (I am one of them), and there’s a small but motivated handful of us.
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.
would XMPP 2.0 still be compatible with XMPP?
Sure, just standardise a set of XEP’s and ensure federation has some strictness in which XEP’s are used.
> ...The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run...
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.
> my immediate family members didn't already have a preferred chat app
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?
Not alone. We started with Matrix, but we are very happy with Zulip now.
That’s a pretty lengthy list.
The illegal content one is I think the most problematic. Meta and friends don’t employ teams of psychological scarred content moderators for giggles…
So why not centralize THAT? Build federated (or hell, p2p) protocols and pay some company that has editor access JUST to do moderation.
There are tons of systems where it's decentralized up until the point where centralization makes sense. It doesn't have to be all or nothing.
this is what we effectively did with https://matrix.org/blog/2025/04/introducing-policy-servers (on a per-room basis). the OP is from 2024, and so predates this.
I disagree that federation must die. Federation has problems, but it solves the most important point which is to avoid that one company controls everything. Whether you have identities, or servers associated or bla bla bla all of that is secondary to preventing centralization of power.
As someone who has witnessed a malicious Matrix admin, it has become glaringly obvious that operating on a platform that hinges on any sort of trust in a human who can oversee metadata (even those who you consider to be good friends) is not viable.
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.
care to elaborate was it encryption they targeted as well?
It was everything... after reviewing my original statement and the reaction to it, I think a better message is "be careful who you promote to admin"; we will need a human to review what is going on, but it is the classic spiderman tale of "with great power comes great responsibility".
Death by a thousand features. A cryptographically secure simple listserv is _well_ within reach
It's all soylent green in the end; people.
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
This post is madness, but apposite madness. All systems are ultimately their creators; with everything they believe encoded in some way.
The VC on the mound doth shout "Who will make thy line go up!"
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!
Stawp! No more slop please. Papalcy isn't even a word.
I wondered from the beginning why matrix was adapted so quickly. It's cryptographic protocol is so flawed. Most of the leaks could be easily prevented.
There were no good alternatives at the time. They were competing largely with Telegram and Whatsapp so basically anything was seen as an improvement. Since then Signal has gained popularity and set a much more robust standard for implementation, instead of hollow feature count.
That doesn't make sense : Signal is slightly older (both 2014), and was end-to-end encrypted from the start, while Matrix only got it officially in 2020 ?
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 ?
Yeah, it was kind of a case of both. Signal was strictly an sms replacement, it used to overlay and replace the sms app on Android. Matrix was designed to work more like telegram where it was supposed to be more standalone and fully featured. Signal later started to add more telegram like features and people started to view it as an alternative.
why do you put Matrix as PC-first?
Use keet, true p2p & secure chat. No servers.
https://keet.io/
Not open source, you can't verify the end-to-end encryption or any other measures the client uses actually happen. This makes it trivial to hide backdoors.
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.
It’s all npm on the inside, if I understand correctly.
It doesn't appear to be open source, so users have no control or lasting guarantees of privacy.