Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Upcoming coordinated security fix for all Matrix server implementations (matrix.org)
141 points by notpushkin 5 hours ago | hide | past | favorite | 58 comments





Just a heads up, that I mostly quit using Matrix except for a few topic-specific and heavily moderated servers.

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.


Any when you complain about it, Matrix accuses you of acting in the interests of the attackers.

I've quit it entirely. They have a real victim complex and don't understand that people have legitimate complaints about them.


I've never engaged the project admins. But if they're like Tor and their responses to deanonymizing OS reporting (basically hostile and attacking), it wouldn't surprise me.

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.


>...if they're like Tor and their responses to deanonymizing OS reporting (basically hostile and attacking), it wouldn't surprise me.

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...


Tor silently, last October, quit spoofing OS and now reports over browser headers what OS you are.

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.


Without knowing anything about Tor, I'd guess you've got it backwards. I imagine Tor leaks your OS through TCP/IP fingerprinting, and whether that fingerprint matches your `navigator.platform` is probably a factor into whether e.g. Cloudflare hellbans you.

Then again, I'd also assume Cloudflare just de facto hellbans all Tor exit node IPs, so...


They definitely have a victim complex. Few years back, when I complained of the then-insanely poor performance and scalability of the Synapse server, they told me to spend a few thousands of bucks on a high-performance personal server, and to educate myself to set up and maintain a Synapse instance, which was then and is still much harder to do than running most other server software.

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.


The Conduit server is very lightweight. I run a private server on a 128MB VPS!

I have heard so, too. Maybe I'll give it or some of its derivatives a try some time.

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.


There's an official Golang rewrite called dendrite: https://github.com/element-hq/dendrite it has few start because they recentyl migrated it from the original repo (https://github.com/matrix-org/dendrite) Development is not fast but it's going on, and it's currently on beta. I haven't tried it, I selfhost a synapse server which I used with friends, and with docker it wasn't hard to set up/maintain after the initial effort.


Only the Apache-licensed version is dead. The commercial arm (Element) forked it and relicensed it under the AGPL to make sure nobody but them can use their post-fork changes commercially. (Element demands you sign a CLA to contribute. Don’t[1].)

[1] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html


Thank you for bring this (conduit) up!!! Nothing beats a binary and toml/json/yml file deployment!!!

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!!


> a real victim complex

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).


I've been using it for over 2 years now and I agree there's a spam problem on public chatrooms.

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.


You might want to look into Unified Push. Although you need to use a Unified Push server that supports the differing Matrix endpoints because for some reason the Matrix devs decided to do their own thing. I wouldn't call using Unfied push with Matrix reliable, just like nothing with Matrix is ever truly reliable, but it works much better than native notifications for me.

In my experience, Element X was released long before it was ready, and I still think it's far from ready. I've been using Element on android and it's been wonderful. Can't speak for iOS.

They recently adopted this thing, though: https://matrix.org/blog/2025/04/introducing-policy-servers/

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.


> It partially nullifies the point of the room decentralization, though.

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?


One of the reasons we cant have nice things.

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 would like to see AI moderating of CSAM, perhaps an open weights model that is provided by a nation state.

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 guess I meant locally to the server not the client (edge). But also perhaps a very light model could be run on the edge.

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.


You can configure synapse to not cache remote images. Yes, these spammers are obnoxious but most homeservers should be safe if the moderation is prompt.

There is a blog post that captures this feelings very well in my opinion: Not being federated and E2E as an advantage https://blog.koehntopp.info/2025/06/17/no-federation-no-e2e....

Aren't matrix user IDs global? Wouldn't it be possible to ban messages from a given user regardless of server?

Wouldn't registering a new user in a different instance give you a new ID?

I am curious if there are any anyways that you would suggest this issue best be handled outside of putting the onus on user, as per your bullet points

I have a private server (running Dendrite) but it doesn't even work well for that purpose -- so many bugs, many preventing me from reading messages due to encryption state fuckups.

