this post was submitted on 11 Sep 2026

13 points (88.2% liked)

Matrix

3974 readers

41 users here now

An open network for secure, decentralized communication

founded 6 years ago

MODERATORS

k_o_t@lemmy.ml

Matrix Metadata Problem: the server sees everything except your messages (dfrws.org)

submitted 20 hours ago* (last edited 1 hour ago) by verifytheposter@leminal.space to c/matrix@lemmy.ml

15 comments fedilink hide all child comments

Matrix Metadata Problem: the server sees everything except your messages

People pick Matrix because of end-to-end encryption. But E2EE only protects message content — everything around it is plaintext.

The server sees:

Your ID, IP, client type and version, device you use
Your presence, typing status, read receipts
Which rooms you join and when you join/leave
Who else is in those rooms → your entire social graph
Room names, topics, avatars (all plaintext state)
For every message: who sent it, which room, a millisecond timestamp, type, size

And federation copies most of that to every other server whose users are in the room. Your "social footprint" isn't one copy — it's as many as there are servers.

top 15 comments

sorted by: hot top controversial new old

[–] fruitycoder@sh.itjust.works 2 points 1 hour ago

I wonder if there is a more practical solution of having matrix servers just be encrypted message routers. Maybe even encrypt the specific users address by the home server and then have federated servers just build routing tables for each other.

So my client sends an unencrypted header saying "send this to server A" with the specific user address being encrypted with Server A's public cert, the message content stays encrypted by the users pub cert. The message gets routed over to there distant server, user address decrypted on server, content decrypted on client.

Have server data like rooms, typing status, etc just be private messages ment for users sent by the distant server it's self. Home server only sees the rooms it's managing then.

[–] stratself 3 points 18 hours ago* (last edited 18 hours ago) (1 children)

Federation never sees your client IP and device details. The same problem applies to most messaging services and protocol anyways. Do you have any better offerings?

Although that SynExtract tool in the linked paper could be nice.

[–] verifytheposter@leminal.space 1 points 17 hours ago (1 children)

Signal is free from this disaster, and client version and device details are only visible to the main server — not to mention the avatar, name, and many more items listed above being in plain text.

[–] stratself 5 points 11 hours ago (1 children)

Kindly find me proof that the Matrix protocol explicitly sends a user client's version and device details towards another server when engaging in federation.

Do note that Matrix and open protocols are federated, and requires some amount metadata to actually process+route stuff.

[–] verifytheposter@leminal.space 1 points 5 hours ago (1 children)

It's already a problem that it sends the client's version, device details, avatar, and bio at all. Those device details are transmitted during federation along with everything else.

https://spec.matrix.org/latest/server-server-api

[–] stratself 1 points 1 hour ago (1 children)

Again in the linked Server-Server API, I can only find mentions of device details here. The most that is required is an opaque device ID, which alone cannot infer more device details. device_display_name is fully optional and hasn't been sent by servers for ages.

These device updates are used for sending device keys, which is needed for establishing multi-device E2EE sessions. The same kind of ratchet-based E2EE that Signal utilizes. The paper you linked only investigated a single server, non-federated deployment, extrapolating every finding to federation just doesn't make any sense.

[–] verifytheposter@leminal.space 1 points 1 hour ago

device_display_name is optional in the federation response. Current Synapse omits it by default, but it can still be sent when explicitly enabled. Older Synapse versions also exposed it through some federation paths.

I believe you are saying that my statement, “Federation copies all of that,” is incorrect. I agree. I should have said, “Federation copies most of that.”

However, the main concern remains: a homeserver can still collect the client type and version, the device being used, room names, topics, avatars, and other metadata. Much of this information is not necessary for delivering end-to-end encrypted messages, and its collection is concerning in itself.

[–] gary_host_laptop@lemmy.ml 4 points 19 hours ago

while i think it'd be nice if those things weren't seen it's not that much, specially if you don't use any real life connection to your user (you'd need to hide your ip i guess). i mean, you can't go to jail for any of those things. if you want even more privacy you can stop federating. i wonder how much of this is because of synapse and if the other servers would do better. they come with tradeoffs, though, synapse is the only one that supports self destructing messages for example afaik.

[–] JoeBidet@lemmy.ml 2 points 19 hours ago (1 children)

Matrix shall be considered a "metadata-rich protocol" :(

[–] gary_host_laptop@lemmy.ml 3 points 19 hours ago (1 children)

without that metadata you'd get a pretty bare bones experience. encrypting metadata adds another layer of complexity, not everyone wants that.

[–] verifytheposter@leminal.space 1 points 17 hours ago (1 children)

signal done it pretty well

[–] gary_host_laptop@lemmy.ml 8 points 16 hours ago (1 children)

signal? the one that requires a phone number to registar? the one that has a centralized server that you can't self host basically?

[–] verifytheposter@leminal.space 1 points 5 hours ago (1 children)

Matrix can expose your device name and device details to other homeservers through federation. Profile information such as your avatar and bio can also be queried remotely. A client version is not a dedicated federation field, but it can leak through the device name. Signal at least has Sealed Sender, which hides the sender's identity from its own service in supported cases.

This is about metadata, not centralisation, self-hosting, or phone-number registration. Those are separate issues, not trade-offs.

[–] Aria@lemmygrad.ml 1 points 41 minutes ago (1 children)

Those are absolutely trade-offs. Do you want the app to positively ID you and tie you to your passport, or do you want the app to broadcast your set name and set identity strings to those you opt in to share it with?

[–] verifytheposter@leminal.space 1 points 25 minutes ago

You haven’t explained why I have to choose between these two trade-offs. I want neither: I want strong metadata protection without being forced to link my account to my real-world identity.