I agree. I’m glad we reached this understanding.

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.

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.

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.

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

signal done it pretty well

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.