Matrix federation works. That's not the problem. The problem is that almost nobody uses it.
As of July 31, matrixrooms.info has discovered 19,935 federated Matrix servers. 4,151 of them publish their room directory. The most popular server software is Synapse at 78.3%. Continuwuity — the community Rust fork we recommended last week — is at 8.6% and growing, up from 8.1% a month ago.
But the real centralization statistic isn't in the server count. It's in the user distribution. Most Matrix users are on matrix.org. The homeserver run by the Foundation. The one that's the default in every client's onboarding flow. Federation exists, but the network looks like a star topology with matrix.org at the center.
This is the problem the Homeserver Decentralisation Working Group was formed to solve.
The Working Group Graduated
On July 24, the Homeserver Decentralisation WG announced it had graduated from a community group to an official Matrix Foundation working group. Nico Da Mutten, one of the chairs, credited TheDarkWizard for sponsoring the group.
This matters because official working groups have Foundation resources and recognition. Community groups are volunteer efforts that can dissipate. The upgrade signals that the Foundation considers decentralization a priority, not just a nice-to-have.
The WG's charter is straightforward: help users discover and join homeservers other than matrix.org. The expected outcomes are a technical solution for homeserver discovery, a Foundation-maintained list of trusted public homeservers, clear criteria for inclusion, and a transparent application process.
The Server List Policy
The WG's first concrete output is the Matrix Foundation Server List Policy — a finished document, open to PRs but functionally complete. It defines 10 criteria a server must meet to be included on the Foundation's trusted homeserver list:
- Recent, actively maintained server software receiving security updates.
- Backups with a 24-hour recovery point objective, including off-site backup.
- Multiple people with root access who know how to operate the server.
- A clear, published policy on stability — how much advance notice before feature reductions.
- Long-term operational intent.
- Public onboarding with a clearly defined, published signup process.
- Participation in the open federated network (blocklists for moderation are fine; general federation must be allowed).
- A human-readable website with: who admins it, how to contact them, moderation rules, registration process, hosting type description, and applicable legislation.
- Support for the well-known support endpoint per the Matrix spec.
- A moderation policy aligned with the Matrix code of conduct.
Servers can be removed for failing to meet criteria without remediation (within weeks), by admin request, for uptime below 95% over a year, or if the Foundation determines the server negatively affects the network's reputation.
This is a useful document even if you're not applying for the list. If you're deploying Matrix for a community — a fire hall, a town office, a community organization — these 10 criteria are a checklist for doing it properly. Most of them are things you should have anyway:
Backups. Off-site. 24-hour RPO. If you're running a community Matrix server and you don't have backups, you're one disk failure away from losing your community's communication history.
Multiple admins. The bus factor problem. If one person runs the server and that person leaves, the server dies. Community infrastructure needs redundancy in operations, not just in hardware.
A human-readable website. Not a wiki page, not a Matrix room — a website on the server's domain that explains who runs it, how to get help, and what the rules are. This is basic institutional communication.
Federation participation. A Matrix server that doesn't federate is just a worse Slack. The point is network membership.
Selective Presence — The Performance Problem Nobody Talks About
While the WG works on the social side of decentralization, MSC4495: Selective Presence addresses a technical barrier to running a homeserver at scale.
Matrix presence is fundamentally broken. The current design sends presence updates — online, offline, typing — to every user who shares a room with you. If you're in 50 rooms with 1,000 users each, your homeserver is processing and distributing presence updates for 50,000 people, most of whom you don't know and don't care about.
This is why most large public Matrix deployments disable federated presence. The performance cost is real. The privacy implication is also real — your online status is broadcast to everyone you share a room with, whether you want them to know or not.
MSC4495, published June 26 by a group of independent community developers including Continuwuity maintainers and the Nexus and Sable client teams, proposes selective presence: only share presence with interested users. Room administrators get an option to control whether presence is shared between members. The proposal is the first in a series dubbed "Presence v2" — additional proposals covering batching and sliding sync integration are in progress.
For community deployments, this matters in a specific way. If you're running a Matrix server for a fire hall with 30 users, presence isn't a performance problem. But if your server federates with the wider network — which it should — presence traffic from federated rooms can create load that's disproportionate to your user count. A 30-user community server in a few large federated rooms can end up processing presence for thousands of remote users. Selective presence would reduce that to the people who actually matter.
The initiative is community-driven, not Element-driven. The maintainers of Continuwuity, the homeserver we recommend for community deployments, are leading the spec work. This is the pattern we noted in the homeserver landscape article: the community is building the features that matter to operators, not just to enterprise customers.
Why Decentralization Is the Hard Problem
Federation is a technical protocol. Decentralization is a social outcome. You can build a perfectly federated protocol and still end up with a centralized network if everyone joins the same server.
Matrix has had federation from the beginning. What it hasn't had is a user base distributed across thousands of independent servers. The reasons are practical: most people don't know what a homeserver is, the default in every client is matrix.org, and running your own server requires technical knowledge that most communities don't have.
The Homeserver Decentralisation WG is attacking the first two problems — discovery and trust. A curated list of homeservers that meet operational criteria gives new users a real alternative to matrix.org. Clients can integrate the list into onboarding flows, making "choose a server" as easy as "choose matrix.org."
The technical problems — presence overhead, sync performance, the resource cost of federation — are being addressed by the community maintaining the servers people would actually run. Continuwuity's 256 MB footprint and SQLite-by-default deployment model make self-hosting practical for communities that can't dedicate a machine to chat. Selective presence makes federation affordable for small servers in large rooms.
What to Watch
The WG is now focused on automating the server list and onboarding process. The list itself doesn't exist yet — the policy does. Watch for the list launch and client integration.
MSC4495 is open for review. If you run a Matrix server, read the proposal and comment. The development room is #presence-v2:zirco.dev. The task list is at ispresencefixedyet.com.
The Matrix Conference is October 20-23 in Malmö. The WG will likely present there. If you're deploying Matrix for communities, it's worth following.
The broader point: a federated protocol is necessary but not sufficient. The work of making federation produce decentralization — not just protocol compliance — is social, organizational, and operational. The Matrix community is doing that work. That's more important than any spec release.