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

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/ 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_retention_policies.html 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/ 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-21%2014_30%20Kegan%20Dougal%20-%20Unable%20to%20decrypt%20this%20message.pdf https://2024.matrix.org/documents/talk_slides/LAB4%202024-09... or the recording at https://www.youtube.com/watch?v=FHzh2Y7BABQ 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/ 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-unauthenticated-media/ 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-unauthenticated-media/ 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.