6 ms·

Matrix works fine for the friend to friend, small community things. Discourse forums too. Use Signal for family and friends, perhaps work. Fediverse and Atmosph

by rapnie 23d ago

Matrix works fine for the friend to friend, small community things. Discourse forums too. Use Signal for family and friends, perhaps work. Fediverse and Atmosphere (Bluesky) for your microblog needs, and RSS to keep track of blogs.

writtenone 23d ago
Having used Matrix for almost a decade, it's hot garbage. Sync is barely working, "unable to decrypt" still exists, the encryption is flawed [0] and the whole thing is effectively just Element and everyone else follows their lead. [0]: https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/ https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...
- the__alchemist 23d ago
  Element in particular is embarrassingly bad. (Consistently, for the past 5 years, through the present)
- bilkow 23d ago
  About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs) and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years). Can't speak about the other issues, I haven't had those but I barely use it. Based on comments, it's clear they exist or have existed for quite some time. [1] https://blog.erinshepherd.net/2026/02/non-contributory-keys-in-the-matrix/ https://blog.erinshepherd.net/2026/02/non-contributory-keys-... [2] https://matrix.org/blog/2026/02/analysis-of-reported-issues-in-vodozemac/ https://matrix.org/blog/2026/02/analysis-of-reported-issues-...
  - some_furry 22d ago
    > About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs) I've edited the above linked post several times to make this clearer, but people still keep linking Matrix's flawed response as if it actually addressed the issue. It does not. The issue is not as simple as "did the check exist? [y/n]". There are actually two issues: 1. Did the check exist? [y/n] 2. Did the group key agreement protocol fall to shit if the check was omitted? [y/n] Matrix was (n, y) due to how Megolm manages keys in group contexts. Signal was (n, n) due to their protocol design. Matrix tried to defend point 1 when the blog post was about both 1 and 2. (Post-Quantum MLS, for comparison, would also have been impervious to this issue due to how KEMs work. Another point in favor of MLS adoption.) > and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years). Even if you assume the worst possible interpretation of this coincidence (which, sure, you're free to if you want-- you would be wrong if you did, of course): What does it even matter? Like, what is the notion of "good faith" that's even necessary for someone to do independent security research and publish criticism of the cryptography used by a software project that's being propped up by EU sovereignty movements? In my opinion, this is a stupid and vacuous framing. Signal omitting the check didn't harm Signal's confidentiality. Matrix omitting the check demonstrably did. --- Also, if you're going to decry my blog post for not enumerating unrelated security bugs (n.b., the blog post was about Matrix, not Signal, so why would I talk about Signal's code in that post???), be aware that I reported non-cryptographic bugs to Element (Matrix client) and Conversations (XMPP client) around the same time. Only XMPP actually credited me with any fixes. https://gultsch.social/@daniel/116125064866469085 https://gultsch.social/@daniel/116125064866469085

by rapnie 23d ago

writtenone 23d ago

Having used Matrix for almost a decade, it's hot garbage. Sync is barely working, "unable to decrypt" still exists, the encryption is flawed [0] and the whole thing is effectively just Element and everyone else follows their lead. [0]: https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/ https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...

the__alchemist 23d ago
Element in particular is embarrassingly bad. (Consistently, for the past 5 years, through the present)
bilkow 23d ago
About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs) and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years). Can't speak about the other issues, I haven't had those but I barely use it. Based on comments, it's clear they exist or have existed for quite some time. [1] https://blog.erinshepherd.net/2026/02/non-contributory-keys-in-the-matrix/ https://blog.erinshepherd.net/2026/02/non-contributory-keys-... [2] https://matrix.org/blog/2026/02/analysis-of-reported-issues-in-vodozemac/ https://matrix.org/blog/2026/02/analysis-of-reported-issues-...
- some_furry 22d ago
  > About the post you linked, see [1] and [2], which makes me question both whether that is an actual vulnerability (Signal, the messenger recommended by the author, also didn't have that check, and it's addition is absent from release notes and CVEs) I've edited the above linked post several times to make this clearer, but people still keep linking Matrix's flawed response as if it actually addressed the issue. It does not. The issue is not as simple as "did the check exist? [y/n]". There are actually two issues: 1. Did the check exist? [y/n] 2. Did the group key agreement protocol fall to shit if the check was omitted? [y/n] Matrix was (n, y) due to how Megolm manages keys in group contexts. Signal was (n, n) due to their protocol design. Matrix tried to defend point 1 when the blog post was about both 1 and 2. (Post-Quantum MLS, for comparison, would also have been impervious to this issue due to how KEMs work. Another point in favor of MLS adoption.) > and whether the post was made in good faith (the check was added to libsignal on the same day that the author disclosed the vulnerability to Matrix, which can be a coincidence, but doesn't seem likely given that the code has been there for years). Even if you assume the worst possible interpretation of this coincidence (which, sure, you're free to if you want-- you would be wrong if you did, of course): What does it even matter? Like, what is the notion of "good faith" that's even necessary for someone to do independent security research and publish criticism of the cryptography used by a software project that's being propped up by EU sovereignty movements? In my opinion, this is a stupid and vacuous framing. Signal omitting the check didn't harm Signal's confidentiality. Matrix omitting the check demonstrably did. --- Also, if you're going to decry my blog post for not enumerating unrelated security bugs (n.b., the blog post was about Matrix, not Signal, so why would I talk about Signal's code in that post???), be aware that I reported non-cryptographic bugs to Element (Matrix client) and Conversations (XMPP client) around the same time. Only XMPP actually credited me with any fixes. https://gultsch.social/@daniel/116125064866469085 https://gultsch.social/@daniel/116125064866469085