Matrix has issues with metadata, cryptography and numerous issues with stability. E2EE is default for DMs which is good, for big rooms with tens of thousands of people it is irrelevant anyways. We don't use E2EE on the public GrapheneOS rooms as it scales poorly.
We have some of the largest communities on all of Matrix and we have had to make new rooms numerous times due to stability issues and state resolution bugs. It can also be very slow on the network and so are the apps.
The multi-session adds a lot of complexity and cryptographers have told us Matrix have issues because of it.
See: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/
There were several earlier rounds of Matrix cryptography vulnerabilities before. See https://nebuchadnezzar-megolm.github.io for one. This has happened repeatedly and we weren't impressed with their response which downplayed it.
We still heavily use Matrix ourselves and have our own server but we're less interested in keeping up with this. It's hard to move away from a platform with multi-session and both good desktop/mobile clients when most of the options don't have that and none combine it with great encryption. We'd like to be able to recommend Element/Matrix but it has these above issues and it gives a lot of metadata to each server. In E2EE Matrix rooms, message content and attachments are encrypted, but the server knows the time, sender, etc.
Still a better choice than Telegram though. As a decentralised service you need to trust your homeserver but that is completely down to you. I am assuming they act in good faith with this post but it is possible not every homeserver will.
final [GrapheneOS] 📱👁️🗨️
npub1c9…7sqfm
2024-08-26 12:22:28
in reply to nevent1q…7vh7
Author Public Key
npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfmPublished at
2024-08-26 12:22:28Event JSON
{
"id": "0e8e4fb0e4873c9e24a2190e9db008169780f0ba25de1e27419e5fa2587bb655",
"pubkey": "c15a5a65986e7ab4134dee3ab85254da5c5d4b04e78b4f16c82837192d355185",
"created_at": 1724674948,
"kind": 1,
"tags": [
[
"e",
"c1cf25eb3f37a55c9c8c4331993dcaeb0237028af887ae69a85e6d9f87be58f6",
"",
"root"
],
[
"e",
"9a86ab2db6f1af6fd3aa3a9ff6e4ba3ec5360065dfbf886d6549c4d13c52a61f",
"",
"reply"
],
[
"p",
"c15a5a65986e7ab4134dee3ab85254da5c5d4b04e78b4f16c82837192d355185"
],
[
"p",
"0f30b9ba98c9c58ec17b0b5dafaac9bf0f9d3a8494fc3f1d288a6683c27b1e2e"
],
[
"r",
"https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/"
],
[
"r",
"https://nebuchadnezzar-megolm.github.io"
]
],
"content": "Matrix has issues with metadata, cryptography and numerous issues with stability. E2EE is default for DMs which is good, for big rooms with tens of thousands of people it is irrelevant anyways. We don't use E2EE on the public GrapheneOS rooms as it scales poorly.\n\nWe have some of the largest communities on all of Matrix and we have had to make new rooms numerous times due to stability issues and state resolution bugs. It can also be very slow on the network and so are the apps. \n\nThe multi-session adds a lot of complexity and cryptographers have told us Matrix have issues because of it.\n\nSee: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/\n\nThere were several earlier rounds of Matrix cryptography vulnerabilities before. See https://nebuchadnezzar-megolm.github.io for one. This has happened repeatedly and we weren't impressed with their response which downplayed it.\n\nWe still heavily use Matrix ourselves and have our own server but we're less interested in keeping up with this. It's hard to move away from a platform with multi-session and both good desktop/mobile clients when most of the options don't have that and none combine it with great encryption. We'd like to be able to recommend Element/Matrix but it has these above issues and it gives a lot of metadata to each server. In E2EE Matrix rooms, message content and attachments are encrypted, but the server knows the time, sender, etc.\n\nStill a better choice than Telegram though. As a decentralised service you need to trust your homeserver but that is completely down to you. I am assuming they act in good faith with this post but it is possible not every homeserver will.\n\n",
"sig": "eacdca5cf2b3f8781d3ba99b7d3fff186a5d6560635ab51217f8a4ef0811100e26f87bf7ffc989cfe0c0f7c12c59ddf13aa7be3e0ebb964af6bb1cdc74f20dfd"
}