> Matrix isn't really decentralized

I think most of the concerns stem from the majority of the development in the ecosystem being driven by a single company. This manifests in a few ways:

matrix.org is by far the biggest server. Element is by far the most popular client. Both were (until recently) maintained by the same company, and the client selects matrix.org as the default server. This was done to make onboarding easier, but it centralised power into one organisation.

Theoretically, since Element does most of the development, if they want to push something into the protocol, the whole ecosystem really has to follow.

Because most people are on matrix.org, and the protocol works by replicating state between involved servers, matrix.org gets a lot of metadata even from conversations that are not hosted on their server (as long as one person in the chat is on matrix.org).

There are some flags which are enabled by default which automatically "phone home" to matrix.org even when you are running your own server. They are easy to turn off, but an annoyance for people who want to run completely separated instances.

The standard way to join a chat is via a "matrix.to" link. This leaks some information to matrix.org even if the server is completely separate.

By contrast, XMPP has no dominant player who drives most of the development, and no dominant server instance. I imagine this is because the protocol has been around for much longer (so there is more time for things to settle), and there is a very clear separation between the standards body and the software developers. There are popular clients that have some influence over the ecosystem, but nowhere near the extent as in Matrix.

Now, XMPP has its problems too, but few of these stem from having too much centralisation.

> which XMPP client you're using on Linux

I personally use Dino (https://dino.im/). It offers a simple, clean experience, and looks really nice.

There are also more fully-featured clients, like Gajim (https://gajim.org/)

* the webserver hosting matrix.to can see your browser’s IP and user agent as it connects to it. (this could be improved by connecting to matrix.to via an overlay network of some kind, or simply using matrix URIs instead)

* it cannot see the room/user being linked to, as this is deliberately hidden in a url fragment from the server

* it cannot see details about the room/user being linked to (eg the icon or room name); it optionally lets the client chose to grab this from a given homeserver, but the service itself never sees this data.

In other words, it was written with privacy in mind.