[jeroenhd]

If you're looking to protect yourself from metadata analysis, Matrix is not the protocol for you.

Matrix and XMPP are excellent protocols for decentralisation, but their E2EE implementation leaves all kinds of metadata exposed outside of the E2EE envelope.

You need to trust the server to not expose any of this information to anyone else (which is difficult to do when the police comes in with a warrant). If you use your own Matrix server(s) this isn't a direct problem, but then the communication links between you and the people you talk to would stand out immediately, so protection fails in other ways.

I'm not saying you should drop Matrix or anything, its decentralized nature and clear finances do have some trust advantages over Signal's occasional behaviour, but on a protocol level, an ultra paranoid person would probably be better off using (an audited client for) Signal.

[udev4096]

What metadata exactly? Matrix only publishes the absolute required metadata for functioning of federation. Unless you can pin point exactly what metadata and how harmful that is, stop throwing that word around. Whoever is pushing this narrative of "metadata leak" in matrix needs to come up with actual facts

[Arathorn]

Speaking as project lead for Matrix, the protocol does currently expose more metadata to the server than it should. Specifically, the main issues are:

* no sealed-sender (but see the OP on why this is not a panacea)

* server can see which users are in which rooms

* plaintext room names & topics (so serverside search can work)

* aggregations (metadata around reactions, edits, replies, threads - ie who reacted to what and with what emoji)

We’ve been working away improving this - for instance MSC3414 defines a way to encrypt key/value events like the above, and an implementation landed this summer. Similarly per-room user ids are planned too. However, it’s not trivial to get right, and we are underresourced so the work is going slower than we’d like. Also, decentralisation at least means the metadata doesn’t pool in some centralised place (as signal’s traffic footprint does, for instance). If you run your own server, then the threat may be acceptable.

[jeroenhd]

You can see the metadata outside of the e2ee envelope in Element. Things like message IDs in replies, room information, room IDs, in some cases emoji reactions, and other data will regularly find itself as part of the plaintext message. Of course there's still a HTTPS wrapper around those components, but the point is about E2EE.

Because Matrix wasn't encrypted from day 1 and because Matrix wanted to improve the general UX, especially for people not sending their notifications through Google and Apple, this metadata is still readable by the server(s) you connect to, so that they can serve users better. None of this is new and all of it is actively being worked on, but the Matrix ecosystem isn't exactly overflowing with funds at the moment so things take time.

Whether or not this kind of metadata being available to a participating server is a problem is up to you to decide. I use Matrix, I believe the federation upsides outweigh the protocol privacy downsides, so I don't think it's a problem for me.

However, the article discusses a privacy risk in Signal that is extremely niche and hardly a problem for 99% of people. It's more false advertising than an actual privacy risk, I'd reckon. What I want to make clear is that if you are part of the 1% where even the slightest metadata analysis poses a risk, Matrix is probably not the protocol for you.

I don't think there is any mainstream protocol that does fit the bill for someone like that. I'd start looking in the direction of Threema or TorChat if Signal isn't private enough.