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?
I read through this, joined their matrix server and talked.
Signal is decent enough to be used. (what I am using with my one friend lol)
it looks in this that simplex is good but I would argue its not when I actually looked into its protocol. Its group feature is actually experimental and you trust the original nodes and they can be malicious... and people could send messages behind your back too... So a no go.
Tor based are good too if you can manage to keep a device open but I have heard somewhere that tor can be tracked through bgp too but honestly tor might be the best option really :/
There are threat models. One has to find their threat model and work on it. There is not any "best alternative" in my honest opinion
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.
> 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...
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.
Well, because hardly any of my friends are on Matrix. Most of them tried it at some point, but it doesn't stick as the user experience just isn't there.
I use beeper which uses matrix under the hood so that I can talk to my friends who are using insta chats and since I don't want to use instagram just to chat with them.
It works really nicely, can recommend. The matrix protocol in that sense does work wonder.
There are new protocols like session, simplex (preferred?) but simplex has the issue that it is doing client side search for csam etc and I don't have a problem with csam search but then they will actually go into that group and shut that group, again I don't have an issue but their wordings have been extremely vague and it just seems like that anybody can report any server and they have the power to shut them down..., doesn't sound decentralized.
Again I am sure that csam is used as shield for privacy and yes I also would want to eradicate csam completely from the face of the earth but maybe in the process we would end up completely 1984.
I read into simplex protocol and the groups are honestly glue code tbh, you trust the nodes to give you safe info but in effect they can be malicious too. Simplex says that it is for 1-1 conversations but at that point, using something like tor based communication for live messaging is better.
The only use case of simplex I can find is 1-1 chats when the other person isn't online. But I guess I don't trust that either and at that point I would much rather use something like proton docs or proton drive as the storage layer...
Deltachat which is based on email looks really nice too.
There is this secuchat created by bkilm on gitlab which is worth a read actually. I am not finding this at the moment but I remember actually going through all of them and going on their matrix [1]
Both signal,matrix and maybe even simplex are good tbh.
My “why not Matrix” is that it’s hard to build a good client for it and hence there are incredibly few (on some days I’d argue none).
To the project’s credit: A lot of work has gone into supporting better UX (QR code sign in, sliding sync) and the Rust library is also apparently pretty good.
Yet, somehow, there still hasn’t been an explosion of clients. IMO it’s because the protocol carries too much cruft and the standardization process (including vendoring) makes it hard to use new features when not using the official libraries, which are a) under-documented and b) only available from Rust, Swift and Android.
Yeah, agree. If you look at their list of SDKs things look great, but in my experience once you actually look into them, you find many are missing important features. The protocol is still getting changes that are, if not exactly backwards-incompatible, definitely backwards-inconvenient. There's also a catch-22 in that, due to this problem, usage is heavily skewed towards Element, which means that Element's behavior becomes a de facto spec.
11 comments
[ 3.0 ms ] story [ 42.5 ms ] threadI have never heard anyone mention this, ever.
I read through this, joined their matrix server and talked.
Signal is decent enough to be used. (what I am using with my one friend lol)
it looks in this that simplex is good but I would argue its not when I actually looked into its protocol. Its group feature is actually experimental and you trust the original nodes and they can be malicious... and people could send messages behind your back too... So a no go.
Tor based are good too if you can manage to keep a device open but I have heard somewhere that tor can be tracked through bgp too but honestly tor might be the best option really :/
There are threat models. One has to find their threat model and work on it. There is not any "best alternative" in my honest opinion
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...
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.
It works really nicely, can recommend. The matrix protocol in that sense does work wonder.
There are new protocols like session, simplex (preferred?) but simplex has the issue that it is doing client side search for csam etc and I don't have a problem with csam search but then they will actually go into that group and shut that group, again I don't have an issue but their wordings have been extremely vague and it just seems like that anybody can report any server and they have the power to shut them down..., doesn't sound decentralized.
Again I am sure that csam is used as shield for privacy and yes I also would want to eradicate csam completely from the face of the earth but maybe in the process we would end up completely 1984.
I read into simplex protocol and the groups are honestly glue code tbh, you trust the nodes to give you safe info but in effect they can be malicious too. Simplex says that it is for 1-1 conversations but at that point, using something like tor based communication for live messaging is better.
The only use case of simplex I can find is 1-1 chats when the other person isn't online. But I guess I don't trust that either and at that point I would much rather use something like proton docs or proton drive as the storage layer...
Deltachat which is based on email looks really nice too.
There is this secuchat created by bkilm on gitlab which is worth a read actually. I am not finding this at the moment but I remember actually going through all of them and going on their matrix [1]
Both signal,matrix and maybe even simplex are good tbh.
Edit: Found it! [1]: https://bkil.gitlab.io/secuchart/
To the project’s credit: A lot of work has gone into supporting better UX (QR code sign in, sliding sync) and the Rust library is also apparently pretty good.
Yet, somehow, there still hasn’t been an explosion of clients. IMO it’s because the protocol carries too much cruft and the standardization process (including vendoring) makes it hard to use new features when not using the official libraries, which are a) under-documented and b) only available from Rust, Swift and Android.