Why not Matrix (2023)
49 comments
·July 28, 2025cwillu
bigfatkitten
There are no absolutes in security.
It’s not a perfect control by means, but if your objective is to minimise the amount of sensitive material just laying around, it definitely helps (and makes your adversary’s life a bit harder.)
cwillu
And how does a protocol enforce that, even in principle?
supportengineer
>> at this point it seems like most of the tech community is familiar with matrix
I have never heard anyone mention this, ever.
esseph
Weird. It's been around for years. A lot of open source projects use it, among other things.
Sophira
Reddit uses it too as the backend for its Chat feature, which is also now used for private messages in general. It doesn't advertise this, though.
null
JamesCoyne
cool
throwaway328
https://matrix.org/blog/2021/07/21/germany-s-national-health...
tl;dr is that the French and German governments are really ahead of the curve then
Arathorn
Another day, another matrix hit piece on the front page of HN. Unsure whether it's really my job as matrix lead to respond, but hey, let's go again.
TL;DR: the only valid points here really are complaints about state resets (being addressed in https://matrix.org/blog/2025/07/security-predisclosure/) and canonical json edge cases (which are on the radar). We should probably also remove device_display_names entirely. Stuff about "you have to trust other people's servers when you ask them to delete data!" is not exactly earth-shattering, and the encryption & authenticated media issues mentioned got fixed in 2024.
Point by point:
> 1. the graph is append-only by design
Nope, Matrix rooms are designed to let server prune old data if they want - https://element-hq.github.io/synapse/latest/message_retentio... is how you configure Synapse for it, for instance. The DAG can also have gaps in it (see point 6 below).
> 2. if you do want to delete something, you can send a redaction event which asks other servers very nicely to delete the content of the event, but redactions are advisory
If you ask a server to delete data, you have to trust it actually deletes it. That goes for any protocol; it's nothing to do with Matrix.
> 3. however, servers that choose to ignore redactions, or fail to process them for some other reason, can leak supposedly-deleted data to other servers later on.
see above.
> 4. certain events, like membership changes, bans or pretty much any event that exercises some control over another user can't be deleted ever as they become woven into the "auth chain" of future events
This one's almost true. The fact that "events which exercise control over another use" (i.e. access control) can't be deleted should not be surprising, given access control that doesn't disappear from under you is generally considered a good thing. However, if you really do want to delete it, you could 'upgrade' the room by pointing it to a new room ID, and vape the previous one (although admittedly there's no 'vape room' API yet).
> 5. the only way to discard all of this spam complexity is to recreate the room.
...or upgrade it, which is increasingly a transparent operation (we've been doing a bunch of work on it in preparation for https://matrix.org/blog/2025/07/security-predisclosure/). Meanwhile, mitigating state spam is part of the scope of the ongoing security work mentioned there.
> 6. it's exceptionally hard to linearize history if you don’t know the entire history of the room partially.
Yup, this is a feature. We don't want servers to have to sync full room history; they're allowed to do it in chunks. The tradeoff is that ordering the chunks is a heuristic, although we're currently in the process of improving that.
> 7. it is also somewhat possible to insert messages into history by crafting events in the graph that refer to older ancestor events
Decentralisation means that servers are allowed to branch from old commits (in git parlance), much like git. This is desirable if you're handling delayed traffic from a network partition or outage; we're working on avoiding it in other scenarios.
> 8. another thing that is worth noting is that end-to-end encryption in matrix is completely optional.
Sometimes E2EE makes no sense (e.g. massive public rooms, or clients which don't implement E2EE). Any client that speaks E2EE makes it abundantly clear when a room is encrypted and when it isn't; much like https v. http in a browser.
> 9. the end-to-end encryption is also annoyingly fragile
Not any more; we fixed it over the course of 2024 - see https://2024.matrix.org/documents/talk_slides/LAB4%202024-09... or the recording at https://www.youtube.com/watch?v=FHzh2Y7BABQ. If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
> 10. sometimes these device list updates updates also leak information about your device
Clients send a default device name (e.g. "Element X on iPhone 12 Pro Max") to the server, to help the user tell their own sessions apart, and to give users on the same server some way of debugging encryption problems. Admittedly this is no longer needed (clients typically hide this data anyway), so the API should be cleaned up.
> 11. the spec doesn’t actually define what the canonical json form is strictly
This one is accurate; we need to tighten/replace canonical json, although in practice this only impacts events which deliberately exploit the ambiguities.
> 12. matrix homeservers written in different languages have json interoperability issues
See above.
> 13. [server] signing key expiry is completely arbitrary
Server signing keys are definitely a wart, and we're working on getting rid of them.
> 14. split-brained rooms are actually a common occurrence
Once https://matrix.org/blog/2025/07/security-predisclosure/ lands, things should be significantly improved.
> 15. state resets happen quite a bit more often when servers written in different languages interoperate
See above.
> 16. room admins and moderators have lost their powers over public rooms many times due to state resets
See above.
> 17. you can’t actually force a room to be shut down across the federation
Same as point 2 and 3, you can't force other people's servers to do anything on the Internet (unless we end up in some kind of DRM or remote attestation dystopia)
> 18. moderation relies entirely on the functioning of the event auth system
See above for upcoming state reset fixes.
> 19. media downloads are unauthenticated by default
Not since https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...
> 20. you can ask someone else’s homeserver to replicate media
Only if you're authenticated on it, as of https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...
> 21. media uploads are unverified by default
Yes, being an end-to-end encrypted comms system, the server can't scan your uploads given it can't decrypt them, by default. Clients can scan though if they want, although in practice few do.
> 22. you could become liable for hosting copies of illegal media
This is true of any federated system. If you run a mail server, and one of your users subscribes to a malicious mailing list, your mail server will fill up with bad content. Similarly if you run a usenet server. Or a git forge, and someone starts mirroring malicious content.
Arnavion
>> 9. the end-to-end encryption is also annoyingly fragile
>Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys.
This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed.
The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.
cyphar
Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never seen anyone opt-in to "don't send to untrusted devices" because even with device signing, it breaks usability in most group chats).
Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues.
Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.
cyphar
I mean, you describe this as a "hit piece" but then go on to agree with most of the points (perhaps disagreeing that it is a problem, but not disagreeing with the factual basis of the statement) or point to incredibly recent developments which you say resolve those issues.
Matrix has been in development since 2014 (which is around when I first started using it) so pointing to solutions only just implemented in 2024 or "still being addressed" in 2025 as proof that this is a "hit piece" seems disingenuous to me (especially since this blog post is from 2023, and thus was correct at the time of writing according to your own comment). I understand that you are protective of your project, but having read your comments over the past decade, it seems that you feel the need to reply somewhat dismissively to any criticism.
I don't want to rehash the entire E2EE history here, but that decade-long saga has always bothered me.
orthecreedence
> If you ask a server to delete data, you have to trust it actually deletes it. That goes for any protocol; it's nothing to do with Matrix.
I've see this "critique" come up with multiple different protocols, and it's almost infuriating.
How does the protocol ensure the server removes the data in question from backups? How does the protocol handle someone copying the data off the server onto another device before deletion? How does the protocol handle servers that don't properly implement the data deletion portion of the protocol? How does the protocol handle wiping the neural synapses associated with the memory of that piece of data for each person who ever interacted with it? Without solving these problems, it seems to me the "delete" feature is nothing more than a suggestion, and therefor the protocol itself is fundamentally broken!!
Like, how do you take back something horrible you said to a friend? You don't. You fucking live with your mistake. Don't send shit to other people if you don't want them to, you know, have that information.
cwillu
Accidents happen, but that's exactly why the delete-as-suggestion feature exists.
eddythompson80
Despite our frustration, you can’t deny that it’s among the top 10 requested features anywhere. Snapchat pretty much made its name on convincing people that they did it. Telegram and Signal have “Delete for me” and “Delete for everyone” options, etc.
One could argue that the right implementation is to not have a delete option at all. Having a delete option gives people the false idea that their data was deleted, but no one can guarantee you that. Pretty sure this makes people even more annoyed and outraged. Imagine the typical responses you will see on a HN post titled “Twitter now is refusing to let you delete your tweets” and Elon Musk saying something like your last sentence to people.
bigstrat2003
Hey, just want to say that I use and quite enjoy Matrix (I run a Synapse homeserver + Nheko on the desktop). Those who are dissatisfied are louder (as is normal), but they aren't by any means the only ones. Keep up the great work!
cyphar
Just be aware that Nheko has still uses the deprecated libolm (which has known security issues and is unmaintained) and the maintainers have said they are not interested in moving to the supported replacement library[1] for the past year. As a fellow Matrix user, I would be cautious about using E2EE with any third-party clients -- the history of issues for the past decade speaks for itself.
bigstrat2003
Thanks for the heads up. I'm not so much interested in E2EE, but I'll have to look into the security issues. I use Nheko because I can't stand how bloated Element is (thanks, Electron), and appreciate the lightweight client. But I do want to not open security holes in the process, of course.
ashton314
Aside: what is with the trend of omitting capitalization from blog posts? I get it when people are writing tweets/texts/whatever short-form media, but for a full blog post? I find it makes it harder to read. Am I alone in this?
gerdesj
OP uses bold text for emphasis like an ill-advised user of a marker pen and deploys a very bizarre collection of quotation marks. Sometimes "..." and sometimes “...”.
If you are going to studiously ignore convention, please do it consistently weirdly.
The list of issues is not a list.
Oh well. In the end the message is the thing and not the medium. Ideally the medium might be a bit more conventional to enable readers to follow the argument and not have to mentally adjust the text.
ashton314
> In the end the message is the thing and not the medium
Ah, but to quote the philosopher Marshal McLuhan, the medium is the message. What does a tweet say? “This is a bite-sized idea that’s easy to understand.” What does a poorly-punctuated blog post say? “These ideas are sloppy.” What does a book say? “This is a more serious argument than you find online.” (alternatively, “I am looking for profit.”) What does a HN comment say? “This is my hot-take trying to sound smart.”
shawkinaw
Yeah, I tried to read the post and was immediately put off by the lack of capitalization. Then I came to the comments and had to fight the urge to ask “why not capitals”
tptacek
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
abnercoimbre
An entire article that omits capitalizing anything at all is likely noteworthy.
GlacierFox
I found the lack of capitals in the whole article interestingly annoying actually.
pezezin
Sorry, but I disagree. When the blog post omits the most basic spelling rules of the language it is written in, it is worth complaining, lest we end up normalising such behaviour.
NaOH
>...it is worth complaining, lest we end up normalising such behaviour.
Discussions about spelling, grammar, and punctuation on other sites transgress the HN goal to normalize thoughtful, curiosity-driven discussion here.
kop316
Since you didn't seem to get an actual answer, here is a discussion on this: https://news.ycombinator.com/item?id=43114156 . I can't find another discussion, but some folks seem to think a lack of capitalization also makes the post more informal.
I personally agree that it makes it much harder to read.
eddythompson80
why use many words when few do trick
gerdesj
"few do trick".
Are you implying, with that statement, that few words might trick a reader into a different interpretation from the one they might reach otherwise or that few words are enough (do the trick)?
I'm all in favour of parsimony but please deploy the bare useful minimum with an eye to clarity and not obfuscation. Also note that a full stop (period) is an indicator that you have finished dribbling.
eddythompson80
Just joke. No imply.
frollogaston
This is my first time seeing that, not fond of it
teekert
I didn’t even notice it but went back and it is indeed very weird. I wonder what the reason is.
timbit42
It's like how e. e. cummings wrote his name.
hammyhavoc
Make the LLM bulletpoint output seem more human that it is?
null
Points 2 and 3 seem to be a denial of reality: you never can delete something except by asking everyone else very nicely, and it's always possible that someone will repost something that they had that you didn't think they did.
Likewise point 8: there's nothing a protocol that isn't just a walled garden for a set of Trusted™ proprietary client binaries can do to prevent a client from doing whatever it likes with the decrypted information.