To be fair on matrix.org they recommend that you host your own server. Main selling point of matrix.org is there is NO centralized server!!! That is whole point of using matrix instead of Telegram, Signal, Wire.

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.


Make server with images banned.

Only text.

Profit?


Possessing the BASE64-encoding of such an image is still a felony. Text only doesn't solve the problem.

Also ban anything that looks Base/binary-to-text encoded.

Matrix messages/events are limited to 64kB if you disallow attachments

Is the CSAM spam a way to harass the admins/users or some kind of trading via broadcast in public forums?

Some of it was the latter. Matrix servers could be used in the past to store and serve unauthenticated media to anyone[0], which was described by the team as "not great"[1] and "abuse of Matrix as a content distribution network" [2].

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/


Former, I think. It involved highlighting all users of the room, and sometimes verbal abuse against Matrix and/or the projects which the rooms in question belogned to. Now that sort of abuse is much harder, since they have improved spam filtering.

Also not unheard of less ethical competitors to engage in such campaigns.

I feel like what's missing is not decentralization, but an open source offering to have large servers with e2e encryption. The cost of running a server doesn't have to be high.

As other commentary here says, there is a real and alarming problem with spam in public rooms on the public server. On the other hand, a private server with just people who trust each other is fairly phenomenal.

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.


I guess many of us are like me - have only a fuzzy idea of what Matrix is and what its like.

Are there any normal web viewers to show what's in the public chatrooms without needing to join matrix and use the app etc?


IRC is and was the answer.

IRC doesn't have chat history and a bunch of other features.

Our small group uses The Lounge web client for IRC which is a very good PWA, acts as a bouncer, has history search (not unlimited, but pretty long), supports image upload, and basically builds a modern group chat on top of IRC as a backend. We have a few folks who still use traditional IRC clients, but almost everyone just uses the web app. It's not a bad middle ground.

IRCv3 has "chathistory" extension. It basically involves combining an IRC network and a bouncer. There are at least two server implementations using it: ergo, which is more or less production ready, but does not have support for multi-server networks, and Libera's sable, which is under (very slow) development.

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.


I guess that because of the "we don't need that here" attitude that ran a lot through the first generation(s) of Internet population. And it's a shame because with a more dynamic IRC development we wouldn't be in the Slack/Discord silos situation.

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...


> IRC doesn't have chat history

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 what I thought until I learned that history really seems to refer to persistence. So if you’re not connected, you won’t get messages, even after you reconnect? For many that’s not very useful.

> So if you’re not connected, you won’t get messages

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.


I can see that in a lot of use cases, yeah. And yes I meant receiving old messages once you reconnect.

Never used it, what's so great about IRC? All I know is that's it's self hosted chat with no history retention, which doesn't sound like a solution to anything fancy in particular. The latter bit strikes me as an anti-feature even, if anything.

There isn't much. It's an old protocol, and very simple. But it's simple to the point of naivete and networks only really function with a bunch of ad-hoc extensions on top of it, but there's very little standardisation of those, and that's basically to get things like the concept of having a persistent identity that can't just be hijacked by anyone else on the server, let alone something like persistent message history, media sharing, or end-to-end encryption.

> what's so great about IRC?

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.


Chat history is a place were knowledge dies. That said my bouncer keeps the history for me.

While long-term chat histories aren't maybe that useful, the problem with IRC is that if your connection dies, you miss all the messages until the connection resumes. That is a big deal on mobile.

Bouncers are an option, but the need to use that sort of extra services will make non-technical users turn away.


Why? With chat history present, reasonable people can search for previously answered questions. Without it, if somebody joins afresh, even if their question was answered just before them, they could have no idea.

IMO it's partly because it's an inefficient platform for storing knowledge, its purpose is instant communication.

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.


Depends on what the question is.

We ran our co-op on matrix for a while. We switched to discord because onboarding to matrix and making people use this "weird app" was a burden. I would have loved to use IRC, or xmpp, but the way we use these "chat apps" is as the cornerstone of our entire organization, and I couldn't find a good way to get IRC or xmpp to work that way.

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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: