Upcoming coordinated security fix for all Matrix server implementations
matrix.org
matrix.org
Why? The main chat server matrix.org has a child porn/CSAM 'problem'. Due to lack of moderation in many of those rooms, along with protocol problems, these sorts of CSAM spammers can do an hours long image campaign of stuff that's illegal to even have. Theres nothing quite like waking up to a post every 10 seconds of felonies in a cybersecurity or Linux chat, and the summary clean and get the hell out of those rooms.
Banning also doesn't work, due to distributed nature of rooms. You can be banned from matrix.org room but connect through a different server, and they can still spam users.
If you do want to be on Matrix, I would recommend a few changes.
1. Don't stay on matrix.org chatrooms. They are the worst hit and slow to resolve
2. Disable image preloading and downloading.
3. If you have private servers and rooms for friends, its the best.
I haven't encountered any of that kind of abuse in Matrix after it has been implemented. It partially nullifies the point of the room decentralization, though.
Some of the biggest public rooms like "Matrix HQ" are almost unusably slow, though, since they have tens of thousands zombie users.
Matrix performance feels now more or less adequate for all realistic use cases, as long as long-term idle users are pruned out every now and then from public rooms.
And that's the ONE thing giving Matrix bragging rights over any other chat protocol. Their whole crusade against XMPP in Matrix early days was based on this distinction and overstating the importance and relevance of it. So I guess we are left with an absurdly complex protocol and single-source implementation for… nothing then?
I've quit it entirely. They have a real victim complex and don't understand that people have legitimate complaints about them.
My issue with possession of CSAM is that its statutory without mens rea. That means if my client gets an image without my knowledge or approval, I'm still blamed for it. And blame is a bloody felony. Some jurisdictions call for absurd punishments of 10y prison per image.
There are a few rooms I'm in. They are heavily moderated and narrow discussion. One is an speech-to-text from OpenMHZ police scanner for my area. But I also discourage usage - I'm highly technical, and I fear average users would get in over their heads and have a very bad time.
Can you be more specific about this? I've met several of the devs and they seem open to bug reports, and the Tor blog is always being updated with notes about various fixes that have been implemented...
Previously, every Tor Browser was "windows".
The claim I've heard was that there were JavaScript attacks that could uncover what OS you were using. Patching those would be 'too hard'. So now TBB just gives up OS. Seems not very good to voluntarily give up bits of PII.
https://m.youtube.com/watch?v=3wlNemFwbwE is where I was made aware of this problem. I verified it on my infrastructure too.
Then again, I'd also assume Cloudflare just de facto hellbans all Tor exit node IPs, so...
Tor had a thin layer of user-agent spoofing: it would always claim to be Windows (I presume) in the User-Agent header. But the real user-agent (which is still spoofed, but platform-specifically) was easily accessible from Javascript without even fingerprinting, since they never spoofed the navigator.userAgent variable in the same way. It could also be detected from other fingerprints such as TLS.
They removed the header-only user-agent spoofing so that the User-Agent header now reports the same value as navigator.userAgent, which is one of three distinct values based on your OS type. The rationale is simple: having these different didn't work. It was a failure. It didn't hide any information. And it tripped fingerprint checks on some websites. So they stopped doing that.
Certain people are trying to make this into a huge uproar for some reason. As far as I'm concerned, it's a coordinated disinformation campaign to discourage the use of Tor. The developers probably get spammed about this particular change a lot, because of the disinformation campaign, which explains the hostile response.
Nor were there any developer statements about this change. From an outsider (user) perspective, this smells like a coverup or an insider threat ala XZ situation.
And for software that people sometimes rely on safeguarding their lives with, well, yeah, addressing these significant changes in the open is how you avoid due scrutiny. And I think scrutinizing the lack of communication is a rather damning problem, especially here.
Hell, I was told I was a some sort of bad person for being unhappy with room joins taking hours or even days.
After exhausting all other options, they have improved their software a lot (it's still not perfect, but definitely usable), but their poor attitude has soured their reputation, and made it really difficult to be enthusiastic about Matrix.
I think there is a some sort of catch-22 going on. Matrix Foundation can't fund the replacement of Synapse with a better-designed server, because hosting matrix.org consumes all the money. And it consumes so much money because it runs Synapse, which uses computing resources in a very inefficient manner.
And the Foundation might have a some sort of conflict-of-interest, since it is closely interwoven with the New Vector company, which business case is being able to make Synapse work despite its flaws.
[1] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
It didn't then, and now that the situation is dire for Dendrite (with no funding and no official effort being put into it), I have little hope things are going to improve.
And it is what great about the matrix.org vs other open source app such as Telegram/Signal/Wire.... The protocol was designed to be open. If you don't like the client, write one, if you don't like the server, write another. Just follow the API specification. Being it is REST it is much easier to decipher than IMAP/SMTP. And port 443 works every where! Even on proxied Internet!!
Although it is possible for two room operators to kick each other on different servers at the same moment, which probably does lead to state desync. They'd have to do it at the same moment. In Matrix, it tries to still sync things that happened 6 months ago...
Yeah I hate the name too.
Made a lil' tutorial as well: https://blog.webb.page/2025-04-25-enter-the-matrix.txt
Now if I could get Element X working that'd be awesome but I've settled for regular Element for now.
that, a thousand times. Combined with a severe lack of objectivity. If you can't see the flaws and can't be critical of your own product, what room/hope is there for improvement? Matrix is a never ending story of over-promises under-delivered, taking feedback in bad faith, and, yeah, playing the victim.
I'm amazed that Matrix did manage to capture so much attention for so long while at it. There were there at the right time but with the wrong tech/product/abstraction/competences, sucked all the air out of the "federated personal instant messaging that you can host yourself"-room, and I am still sour that they possibly contributed to the current sad sate of affairs and worst case of consolidation there has ever been in this space (there was a time when WhatsApp wasn't so ubiquitous, facebook messenger, skype, … sucked, GTalk had some amount of interop, and we had a shot at not having our instant messaging in walled gardens).
This should not be remotely controversial.
Obviously the Matrix team is very aware of the very real legitimate problem of the CSAM spammer, and all the very real legitimate complaints about it, and we have tackled it as transparently as we can, with very limited resources.
I am incredibly disappointed that someone I previously respected and considered a constructive member of the open source community reacted like this to a simple request to not feed the trolls.
I believe the team was prudent in being reserved about describing the issue (and the abuse it could entail) until after these changes rolled out in 2024[1], especially due to the unique challenges they required (including putting a freeze on unauthenticated media as part of the upgrade process).
[0]: https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...
[1]: https://2024.matrix.org/documents/talk_slides/LAB4%202024-09...
[2]: https://matrix.org/blog/2025/02/building-a-safer-matrix/
[3]: https://matrix.org/blog/2024/06/20/matrix-v1.11-release/
Only text.
Profit?
Proper SPAM and user/content management is an inevitable need for public chat. E.g. what makes HN chat readable and full of legal content is not comment length limit but all of the other more complex systems enabling efficient moderation.
Element for smart phone, please make it very easy to change custom server instead of the default "matrix.org" ( Schildi Chat did a good job in their UI) I would recommend matrix client over Element TBH.
However, what's making me want to quit is that for more than 3 months now, message notifications have been completely broken on Android (Element X and its forks), and there's no fix for it. I completely miss out on important things and now have to build the habit of opening Element X once or twice every 15 minutes, so that it loads the messages from the server, and shows what people have been messaging me lately.
I no longer get message notification details on my phone, instead a generic "you have new messages" pop-up. There are at least 6 issues on GitHub detailing the same issue, but there isn't a fix and it looks like this is not a priority for the development team right now, even though it makes Element X practically unusable.
* event cache, to speed up room load and provide offline support. this was a huge amount of “invisible” work.
* media browsing - swiping between images, using the event cache
* fixing voip integration
* loads of trust & safety features
* threads (now in labs)
* spaces (in active dev)
* search (in active dev)
I agree that it feels like dev has slowed since the initial sprint to launch, but there’s another wave of features landing in the coming months.
The fix I found that works for me (at least if you're using Unified Push like ntfy) is to go into ntfy and delete all the Element subscriptions in there. Force close and reopen Element, which will automatically remake them.
That fixes the issue, at least for a long time. About once a year I need to redo the ritual.
Hopefully this helps you.
CSAM spam filtering is a bit of a moat for larger companies able to manage the costs of moderating it.
I would like to see AI moderating of CSAM, perhaps an open weights model that is provided by a nation state. With confidential computing such models can be run on local hardware as a pre-filtering step without undermining anonymity.
I don't envy the people who would have to trauma their way through creating such dataset. Yet, it would be useful yes.
> With confidential computing such models can be run on local hardware as a pre-filtering step without undermining anonymity.
I'm not sure it'd make sense to run locally. Many clients aren't powerful enough to run it on the receiving end (+ every client would need to run it, instead of fewer entities), and for obvious reasons it doesn't make sense to run on the senders end.
I built a porn detection filtering algorithm back in the Random Forest days, it worked well except for the French and their overly flexible definition of 'art'. The 'hot-dog/not-hot-dog' from SV HBO is pretty accurate on what that was like. I've thought about what it would take to make a CSAM filter and if it could be trained entirely within a trusted enclave without external access to the underlying data and I do believe it is possible.
For my matrix rooms I really want a default karma = 100 to be seen by others in the room, people can adjust this higher or lower
Might be interesting to have an option for others to donate 20 karma to new people they know are cool or something.
I get it that that destroys the conversation for new people and new people are what many groups really want - but we could be transparent about it.
I have two spammers over the years that I spent many many hours blocking ip cidrs and such.. this was actually easier with the old RealChat program (simple right click by moderators) - not sure if that has gotten better in recent year or so.
A cool down for new users and making it so we stop multiple 'cool in / warn up' accounts from same subnet would be nice too.
However, TFA seems to be in general about an upgrade to fix the following: "“state resets”: scenarios where Matrix’s state resolution algorithm can give unexpected results".
If room states become more stable, that is great.
Thanks to the Matrix team for all their efforts. Much gratitude.
Are there any normal web viewers to show what's in the public chatrooms without needing to join matrix and use the app etc?
I wonder why such thing wasn't done 15...20 years ago. Now it seems to be too little too late, with Matrix more or less having been taken the place of IRC.
Or maybe we would have been anyway because adding more and more complex features to federated, open-protocol systems with many actors involved with different, maybe even competing interests is not easy at all.
But also if I think back at late '90s, IRC had almost the needed critical mass and non-tech users to become something more mainstream...
Personally I see that as a feature. Chat is ephemeral, discussions/texts that aren't should be saved elsewhere anyways, otherwise it gets lost with all the other ephemeral stuff.
That's true, if you're not connected, you don't receive messages.
> even after you reconnect?
That's not true, once you're connected, you start receiving messages again.
> For many that’s not very useful.
Yeah, I understand it isn't useful if your perspective is that you should be able to read what happened when you were away. But I guess my previous point is that people shouldn't have to do that, there should be another resource for catching up what happened when you were away, and instead it should be OK to return without having to read through all the messages.
- Use some software project, want to ask a question, see they have an "IRC channel" - Hopefully it's a hyperlink to an IRC web chat, or else they'll have to do a lot of research to find out what IRC is - Join the web chat link, see a room with a list of names - See no messages - Ask a question - Wait ten minutes, get no reply - Assume it's just dead and leave
The ability to see older messages would be a huge boon, and to see messages between connections as well. I've seen it happen that a user joins a channel, they leave because nobody talked to them, somebody answers their question after they leave, they rejoin, they ask the question again, then disconnect.
If that knowledge is actually valuable, it should be stored elsewhere, in a structured manner. But I get your point, it's better than not having any answer at all.
Bouncers are an option, but the need to use that sort of extra services will make non-technical users turn away.
It's got a simple protocol that's easy to implement.
There's no company who "owns" IRC, as there is with Matrix, and no "reference implementation". Extensions and enhancements are done by consensus of the people writing the clients and servers, there's no central agency that maintains extendion proposals like Python's PEP or Java's JEP. As a result, to be as interoperable as possible, most implementations stick to supporting the existing status quo. If you want to add something new to a client or a server, you run the risk of having that feature only work for a small fraction of users. If it's popular enough, other impementors may choose to make their clients and servers support it.
IRCv3 is an attempt to make collaboration a little more formal, but it's a slow process.
* alexey (red hat)
* clokep (simplisafe)
* tulir (beeper)
* travis (funded by fdn)
* uhoreg (element)
* richvdh (element)
* dbkr (element)
* andrew (element)
* erik (element)
and me
from memory andrew & uhoreg all joined the team before later applying for jobs at Element - the fact being that if you wanted to be paid to work on Matrix back then, Element was pretty much the only place to do so (being the company formed by the team who created Matrix). I’m not going to fire people from Element or kick them off the SCT and lose their braintrust though.
The lack of server-side history is a severely underrated feature, actually. Lack of history means you aren't legally obligated to moderate history (because there is no history) and you aren't legally obligated to have someone on-call to moderate the history. Spam has a lower impact because the spam is not saved.
IRC's severe flaw is not the lack of server-side history, or images or emoji reactions - it's the reliance on constant connection between the client and server. This makes a very bad experience on mobile devices. It works badly on the other side of the equation, too - the online/away/offline social protocol is designed for an era where you log into your computer at the start of the day and shut it down at the end. And in general, the social protocol is from the era where you messages targeted at you are few and mostly interesting, and you may also subscribe to a small number of small social groups or topic subscriptions - none of that is true in the modern social era.
If you want to solve at least the non-social part of that, you end up designing servers that buffer messages on behalf of clients, which is the same as server-side history and creates a legal obligation to moderate it. Bouncers don't have this problem because the bouncer is under the control of the end user, so they can do what they like with it. But bouncers have to run on devices with stable power and internet access.
And that's all well and good, did recognize that, but then isn't it a bit disingenuous to present it as some sort of "real" solution in a thread about a communications technology that aims to cover much more? It's like arguing that Prometheus is the be-all end-all of monitoring, even though the remaining concerns still remain, and are just shoved aside to be some adjacent solution's problem.
> Lack of history means you aren't legally obligated to moderate history (because there is no history)
Is that actually right? Feels pretty suspect to me, you have to hold onto the data at least a little bit to transmit it to all connected clients, being a client-server protocol. I don't think this passes by the courts, not any more than holding onto a few dozen or a few minutes of logs in a non-persistent fashion (i.e. in-memory only) would.
"As a rule, strong feelings about issues do not emerge from deep understanding."
It doesn't excuse failure to moderate the service at all, but if there is no chat history, you cannot be excepted to moderate it specifically. Basically, in any even remotely fair legal system, one cannot be excepted to delete something that doesn't exist in the first place.
For example, we have the "gigs" channel where gigs that are hiring are posted as threads, and people interested reply in that thread asking questions about the gig, putting their names in the hat, getting communicated with about client questions etc. A lot of the information is "duplicated" to our CRM and even our wiki in a little table, but at the end of the day the "chat room" is the hub.
Same for events (which are duplicated to wiki and calendar), announcements (wiki, monthly email newsletter), and long running threads in "general" planning FOSS projects or whatever that people that only check in a couple times a week will pick up again after a gap.