Matrix, still finding its feet

#PreambleWhat Matrix claims, and the distance between the claim and the reality

Matrix, as pitched on its own marketing material, is “an open network for secure, decentralized communication”. It promises the best of both worlds: the openness and self-sovereignty of a federated system, the end-to-end encryption of Signal, the engagement of Discord, and a bridging layer that lets every protocol talk to every other protocol. The implication is that Matrix is the final chat protocol — the one that renders all walls obsolete, where your identity is portable, your communities are resilient, and your messages are safe from everyone, including the server operator.

These are beautiful promises. The reality, as experienced by anyone who has actually run a homeserver, operated an IRC bridge, or tried to maintain a community on the network, is considerably more ragged. The protocol has been in continuous development since 2014, was at version 1.0 of its spec in 2019¹, and is still, in 2026, laboring under rapid, breaking change and a parade of “room versions”² and “feature powers”¹⁴ that betray a system still finding its feet. This document is an extended argument, in nine chapters, for the following thesis:

Matrix is an ambitious experiment that has outgrown its own foundations. Its protocol is unstable, its identity model welds every user to the server that issued their identifier, which means it splits communities instead of uniting them and locks each of those communities in by design; its most famous integration — the IRC bridge — is a structural nightmare; its administrative surface is a numeric ladder and a support email, with the real power sitting on a sysadmin your community cannot appoint, audit, or remove; its ecosystem is economically and operationally centralized in precisely the ways it claims to oppose, anchored by a default homeserver that is simultaneously the network’s biggest asset and its largest single liability; its clients are slow to the point of vendor-documented, benchmarked failure and broken in ways that no client engineering can repair; its end-to-end encryption — the one feature that supposedly distinguishes it — is a credential ceremony that its own users cannot complete, whose recovery paths are order-dependent and non-atomic, and whose vendor response was to make the machinery invisible; its timeline is not a record of what was said but a surface that can be rewritten after the fact, so that replies, threads, and reactions silently re-point at sentences their authors never wrote, and the protocol’s own specification serves two different versions of the same message depending on which endpoint you ask; and its security model leaks metadata, trusts servers it shouldn’t, and has shipped real, exploitable supply-chain holes. Matrix is not the future of chat. It is a very clever prototype with a very large marketing budget.

Everything below is written from the perspective of someone who has operated these systems, not merely read the spec. Where I cite specifics — room versions, bridge failures, breach reports — they are real and verifiable.

#Chapter OneThe protocol is immature

1.1 The specification never stops moving

A mature protocol has a spec that changes slowly and additively. HTTP/1.1 did not change for twenty years. SMTP has been static for almost as long. Even the much-maligned IRC is rock-stable precisely because it is old and boring — which is a feature, not a bug, because every IRC client, bouncer, and bot written in 1998 still works today.

Matrix has the opposite property. The client-server API has been edited thousands of times since its inception.⁸ New concepts arrive with regularity, not because the ecosystem demanded them, but because the Matrix Foundation decided they were good ideas and retrofitted them into a spec that was not designed for them. Consider the half-life of core abstractions:

• Room versions. At the time of writing there are roughly a dozen room versions (1 through 12 and counting)^{2, 6}, each a fork of the room-sync and state-resolution logic. A homeserver must implement the state resolution algorithm for every version it claims to support, because rooms live forever across version boundaries. The infamous “state resolution v2,”^{3, 4} introduced to fix the pathological worst cases and state-rewind problems of v1, did not fix all of them. The correct behavior of a Matrix room is, to this day, a research question under active investigation^{5, 6, 7} — including a formal academic analysis of the event-graph replicated data type itself that documents subtle convergence and consistency hazards in the room-state model,²⁷ — not a settled fact. That is, by definition, immaturity.
• The “feature inheritance” treadmill. The spec separates “room versions” from “extensible events” from “feature powers” from “capabilities,” and the interactions between them are complex enough that the spec team maintains a living document¹⁴ to explain which feature is valid on which version of which room. No mature protocol needs a compatibility matrix to keep its own rooms from disagreeing about how state works.
• Encryption was bolted on. Matrix was originally designed without end-to-end encryption in the protocol at all — it was added years later through the Matrix SDK (software development kit) layer (olm/megolm),⁹ then partially grafted into the spec. This means that encryption exists as an awkward overlay: clients perform complicated “device key share” dances, servers relay key requests, and the result is a system where a message can be encrypted to devices that are offline, unreachable, or whose keys were requested and never delivered. The protocol is still, fundamentally, a plaintext event replicator with a cryptographic afterthought bolted to the side.

1.2 The sync loop: long-polling as a four-part architecture

Matrix’s client design centers on the /sync long-poll endpoint.⁸ Every connected client holds an open HTTP connection to its homeserver, which streams updates as they occur. This sounds elegant and is, in practice, a scalability and consistency headache. Each sync request returns the entire room state delta since a token; the token advances monotonically, and if a client misses events (a dropped connection, a timeout) it must re-sync from the last token, replaying potentially thousands of events. Mobile clients with flaky connections “catch up” by pulling huge JSON payloads over constrained links.

Compounding this, the homeserver must compute state on every sync — power levels, membership, room history visibility — recursively, per room, per client. The infamous “state resolution” algorithm exists precisely because two servers can legitimately disagree about what the state of a room is, and the protocol has to spend real effort converging them.³ On busy rooms, the CPU cost of resolving state and generating sync responses is the dominant cost of running Synapse, the reference homeserver.¹⁷ Synapse’s awful performance is so well known that the Matrix Foundation has spent years funding not one alternative implementation but two — Conduit¹⁹ and Dendrite¹⁸ — while Synapse remains the only one most people can actually run. A protocol that needs its reference implementation replaced to be usable at scale is, again, immature. Independent measurement came to the same verdict: the peer-reviewed Middleware 2019 study of the live federation identified structural scalability limits in Matrix’s group-communication mechanism, and observed that genuine decentralization would only increase the per-server sync and state-replication burden, not relieve it.²⁸ The project’s own homeserver engineers said the same thing to a user in June 2022, when asked why their login was unusable: “Initial sync is notoriously slow. That won’t realistically be improved dramatically until sliding sync is supported.”⁶² Note the tense. In mid-2022, the flagship protocol’s flagship server’s own maintainers were telling users the fix was a mechanism that did not exist yet, and would not for another two years.

1.3 Server implementations are disparate and incomplete

The Matrix ecosystem has a handful of homeserver implementations in varying states of brokenness. Synapse is the default and is resource-hungry.¹⁷ Dendrite (the go rewrite) still lacks feature parity.¹⁸ Conduit is fast but minimal.¹⁹ And so on. The result is a fragmentation of implementation capability: the same Matrix client will behave differently against a full-featured Synapse on matrix.org than against a hobbyist Conduit instance, because whole feature categories — spaces, threads, voice rooms, specific room versions — simply don’t exist or disagree across servers. A user’s experience of “Matrix” is entirely a function of which homeserver their identity happens to live on. That is not a network; it’s a collection of loosely compatible toys.

One codebase, four names

The Conduit lineage is the sharpest evidence for that last sentence, because it is not four competing implementations. It is one codebase, versioned four times. Conduit — the Foundation-funded Rust server, whose hosting the Foundation still donates¹⁰⁰ — stalled in beta. In November 2023 a volunteer hard-forked it into conduwuit, and stated the reason plainly in its own README: to fix “the majority of upstream Conduit bugs or UX issues that are taking too long to be resolved, or unnecessary Matrix or developer politics halting simple things from being merged or fixed, and general inactivity.”¹⁰¹ conduwuit became the de facto Synapse alternative for small and self-hosted deployments — a single binary, a config file, and a database path — and the project’s own newsletter was writing it up by April 2024.¹⁰² Its final release was v0.5.0-rc4, published 9 April 2025; days later the lead maintainer announced that the project was over, and the repository is now archived.¹⁰¹

Within a few months two successors had appeared, and the detail worth noticing is that both forked conduwuit rather than Conduit. The transition was handled as a rename rather than a successor project at first — the binary was rebuilt as tuwunel while still recognising the old CONDUIT_ and CONDUWUIT_ environment variables¹⁰³ — and then split. Tuwunel took commercial sponsorship and, by December 2025, was serving Swiss citizens in production.¹⁰⁴ continuwuity is a community fork that describes itself, without irony apparently intended, as “the official community continuation of the conduwuit homeserver,” formed because “[t]he original conduwuit project has been archived and is no longer maintained.”¹⁰⁵ The archived conduwuit README opens by declaring that Tuwunel “is the ONLY official successor to conduwuit, no other project or fork is,” and that anyone claiming otherwise is “wrong and spreading disinformation.”¹⁰¹ Two projects, each the sole legitimate heir.

The project’s own servers directory resolves that disagreement the only way it can: by listing all four, at once.¹⁰⁶

Read that table as an operator would. Two of the four are graded Stable, they are not forks of one another, and each is the self-appointed successor to the same abandoned project. Anyone who follows the project’s own directory to “the fast Rust server” gets a choice the documentation does not resolve — and gets it from a lineage that has gone through three volunteer-maintained generations in the eighteen months since November 2023.

And the upgrade path is gone, not merely awkward. conduwuit offered drop-in migration from Conduit for about a year, then withdrew it: the README says bugs broke it, debugging Conduit “is not one of our interests,” and a Conduit user upgrading now “will have to wipe and reset your database.”¹⁰¹ continuwuity’s own migration page lists Conduit as incompatible alongside Synapse, Dendrite, and Grapevine; the only supported path is from conduwuit, by swapping the container image.¹⁰⁵ So an operator who chose the lightweight Rust server in 2023 and the lightweight Rust server in 2026 has a different name, a different feature set, a different maintainer, and no way to carry their state across except by recreating it.

This is the lock-in effect of Chapter Two running on the server instead of the account. There, a user could not leave without losing their history because their identity was welded to a hostname. Here, an operator cannot upgrade without losing the database, because the implementation is not a stable identity either. A protocol whose central promise is that your identity and your history are portable and permanent has no versioned continuity for its own reference alternative — and the fragmentation of implementation capability described above is not merely a list of missing features. It is a supply chain in which the successor of the successor breaks the migration path from the original.

1.4 The API is descriptive, specification-first, and unstable

Matrix’s client-server spec is descriptive to the point of being prescriptive: it documents m.room.member, m.room.power_levels, m.room.redaction, and so on, then reserves the right to change their semantics.⁸ The result is that almost every real deployment pins its client SDK to a specific “release train” and breaks silently when the server upgrades. Any ecosystem where applications have to track protocol-version changes as aggressively as Matrix developers do is not a stable ecosystem. It is a living target.

#Chapter TwoCommunities get split, not united

Matrix’s real product is not a protocol. It is a sentence: your community will not be split. Federate your rooms, invite your friends from any server, and the boundaries dissolve — that is the pitch, and the pitch is the whole reason communities adopt Matrix instead of a well-run forum. Everything in this chapter is about the distance between that sentence and the shipped product. The mechanism is short, and once you see it, the rest of the ecosystem’s behaviour stops being a pile of unrelated annoyances and becomes a single structural fact: Matrix has no community-level migration, and every migration it does have is per-account. A protocol that can only move people, one at a time, and only into brand-new rooms, cannot move a community. It can only divide one.

So, before the particulars, the shape of the damage. It is tempting to summarise the protocol’s behaviour here as one rule: a Matrix community can be fractured by any of the things below, and the answer is always the same — there will now be two rooms. That summary is wrong, and it is wrong in the direction that flatters the protocol. Two rooms is the best of the three available outcomes, and the only one with a paper trail.

There are three distinct answers, and they differ by a single question: where does the authority to name the divergence live?

One: the authorised split, which is two rooms. When whoever holds the power decides to replace a room — a version upgrade via POST /_matrix/client/v3/rooms/{roomId}/upgrade, or a client founding a replacement room carrying a predecessor field in m.room.create — the protocol does precisely what the slogan predicts. There are now two room IDs, and they are permanently two: the new room’s m.room.create points back at the old one via predecessor, and the old room receives an m.room.tombstone naming its replacement_room,⁸ so a client that understands either field can follow the community across. Note who executes this: the upgrading account’s homeserver mints the new room,³⁸ so the split’s geography follows the power map rather than the membership — the new community exists wherever the power happened to sit. This outcome is legible and joinable, and lossy in five ways at once. History cannot come, because every event embeds its original room ID and is signed by the sending homeserver.³⁹ The old room is not closed, merely pointed at, so it stays writable and its members stay in it. Only aliases on the upgrading homeserver transfer automatically.³⁸ On a room version that supports creator succession, the other creators are not inherited — the specification is explicit that the full set must be re-supplied, since the upgradeer’s are not copied automatically.⁸ And join rate limits during the window make it, in the Foundation’s word, “easy” to lose a room outright.³⁸ The spec’s own suggestion for what the user should experience is the tell: clients “may virtually merge the rooms such that the old room’s timeline seamlessly continues into the new timeline.”⁸ The offered remedy for a data-structure impossibility is a rendering trick.

Two: the unauthorised split, which is one room and a deletion. Now suppose the fracture is authorised by nobody: a network partition, a homeserver that reaches its own divergent conclusion and gossips it, or a fork propagated from a single server. There is no second room here at all. There is one room ID carrying two irreconcilable states, and the protocol’s answer is not a fork but a reduction. State resolution takes the divergent states, computes the conflicted set — every (event_type, state_key) pair the branches disagree about — and selects exactly one winner per key, discarding the losers.³ That is a winner-take-all reduction, not a coexistence. And what it discards is defined precisely by the specification: the “power events” whose conflicts the algorithm resolves first are m.room.power_levels, m.room.join_rules, and m.room.member events carrying leave or ban.³ So the state a server split destroys is, exactly and by design, the moderation state. The losing branch does not get its own room. It loses its power levels, its join rules, and its bans, and the room can conclude that its own members are no longer members. The specification names this outcome itself: divergent views of state “can lead to bifurcation of the room due to e.g. servers disagreeing on who is in the room.”³ There is no pointer, no second room, no tombstone, and no notification — and the outcome is not even guaranteed to match across servers, because the residual class of these defects is the one the project has been chasing for years without closing it.^{6, 7, 59, 65} This is not hypothetical. In June 2020 several users were ejected from #matrix:matrix.org because state resolution concluded their own homeservers were no longer in the room, and a Synapse maintainer’s assessment was that such conclusions “tend to persist for the lifetime of the room,” the only remedy being to leave, purge the room from the database, and rejoin.⁶⁰

Three: the community split, for which the protocol has no operation whatsoever — because a community is not a protocol object. The data model contains rooms, aliases, users, and (since Spaces) rooms grouped beneath other rooms.⁸ There is no community entity, no community identifier, and no operation that moves, forks, renames, or dissolves one. A “community” is a convention that humans maintain over a set of room IDs, a set of aliases, and a member graph — which is why the abstraction has already been renamed once (m.room.related_groups and /groups, deprecated in favour of Spaces), with both models still coexisting in the wild and neither behaving identically across clients. A thing the protocol cannot represent cannot be split by the protocol. It can only stop being one thing, one room and one alias at a time.

So the accurate summary of the shape of the damage is this: Matrix can represent a fracture as a fork only when someone with the power to authorise one performs it. Otherwise it either collapses the disagreement by silently discarding half of it — specifically the moderation half — or declines to represent the disagreement at all.

2.1 Identity is server-bound, so the network forks by default

In Matrix, your identity is @alice:theirserver.com.⁸ That is a federated address, but it is not a portable one. Your account, your membership in every room, your power level in every community, and your history are all owned by the homeserver that issued your localpart. And the localpart is not a nickname you chose — it is a routing key that names a machine, which means the hostname is welded into your identity permanently. Element’s own documentation is blunt about the consequence: “It is impossible to change the domain of any Matrix server.”³⁷ A user ID is therefore not a name. It is a mortgage on somebody else’s domain name, held at your local convenience.

If you created your account on matrix.org (as most people do, because that is where the mobile app defaults to) then your entire digital chat presence is a lease on the goodwill of one operation, and your identifier contains their brand.

Now consider what this does to a community. The protocol’s pitch is “decentralized chat.” The reality is that a community “on Matrix” is almost always anchored by a handful of rooms on one dominant server, with straggler accounts on half a dozen peripheral servers. And this is not a subjective impression: researchers from the Karlsruhe Institute of Technology crawled the public federation and reported the network as visibly imbalanced — users cumulated on a single large server carrying on the order of 50,000 daily active users, with the load concentrated accordingly.²⁸ The split is not a bug in that arrangement. It is the arrangement.

• Clients can’t log into multiple homeservers with one session. The Matrix client-server API is strictly single-homeserver. A user whose community is split across servers must maintain separate sessions, separate notifications, and separate encryption key stores per identity. There is no “one client, many servers” window into the network, and therefore no multi-server session to fail over to when one server is having a bad day.
• Identity verification is per-server and per-device. Getting your history, rooms, and encryption state onto a new server requires you to leave everything behind. Sydent, the legacy identity server, was a partial attempt at a portable identifier and has spent its later life as an unmaintained side project outside the Foundation⁴⁵; the fundamental unit of identity in Matrix remains the homeserver. If you quit matrix.org and join another server, you are, transactionally, dead to the rooms you inhabited on matrix.org.
• The default centralization is a single point of failure. Because the companion element.io and matrix.org are the de facto defaults, the “decentralized” network is dominated by one operator, one server, one moderation policy set, and one incident-response regime. That is not a federation of equals; it is a monarchy with a peer-to-peer flag.
• You cannot even find each other. The user directory is a per-homeserver index of users that server has some connection to — local accounts, and remote accounts that share a room with a local user or sit in a public room the server knows about.⁴¹ The user directory performs no federation queries of any kind:⁴² a person is discoverable only through a server that already shares a room with them. So “is this person even in our community?” — the first question of every onboarding, every incident, and every investigation — has no network-wide answer, and the answer a community gets depends on which server is asking.

2.2 The lock-in effect: the switching cost is the product

Every protocol has a migration story. Most protocols are boring about theirs. Matrix has no migration story, and it has something worse than no migration story: it has a documented, first-person account of what attempting one costs, published by the project itself.

A community administrator who decides to leave matrix.org and self-host has, per Element’s own documentation and the community’s own walkthroughs, the following options. There is a web tool that automates cross-server account merging — it has been broken for years, does not support the current authentication stack, and has been removed from the hosting portal entirely rather than fixed.⁴⁰ There is the manual method, and the manual method is: export your keys, register a new account, invite the new account to every room you can invite it to, re-grant every power level by hand, and re-join everything else yourself.^{35, 36} And there is the detail that finishes the argument, from the community’s own walkthrough of doing this carefully: in a room set to share history only from the point of invitation, the new account cannot see anything that happened before the invite, and there is no setting, admin or otherwise, that overrides it.³⁶ For a room with a two-year history, “we tried to move and the archive is gone” is the expected outcome, not the failure case.

Now read the warning in the Foundation’s own migration write-up, because it is the most honest sentence anyone in the Matrix ecosystem has published on the subject: “Homeserver migration is a high stakes process, as there’s a point past which mistakes will permanently wreck your ability to communicate with other people on the open federation. At that point, the resolution is to create a new account!”³⁶ The same post adds that messages sent into encrypted rooms during the migration window “will likely be unreadable, even if you do everything right.” One person, one server, one weekend, with DNS TTLs setting the deadline, and an acknowledged chance of ending up with a fresh empty account. And that is the easy case, where the person moving is the sysadmin and has the keys, the backups, and the time.

Multiply that by a community and the switching cost stops being a cost and starts being a wall, and it is a wall with a specific shape. The cost of leaving a Matrix community is the sum of every member’s individual migration, executed in parallel, on a deadline, with a failure mode that is permanent. The cost rises with the size of the community. It is highest for exactly the people with the least leverage: the ordinary members, who have no sysadmin skills, no key backups, and no reason to spend a Saturday on someone else’s infrastructure politics.

That produces a predictable and thoroughly observed outcome. The person with the strongest reason to leave — the admin whose server is being seized, reorged, or bought; the organization whose compliance team has opinions; the sysadmin who simply got tired — does leave, and sets up somewhere else, and makes a new room. The majority stays, because for them the migration is expensive, risky, and entirely pointless. Now there are two rooms. Two aliases. Two ban lists, two sets of moderators, two histories, and roughly half the moderation capacity in each. And both halves are worse than the one room was, because the split cost the community its shared memory and doubled its coordination cost without doubling its moderation.

This is the crux, and it is worth stating without hedging: the split is not a side effect of Matrix’s migration story. The split is the only outcome its migration story permits. Because there is no unit of community-level movement, every departure is a person leaving, and a person leaving cannot rejoin a room on another server — they join a different room, one with no history, no power, and no members. A protocol that can only move people, individually, into new rooms, has built a diaspora generator and labelled it federation.

The cost of leaving a Matrix community is the sum of every member’s individual migration, and each of those migrations is a documented, high-stakes, one-way operation with a real chance of ending in a brand-new empty account. No community ever moves. Communities split — and then spend the rest of their existence arguing about which half is canonical.

And the lock-in is not a side effect either. It is the design working as intended, just not as marketed. The element that makes Matrix federated is the same element that makes your identity unportable: the server-name suffix. You cannot have one without the other. A protocol that let you change servers without changing who you are would not need you to federate at all — it would just be a protocol. Matrix chose the server as the unit of identity, and then the server became the unit of lock-in, and the marketing called that a feature.

2.3 Why matrix.org is the worst possible home for a community

The lock-in argument has a preferred victim, and the ecosystem nominates it by default. Element’s clients ship pointed at matrix.org; that is where a new member ends up when they install the app and type nothing. Which means the most important infrastructure decision a community makes — where its collective memory, its member graph, and its moderator keys will live — is made by default, by a person in a hurry, and is effectively never revisited. A community that adopted Matrix “because that is what everyone uses” has adopted matrix.org, and has thereby done the one thing it was deploying a decentralized protocol to avoid, on day one, without a vote.

Here is what that arrangement means in practice, given what the operator is and is not:

• There is no contract, no service-level agreement (SLA), and no recourse. matrix.org is operated by a nonprofit foundation and its commercial sibling,²³ not by a party that owes your community anything enforceable. The terms under which your community exists can change on the day they choose, and the only remedy available to you is the migration described above — which is to say, the only remedy is the one that does not work well.
• The free tier is a product decision, and it has already gone the other way. Element Matrix Services — the managed hosting that the apps defaulted to — has been narrowed toward enterprise, and the documented consequence for users is that they are now expected to self-host.³⁶ You did not choose this. Your signup form chose it for you, and the withdrawal notice came as a migration guide.
• The operator can withdraw a service your community depends on, on two weeks’ notice. When the sliding-sync proxy was retired in November 2024, the announced procedure was that the service would be decommissioned and that users “will get logged out” to move to the native path.⁴⁶ That is a small thing, technically. It is also the clearest available demonstration of the governance model: a component of your client experience, deployed on the network’s central infrastructure, can be ended unilaterally, and the community’s recourse is a forced logout. Judge every other unilateral decision by that precedent.
• One legal process reaches your entire community. A single subpoena, court order, or takedown request served on one operator yields the membership graph, the join and leave timeline, the IPs, the device list, the moderation records, and the unencrypted traffic of every room that operator hosts. The end-to-end encryption from Chapter Six does not help here, because the metadata is plaintext and the server is a party to the request. A community that chose Matrix to get away from exactly this failure mode chose the largest single repository of exactly this data in the network.
• You cannot fail over, and you cannot hedge. Your client speaks to one homeserver.⁸ You cannot point it at a second one to keep reading while the first is degraded, seized, or switched off, and you cannot hold a backup account that transparently carries your room memberships. Your redundancy strategy is “ask the members to rejoin somewhere else,” which is Chapter Three’s bridge problem wearing a different hat.
• The keystone has been breached, and the domain is the company’s to lose. In April 2019 the matrix.org production database — identities, rooms, access tokens, password hashes, and the signing keys for its own packages — was reached through a build server.²² The same class of flaw reappeared in 2021 as a room-key theft spanning Element and several independent clients at once.¹⁰ And because the domain is baked into every user ID, a rebrand, a domain retirement, or a corporate transaction at Element is not an inconvenience to your community; it is an identity migration it can never perform.³⁷
• It is also the most attacked server on the network. The server carrying the plurality of users is the server carrying the plurality of spam waves, rate-limit pressure, and abuse load, and its rate limits are set by policy rather than by your community’s tolerance. A moderation team’s worst day is the day every other community on matrix.org is having one too.

None of this requires matrix.org to be badly intentioned, and it should be said plainly that it is not: the Foundation has published breach disclosures, CVE (Common Vulnerabilities and Exposures) notices, and kill-switch plans with more candour than most operators of its size. The problem is structural, not moral. Governance cannot be patched by good intentions. When the design says that one party’s unilateral, unappealable, uncompensated discretion is the load-bearing element of your community’s continuity, then the honest reading of that design is that your community has an owner, and the owner is not you. “Decentralized, except for the part where everything actually is” is a slogan. This is what the slogan costs.

2.4 The administrative floor: what a community can actually do

Now the part of the critique that should worry community operators more than the centralization, because it is the part they discover in month two. Matrix gives you moderation and calls it administration. Administration is the ability to make and enforce a rule across a population you do not control. Here is the honest inventory of what a Matrix community’s administrators actually have:

Two things in that table deserve to be pulled out, because they are the load-bearing failures rather than the merely annoying ones.

The information asymmetry runs the wrong way. The party with the least legitimate interest in your community — a sysadmin you have never met, on a server whose owner you do not know — holds strictly more information relevant to moderation than you do. They can see every room a user is in, their IP addresses, their device list, their email, their join and leave history across the whole server, and their entire timeline. You, the room’s actual administrator, can see one room. The entity best placed to detect a ban evasion is the entity with the least incentive to, and the entity with the most incentive is the one you cannot ask. No amount of moderator tooling fixes that, because the gap is not in the tooling.

Administrative continuity in Matrix is a key-management problem wearing a governance costume. Every moderator is a personal account, on a personal homeserver, unlocked by personal device keys, and their moderation power is attached to all three. The protocols that are supposed to make that robust — cross-signing, key backup, verification — are, per Chapter Five and Chapter Six, the least reliable code in the ecosystem, and the ones that fail silently. So the most important governance question a Matrix community has — who can act on this community if Alice is unavailable? — is answered by Alice’s passphrase and by whether she exported it. That is not a moderation model. That is a shared-secret ring.

Matrix gives you a per-room numeric ladder and calls it administration. It gives the community the ability to remove a single string from a single list, and it gives the operator of the server everything else. Kick, ban, ignore — that is the whole toolkit. A community that needs to govern itself — to define roles, enforce rules, verify identity, rate-limit, delegate, retain, escalate, and hold its infrastructure accountable — is a community that Matrix cannot host.

2.5 The community abstraction keeps moving, and the move is a split

Matrix has been through multiple attempts to model “a group of rooms.” Early on, there was m.room.related_groups and the “community” concept with /groups. That was deprecated and replaced by “Spaces” (m.space.child events)⁸ — yet another new event type with new semantics, requiring new client support. Migration tooling was bolted on late, and the two models still coexist in the wild. A “community” on Matrix is therefore a moving target: rooms that predate Spaces, spaces themselves, and rooms claiming both, none of them behaving identically across clients.

But the deepest version of this problem is not the Spaces churn. It is that the Foundation’s own documentation instructs communities to split, and does so as best practice. Upgrading a room to a new room version is performed by creating a new room and leaving a tombstone pointer behind,³⁸ which means the officially recommended way to change anything fundamental about a room’s rules is to found a second room. The guide is admirably candid about the consequences, warning that the decentralized nature of Matrix creates “circumstances that your homeserver cannot automatically mitigate,” that only aliases on the upgrading homeserver transfer automatically, that the room directory on every other server will need manual correction, that join rate limits during the upgrade mean “it is easy to lose a room,” and that some clients cannot even follow an upgrade from the old room to the new one.³⁸ Read that list again with the framing of this chapter in mind: every item on it is a mechanism by which a room upgrade leaves members behind in the old room and the community becomes two communities.

What cannot come along is history, and here the reason is not operational but cryptographic, which is to say permanent. The Synapse maintainers’ own answer to the long-standing request to carry history into an upgraded room is that each event embeds the original room ID and is cryptographically signed by the sending homeserver, so one server cannot re-issue them under a new room ID — it is not a missing feature, it is a property of the data structure.³⁹ Room version 12 pushes the same logic one step further into ownership, granting the room’s creator “irrevocable full control” and letting communities nominate additional_creators.³⁸ The protocol’s answer to “what if the person who created this community loses their account?” is more accounts, on the same class of infrastructure, that can also lose their accounts.

This churn has a real human cost. Communities are built on the identity model of the day. When the identity model changes, the community either rebuilds itself (losing membership, history, and trust) or splits: a new space on one side, a lingering room graph on the other. Every abstraction change in Matrix is, in effect, a small diaspora generator — and unlike the previous ones, this one is documented, recommended, and unskippable.

2.6 Moderation can’t reach across the ecosystem

Moderation in Matrix is done per-room by operators with power levels, using m.room.kick and m.room.ban, plus the one primitive the spec offers as its answer to moderation at network scale: policy lists (m.policy.rule.*), where a community publishes its rules once as events in a dedicated room and other rooms are supposed to enforce them. Fine-grained moderation APIs live in “MSC” (Matrix Specification Change) proposals¹⁴ (most notably, moderation APIs around MSC 2457 and reporting) and are inconsistently implemented.

The net effect is that when abuse happens on Matrix, the response is as fragmented as the network itself. A report submitted on one server must be forwarded — people coordinate via password-protected moderator rooms, which are themselves just Matrix rooms with their own availability problems. A proper moderation toolset — account-wide bans, global ignore lists, cross-server blocks — is only now being seriously standardized.

And the fragmentation is not merely inconvenient; it inverts the guarantee the ban is supposed to provide. A ban is a claim about a person, expressed as a fact about a string. One human being can hold as many MXIDs as they have spare email addresses, on as many servers as they care to register with, and nothing in the protocol links them — not the shared IP, because the operator sees that and the moderator does not; not the device fingerprint, because the moderator cannot see devices; not the behavioural signature, because there is no shared reputation to violate. The moderator bans a costume, and the community is told the problem was solved. Meanwhile IRC’s equivalent — a network-level KLINE (a network-wide ban on a host’s address mask), a cloaked hostmask, a services-authenticated nickname — is enforced by the network itself, applies to every channel on every server, and survives the offender changing channels, changing clients, and changing nicks. It has been battle-tested at a scale Matrix cannot touch, and it is the reason a decade-old protocol still handles harassment better than a protocol with five years of academic papers behind it.

Two further asymmetries make this worse in the federated case specifically. First, enforcement cannot even be requested coherently: reports go to the admin of your own server, who has no jurisdiction over the reported account, so cross-server abuse resolution runs through moderator-room coordination and out-of-band email — which is to say, through trust. Second, enforcement is unilateral in the wrong direction: a room admin’s ban reaches exactly as far as the room, but a server operator’s federation restrictions reach everywhere. Homeservers can and do restrict federation by domain,⁴³ so a community can be severed from a third party’s entire userbase by that third party’s sysadmin, unilaterally and invisibly, while the community’s own moderators retain exactly one tool — asking nicely, in a moderator room, in a client they no longer control.

It is hard to argue that an ecosystem which fragments enforcement, distributes trust to strangers, and hands the keys to the operator is the one that unites communities. Matrix does not fail to moderate. It fails to make moderation portable, and portability is the entire premise of the network.

#Chapter ThreeThe IRC bridge headache

3.1 Why everyone bridges, and why everyone regrets it

The most visible — and most technically fraught — integration Matrix promises is the IRC bridge.^{20, 21} IRC networks are old, vast, and populated. Bridging is how most people encounter Matrix at all: your project’s IRC channel gets an @…:matrix.org ghost, or your Matrix room forwards events to a Libera channel, and suddenly you are on the “bridge.”

The IRC bridge is where the immaturity of Matrix’s protocol becomes a daily operational crisis, because bridging two systems requires that you translate everything one protocol says into the other. The semantic gaps are enormous:

The classic failure is ordering. IRC has no edit/fetch-context and no redaction. When a Matrix user edits or redacts a message, the bridge has to synthesize — typically appending a “message edited” note — and IRC users see a stream of synthetic corrections, while the Matrix users see a clean consequence-free edit. The two halves of the community are, in effect, reading different conversations, and neither side is wrong.

3.2 The bridge is a single point of failure at the worst place

To bridge IRC to Matrix, you run a homeserver-hosted application service (“as”) that opens a persistent IRC connection per channel. That bridge now holds the authority for the identity of the entire merged community: it relays messages, it owns the “@ghost:bounce” nick for every IRC user, and it duplicates the entire room state. If the bridge process dies, the only symptom is “why is the channel silent?” — while Matrix users keep chatting into a void and IRC users see a channel that has simply gone quiet, with no error and no explanation. There’s no transparent way to detect a dead IRC bridge without external monitoring.

And because IRC networks block abusive bridges, the Matrix team has, over years, hit every IRC network-side anti-abuse mechanism there is: mass-nick collisions that trip flood protection, i-line limits, and network-wide modes that clamp down on a bridge that misbehaves. The infamous “the IRC bridge ‘lost the room’” episodes — where a bridge’s IRC connection gets killed by the network and the room has to be manually re-bridged — are a recurring operational genre on the matrix-dev mailing lists.

3.3 Presence, history, and the ghost problem

A Matrix user sends a message into the room. The IRC bridge delivers it as <@matrix-ghost:example.com> text. An IRC user replies. The bridge converts that into a Matrix event signed by a user-ghost @irc-nick:example.org. Now consider trust: the IRC user never authenticated to Matrix; their ghost identity is asserted on nothing but the bridge’s word, and the bridge is the only thing vouching for the mapping.

This is the “ghost trust” problem. Every IRC operation — membership, moderation actions by IRC ops, bans, kicks — must be represented in Matrix as events authored by a ghost that the IRC side implicitly trusts.²⁰ If the bridge is compromised, all of IRC-side identity becomes repudiable: a malicious bridge can attribute any message to any IRC user, kick anyone, and forge ops’ moderation actions. And this is not theoretical; IRC bridges have been a target and a vector across multiple networks.

Presence is even worse. IRC presence is derived from the fact that a client is connected to a server. Matrix’s “presence” is a protocol-level concept that the bridge must fake by polling and relaying connection state, or simply by reporting anyone who has spoken in the last few minutes as online and everyone else as away. Online/offline state across the bridge therefore misleads both communities.

3.4 The bot/integration swamp

IRC users expect the ecosystem of bots — the channel bots, the services-based operator tools, the feed watchers — to keep working across the bridge. But bridged IRC bots see a stream of matrix events (edits, reactions, threads, redactions) for which they have no native concept, and Matrix-side bots get IRC’s drastically coarser event stream. The integration toggle is unidirectional: IRC gets Matrix’s richness reduced to text, and Matrix gets IRC’s poverty preserved as poverty. Nobody’s tooling survives the crossing intact.

The famous corollary is that bridging Matrix to IRC “for free” is a lie. It is a sustained engineering effort, and the effort shows.^{20, 21} There are long track records of bridge bugs: edited messages exploding into multiple IRC lines, reactions becoming numeric mojibake, users double-posting, and — because the bridge is a third participant in every room — rate-limit loops where the bridge retries and retries a message that the IRC server rejected. Every one of these has a mailing-list thread that ends with “this is a long-standing limitation of the bridge.”

#Chapter FourThe ecosystem is broken

4.1 De-facto centralization (the opposite of the pitch)

Matrix’s defaults are matrix.org and element.io — the latter being both the reference client and the operator of the reference hosting — and the doctrine that follows from those defaults is simply: use matrix.org. The practical shape of the ecosystem is:

• One dominant homeserver (matrix.org) carrying the plurality of accounts and the most important rooms and communities.
• One dominant client (Element) with near-monopoly UI.¹⁵
• One dominant bridging/image/hosting stack from the same corporate cluster, funded by the same private foundation and corporate donors (Sphere, Automattic, etc.).

That cluster is a single point of failure in the truest sense: when matrix.org was breached in April 2019 and its production databases were reached, essentially every user who depended on those rooms felt the aftermath.²² “Decentralized — but everyone here is really on matrix.org” is a joke every Matrix operator has made, and none of them finds it funny. The academic measurement confirms the joke: the federation crawl found the network’s activity and load concentrated in a dominant server, directly contradicting the decentralization ideal the protocol is sold on.²⁸

4.2 The moderation problem is structural, not accidental

Because identity is bound to a single server, and because a server cannot see the users of any other server, there is no network-wide record of pseudonyms. You cannot, at the network layer, ban a user — only a room, a home server, or (if you operate the server itself) an account. Malicious users simply create accounts on a fresh homeserver and rejoin. The Matrix ecosystem’s answer (“room validation,” “Moderation policy lists”) is immature: policy lists are event types in a “policy room” that users must discover and subscribe to, and there is no standard global blocklist across the network. Compare with IRC’s long-developed, network-wide operational machinery: services, cloaks, network-wide kill lines, and operator tooling that, while also imperfect, is battle-tested at a scale Matrix can’t touch.

4.3 The financial model is a charity case

Matrix is bankrolled by the nonprofit Matrix.org Foundation plus corporate sponsorship.²³ Homeserver infrastructure — the storage, the bandwidth, the incident response — is a cost borne privately by the foundation for a service the whole ecosystem depends on. There is no economic mechanism for the network to self-sustain: hosting is a donation. This is the classic tragedy of the commons. As the network grows, matrix.org’s burden grows, and the heaviest users of it are precisely the small operators, who shed their own infrastructure costs onto it. The foundation is perpetually fundraising, the server is perpetually overloaded. A protocol ecosystem that cannot economically sustain its own core node is a broken ecosystem. It has been “improving” at this for years, without end.

4.4 “Trusted by secure organizations”: the customer list is the funding model

Element’s marketing does not merely suggest that governments and militaries use Matrix. It publishes a heading that says so, and under the heading a wall of the institutions. On the page that sells Matrix as the standard — the page a prospective public-sector buyer actually reads — the section is titled “Trusted by secure organizations.” and the sentence beneath it reads: “Element works with a number of large multinational corporations as well as government organizations all over the world, including NATO, Space Force, the French Government and the German Bundeswehr.”⁷⁹ The sentence names four. The wall under it has twelve logos: HM Government, Försäkringskassan, Dinum, Bundeswehr, BWI, United States Navy, Gematik, Dataport, United States Space Force, US Marines, hexagon.com, fedoraproject.org.⁷⁹ The defence page is blunter — “Trusted by armed forces, alliances and partners” — and its wall runs the Ministry of Defence, US Navy, Bundeswehr, NATO, the United Nations International Computing Centre, and then Raytheon, Roke, Boeing, Boxxe, Partner Force and Veilant.⁸⁰ The landing page selling the analyst report carries a third variant: “Trusted by the world’s most secure organisations.”⁸⁴

Read as a list rather than as decoration, the first wall is doing something specific. Three of the twelve are American military services — Navy, Space Force, Marines. One more is the German armed force. Two are national agencies, for health IT and for social insurance. Two are government IT suppliers. One is a digital administration directorate, one a defence-industrial group, and one is a Linux distribution. A logo wall cannot distinguish a four-hundred-thousand-user deployment inside a national accreditation boundary from a project that uses the protocol for nothing, and it does not try, because the entire function of a logo wall is to transfer the authority of the most alarming entry to the least. The Chapter Two argument applies to procurement as much as to users: the buyer is not choosing Matrix. They are choosing the Space Force emblem.

Now take the two most load-bearing entries and read the vendor’s own words, because this is where the heading and the documentation part company. NATO’s NI²CE Messenger — NI²CE being the NATO Interoperable Instant Communication Environment — is described by Element as “an experimental Matrix-based project that aims to complement existing NATO communication solutions with a secure Bring Your Own Device (BYOD) style messenger for ‘unclassified’ use”⁸² — and, in the company’s own summary of the same announcement, “a low-side sovereign messenger.”⁵⁴ The American entry: “In the US, federal customers such as the DOD (Navy and Marine Corps) run Element themselves on their own infrastructure at the necessary classifications, mitigating the need for FedRAMP certification”, a trade the same page describes as cross-domain connectivity “between high-side and low-side environments.”⁸⁰ (DOD is the US Department of Defense; FedRAMP is the US Federal Risk and Authorization Management Program, the accreditation federal agencies require of cloud services.) Set that out plainly, because it is the whole section. The flagship military logo on the wall is a bring-your-own-phone, unclassified, experimental messenger. The other is a deployment the customer runs itself, deliberately without the US federal cloud authorisation standard. Both are defensible products. Neither is what trusted by secure organizations conjures — and the unclassified ceiling is not a criticism of the product: it is the specification of the product, and the wall does not carry it. The German armed forces’ BwMessenger is put at “more than 100,000 active users” and UNICC is a named customer;⁸¹ the same platform, in the same breath, is described as connecting “more than 300,000 civil servants” across the French government, where the company’s own 2021 funding announcement said the deployment covered “some 5.5 million civil servants.”⁹⁶

There is one claim on that page which would satisfy the heading, and it cannot be checked: “our self-hosted solution is accredited and deployed at SECRET and other classifications in multiple countries.”⁸⁰ No accrediting authority, no national scheme, no scope, no date, no product identifier. Accreditation at that level is granted by a state’s security authority to a specific system inside a specific enclosure; it is not a property a vendor can assert about a product family, and no public register of such accreditations carries a self-hosted software SKU as its object. The claim is probably true in the way these claims usually are — some national body, somewhere, accredited some configuration, once — and it is also unfalsifiable as written. What sits beside it on the same page, and can be checked, is a set of commercial compliance marks: Cyber Essentials Plus, ISO/IEC 27001:2022 and an OpenChain ISO/IEC 5230 badge.⁷⁹ That is the assurance a public-sector buyer can actually audit, and it is a different kind of object from the state accreditation claimed in the sentence above it.

The scale of this, in the vendor’s own accounting, is one sentence long: “There are currently 16 governments that make use of Matrix-based software for their communications. As it’s usually the most security-conscious parts of government that pioneer the use of Matrix, we often can’t cite those deployments.”⁵⁴ That deserves to be read twice. Sixteen governments — and the most security-conscious of them are precisely the ones the company cannot name. The deployments that would substantiate the heading are, by the account of the company doing the heading, largely uncitable. The one figure that ever became public arrived from outside the company, and the company says so itself: senators Ron Wyden and Eric Schmitt “have put the US Navy’s use of Matrix across ‘23 afloat units and 3 shore sites’ into the public domain” — two senators writing to the Department of Defense in December 2024, after Salt Typhoon exploited lawful-intercept backdoors in the American telephone network, urging the DoD to expand its use of Matrix and to investigate its failure “to secure its unclassified telephone communications from foreign espionage.”^{54, 82, 83} The endorsement that made the marketing possible is a congressional complaint.

None of that would be remarkable if it were not the funding model, so it is worth being exact about where the money comes from, because the three sources are not the same kind of thing. Element has taken roughly $48M in venture capital, itemised in the public record: $5M from Status in 2018, $8.5M in a 2019 Series A, $4.6M from Automattic in 2020, and $30M in a July 2021 Series B led by Protocol Labs and Metaplanet, with Automattic and Notion participating.⁹⁶ Before any of that, for the first three years of the protocol’s life, the core team was paid by a third party entirely — and the Foundation’s own account of those years is that it did not pay for its own work: “Amdocs (who incubated Matrix) and Element (hiring the core team) shouldered most of the costs.”^{86, 97} And on top of both sits the third source — the one the wall advertises. Element Server Suite is described by its own vendor as “Element’s core revenue-generating product”, with the revenue funding everything else the company does, and Synapse Pro sold “under a commercial licence, which in turn will help fund our open source work.”⁵⁴

That last clause is the mechanism, and the project documented it on a stage, in the present tense of its own decision. At FOSDEM 2024 — the annual Free and Open Source Software Developers’ European Meeting — the Foundation’s chief executive set out the arithmetic on one slide: “Lots and lots of large deployments not helping funding underlying dev”; “‘Public Money For Public Code’ ⇒ Govts only want to fund new features”; and, as the conclusion of the whole year, “Element ended up switching its development on Synapse to AGPL in order to sell AGPL exceptions to those who need them.”⁸⁹ The slide before it plots “size of deployment” against “size of financial support to the Matrix core team in 2023” for Ukraine MOD, France (Tchap), gematik, NATO, UK Govt, US Govt, Poland MOD, Sweden, Bavaria Schools, Hessen Administration, NRW Schools, BwMessenger, BundesMessenger, openDesk and Phoenix Suite — the project putting its own public-sector deployments on a chart whose second axis is money.⁸⁹ And the request attached to it is unambiguous about who should pay: “Meanwhile, much of github.com/matrix-org is written and maintained by the core team hired by Element, who donates their time to the project — please support them by buying enterprise Matrix deployments from Element if you’re a Government or Enterprise.”⁸⁹ The Foundation put the decision in its own voice that December: Element “can no longer financially afford to donate its work on Synapse and other server components” under a permissive licence, so it relicensed — and the same post records what the squeeze cost elsewhere: P2P Matrix, Low Bandwidth Matrix and Account Portability paused, Element-funded Dendrite work stopped, and the Third Room team disbanded.⁹⁸ The model’s logic is complete and self-describing: the protocol is free, the reference implementation is commercially licensed, the largest deployments buy the licence, and the money is not expected to reach the specification.

Which produces the finding this section actually rests on, and it is not a matter of interpretation, because the Foundation says it in its own words. A January 2024 board paper, written to recruit funding members: “Element cannot afford $5M/y in this macro environment. Many large deployments go live without contributing neither code, resources nor funding.”⁸⁶ April 2024, with the xz backdoor as the occasion, the diagnosis is sharper: maintainership is “distinctly overstretched” in a protocol that is “at the heart of huge amounts of critical infrastructure, ranging from the Ukrainian MOD to NATO and at least 15 other countries and major international organisations”, and the consequence of the money stopping is named as “a massive hole in funding for Matrix.”⁸⁵ The cause is not ignorance but procurement design, and the Foundation describes the mechanism with unusual precision: “procurement departments want to have something concrete to procure as a one-off, rather than making an ongoing commitment to keep the project secure” — so they fund features, or their own staff, and “ignore maintenance.”⁸⁵ A ministry of defence, asked to help fund core Matrix development given its operational dependency on Matrix, replied: “You have to understand, we’re responsible for taxpayer money here. We can’t just make a donation to your open source project.”⁸⁵ The post’s own remedy is not a market one. If “free and open source software has literally become shared digital public infrastructure”, then “FOSS maintenance should be funded by governments on behalf of the taxpayer. This funding should NOT be tied to specific feature development, but simply funding the core maintenance of the infrastructure.”⁸⁵

The Foundation’s accounts are how that becomes concrete, and they are published. In 2024 it nearly doubled revenue to $561K while carrying the full cost of operations for the first time, at $1.2M; it liquidated $283K of cryptocurrency donations, ended the year $356K in deficit, and says it needs an additional $610K merely to break even — a shortfall a single $100K grant would have covered for one month.⁸⁷ The bridges, the reason most of the network arrived and the subject of Chapter Three, were closed or scheduled to be archived when that target was missed; by 2025 the WhatsApp bridge was “on ice until funding is unlocked.”^{87, 90} The reference homeserver that 4.1 called the network’s centre of gravity began charging for what had been its free tier, because “the alternative is to turn off the server” — which would have left “its 370k monthly active users in the awkward position of finding a new home for their account.” The sentence that indicts the customer base is the project’s own: “none of the big players in the ecosystem have actually committed to one of the higher membership tiers.”⁸⁸ The 2025 report adds two details that finish the picture: the number of Silver members doubled but brought only 30% more revenue, “due to them mostly being small organisations”, and after churning one Gold member, “the one left (Automattic) now corresponds to 50% of our revenue.”⁹⁰

And in that same report the loop closes. Its own summary: “The main shadow on the picture has a financial shape, as the Foundation is still struggling financially, which hinders its ability to support and grow the ecosystem.” Then the disclosure: “It is worth noting that Element’s Platinum membership was supported by in-kind contributions and financial support in 2025, and thus doesn’t appear as revenue in financial reports.” The matrix.org homeserver, though a Foundation project, is “operated under contract by Element”, and the stated objective for 2026 is to “build financial independence from Element” by “paying for the operational services they provide rather than have them as in-kind contributions for better clarity.”^{90, 99} So the protocol’s steward is a charity a few hundred thousand dollars short: its largest tier is the vendor’s, contributed in kind rather than paid for in cash; its largest paying member supplies half of its revenue; and the server at the centre of the network is operated under contract by that same vendor. The dependency is not concealed. It is itemised annually, in a PDF, by the people who depend on it — alongside the Foundation’s own verdict on the sector it serves: “Whilst the wider world realises that Matrix is needed, it hasn’t concretised into proper support to our work yet.”⁹⁰

In the same footer as the logo wall, Element also displays a Digital Public Goods Alliance badge, and the registry entry reads as the project’s own summary of itself. Element has been a verified digital public good since 9 June 2026, last evaluated on the same date; the named owner is “Element Creations Ltd”, a private company; the licence presented as the open one is AGPL-3.0 (the GNU Affero General Public License, version 3.0); and the “organisations using it” field is a self-reported, annually updated list beginning Australia, Austria, Belgium, Canada, Croatia, Estonia, Finland, France, Germany, Greece, Italy, Luxembourg, Netherlands.⁹¹ The SDG (Sustainable Development Goals) justifications, also self-reported, are about sovereignty: governments and organisations can “build and operate sovereign communication infrastructure using open-source software and open standards, without dependence on proprietary vendors”, protected against “vendor lock-in.” The platform-independence section, by contrast, is blunt: Scalar, a proprietary integration manager for bots, bridges and widgets, and Firebase Cloud Messaging for push.⁹¹ A verified public good is a fair description of the AGPL clients. It is an odd thing to hang on the same site as a NATO emblem — and the registry’s roster of government users is the closest thing to a public list of the deployments the vendor says it cannot cite.

The two deployments with the most published detail behind them also have the two public incident histories, and the record deserves to be read in the project’s favour where it earns it. Tchap launched on 18 April 2019. Within hours, a researcher registered an account that the system recorded as belonging to the Élysée, because the signup path validated one address and mailed the confirmation to another. The Foundation’s own note that day records that sydent “uses python’s email.utils.parseaddr function to parse the input email address before sending validation mail to it, but it turns out that if you hand parseaddr an malformed email address of form […]@c.com, it silently discards the @c.com prefix without error”, so a token requested for one address would be delivered elsewhere while “the address […]@important.com would be marked as validated.”⁹³ The fix shipped the same day, the explanation was published rather than buried, and the project confirmed to the press that “there was no security audit on their solution.”⁹² That is how a maintainer behaves, and it should be recorded as such. It is also a launch-day authentication bypass in the flagship government deployment of a protocol sold on the strength of its identity guarantees — the one property a Matrix account is welded to, and the subject of 1.1 and 2.1. It happened again seven years later, differently, and this time the French state had spent the interval expanding the platform: a circular under Prime Minister Bayrou called for Tchap to be generalised across government in July 2025, and the Dinum (France’s interministerial digital directorate) had launched a bug bounty with YesWeHack six months before that.⁹⁵ Then on 7 June 2026 ANSSI (France’s national information-security agency) detected a compromise, which DINUM attributed to “l’usurpation de compte” — the hijacking of a legitimate user account, apparently in the education ministry’s environment — rather than to any vulnerability in the platform, the protocol or the Matrix infrastructure.⁹⁵ Officials said the reachable material was the open forums available to every authenticated user; an attacker claims roughly 13.5GB downloaded, 643,000 messages and 73,000 accounts, and none of the big numbers are confirmed.⁹⁴ The CNIL (France’s data-protection regulator) was notified and the log analysis was still running at the time of writing. The 2026 incident is an identity failure rather than a cryptographic one, and the encryption held, which is the vendor’s whole argument for the product. But note what the two share. In both, what broke was the binding between a human being and an account — the one guarantee the rest of the protocol is built on, and the one guarantee a logo cannot supply.

The counterpoint deserves to be stated at full strength, because a section like this that only argues one way is not an argument. Nothing here shows that a single military deployment has been compromised, that any of these customers is dishonest, or that Element has done anything wrong in the ordinary sense. The Tchap flaw was disclosed by the project, explained technically within a day and fixed within hours; the 2026 incident was a credential compromise the operator reported itself, to its regulator, before anyone else wrote it up. Governments choosing to run a stack inside their own accreditation boundary is a legitimate sovereignty decision, and Element’s account of the FedRAMP exemption is that it removes a procurement barrier rather than a security control. The Foundation’s independence is real in the ways it can be: its own board, its own elections, its own chief executive — who in 2024 was glad to announce that “[t]he Foundation now runs entirely independently” — and a Silver tier that doubled in a year, even if that doubling bought only 30% more revenue.^{89, 90} Venture funding is not a moral failing. A non-profit asking governments to pay for maintenance is not extortion; it is the model that serious proposals for funding critical infrastructure keep converging on, and on that point the Foundation’s argument is better than most of what is written about open-source sustainability.

Which leaves the honest form of the charge, which is far narrower than the one the marketing invites and does not need the rhetoric. It is not that Element sells to NATO — that is a business, and a legitimate one. It is that the trust claim is load-bearing for that business, and load-bearing for a protocol whose specification is written by a separate legal entity that the same company funds, employs, houses, and is currently the largest member of. Every claim on the wall is a claim about somebody else’s security posture, and not one of them is a claim the vendor can make about its own funding. The charitable sector sits on the other side of that wall, in a deficit, and its largest prospective donors are the ones who declined to fund it — not out of malice, but because, in the words of a procurement department that understands its own job exactly, a donation is not a procurement category. Matrix’s most security-conscious users turn out to be the ones whose money has the shortest path to a sales contract, and the ones with the least claim on the protocol are the ones it was built for.

The question a community should ask is not whether NATO uses Matrix. It is who pays when NATO’s procurement department declines, and whether the protocol survives the answer. On the evidence above, it does not have a payer.

4.5 Interoperability is a marketing word

The promise of interoperability with IRC, XMPP (Extensible Messaging and Presence Protocol), and Discord is the central pillar of Matrix’s value proposition. Yet on the ground: bridge quality is inconsistent, most bridges are experimental, and the protocol’s own “interoperable” component (the application-service framework for bridges) is where a huge amount of the experimental, unstable machinery lives. When a room is “bridged” to IRC, the two halves experience different rooms with different guarantees. Calling a system that requires every community to run third-party bridge daemons, each with their own quirks and their own security posture, “interoperable” is generous to the point of fiction.

#Chapter FiveEvery client is broken, and it cannot be fixed

5.1 The client is where the protocol’s failures concentrate

Everything a Matrix user actually touches is the client. The protocol is an abstraction, the homeserver is somebody else’s server — the client is the one piece that sits on your computer or in your pocket and renders your rooms, your encryption, your identity. It is therefore the natural place to look for the health of the network, and it is, by near-universal experience, in dramatic ruins.

The standard excuse, offered constantly in Matrix’s own developer channels, is a version of “the protocol is fine; the clients are catching up.” This gets the causality exactly backwards. Clients are not broken because their authors are incompetent; they are broken because the protocol requires every client to be a full-state replica of a system that is, by design, permitted to disagree with itself. No client code can repair that.

5.2 Element: the reference client is a monument to bloat

The closest thing Matrix has to a reference client is Element. Element Web is an Electron application wrapped around a React SDK^{15, 16} — software that loads like an operating system in order to display what is, at bottom, a chat window. It is infamous, in the way the reference homeserver Synapse is infamous, for its resource profile: a handful of matrix-aligned channels will comfortably consume more memory than the entire IRC client-plus-bouncer stack it replaced.

What makes Element Web remarkable as evidence is that its own authors have now gone on the record about why. Element presented its own history at FOSDEM in February 2026, and the retrospective is not a victory lap. The first Element Web, launched in 2015 alongside the Matrix JS SDK, was, in the presenters’ words, “small, simple, and lightning fast — switching between rooms felt instantaneous.” It also came with, in the very next sentence, “trade-offs: features like end-to-end encryption, Spaces, and other core Matrix functionality weren’t yet in place.”⁴⁷

The flagship client of the world’s most federated chat network was fast before it was encrypted, and has been slow and structurally incoherent in every particular since the security features were bolted on.

Read that pairing again, because it is the shape of the entire project. Matrix took a small, fast, boring chat client, attached a state-of-the-art end-to-end encryption scheme to it, and has been paying the latency and complexity bill ever since — in every client, on every platform, for eleven years. The encryption was never free, and it was never going to be free, because crypto in a federated group system is not a feature toggle; it is a second, permanent, stateful, per-device, per-room, per-session protocol that must be re-implemented, kept in sync, and re-verified by hand, forever. The vendor says as much when it explains the roadmap.

As the platform grew, so did the complexity and the technical debt, Element concedes: the shared SDK that was meant to be “a reusable foundation for any Matrix app” “became tightly coupled and increasingly difficult to maintain,” and “business logic often lived inside UI components,” making updates hard as React evolved.⁴⁷ A client whose state logic is welded into its buttons cannot be made fast without being dismantled, and Element’s own engineers have publicly concluded that a rewrite is the only way out. The Rust SDK, which already powers the Element X mobile apps and which the same presentation describes as delivering “dramatically improved performance and memory efficiency,” is described for the web as a “key part of our long-term plan,” to be integrated via WebAssembly, with the current roadmap items listed as a move to MVVM (model–view–viewmodel) and a future “Rust-SDK under WASM” (WebAssembly).^{47, 48} As of early 2026, eleven years after launch, the flagship desktop client of Matrix still does not have the core that its own phone app has. The rewrite is not late. It is the plan.

Element also defines the ceiling for “finished.” Its SDK repositories carry a backlog of open issues that is itself a genre; its feature matrix across Web, iOS, Android, and the Element X rewrite is a month-by-month confession of a team that cannot be in four places at once — while the protocol keeps moving under all four of them. Element is not a client that someone finished and shipped. It is a barge permanently under construction, and every room in the network is being kept afloat by a deck that was never finished.

5.3 The lag is measurable, because Element published the numbers

“Laggy” is not a matter of taste, and the vendor has been obligingly specific. In its own Element X Web presentation, Element lists what the Rust SDK buys the clients that have it: “instant login, launch, sync,” and a “15x memory improvement” — from 1.4GB to 90MB of heap.⁴⁸ Fifteen times. That is not a tuning pass, a cache policy, or a lazy-loading exercise. That is the gap between the client that exists and the client that was supposed to exist, measured by the people who own both, and published on a stage.

The marketing copy makes the same point without the numbers. Element X is promoted on the promise of “instant sync, instant login and instant launch — never stare at a launch spinner ever again!”⁵³ Read that as a specification of the old product. The headline benefit of the new client is the absence of the old client’s defining behavior. When a vendor’s primary selling point is that you will no longer wait for the thing you already use every day, then the waiting was the product, and it was the product for years.

The latency is not confined to the client. It is in the sync layer, and the engineers who own that layer say so plainly. “Matrix previous synchronisation mechanism is slow and inefficient,” wrote Ivan Enderlin of the Matrix Rust SDK team, describing why sliding sync was built at all.⁴⁹ The measurements in the reference implementation’s own tracker are correspondingly grim: initial sync requests observed taking 36 seconds to arrive, and still taking roughly five seconds to execute after a two-hour period offline, over payloads measured in hundreds of kilobytes.⁵⁰ And the mechanism that was supposed to make this disappear needed, in the end, a proxy service — a program that sits in front of your homeserver — which by the Rust team’s own account was buggy and slow enough to be dismantled, prompting a further simplification of the proposal, a second protocol number, and a November 2024 shutdown in which users were told to expect a forced logout with no recourse.^{49, 46}

Three observations follow, and none of them are subtle. First, the improvement was real: sliding sync is now, in the same announcement, celebrated for working “linearly whether the user has 10 or 10’000 rooms”⁴⁹ — which is a compliment to the new mechanism and an indictment of the old one, because linearity is the bare minimum you expect from a system that claims to federate at scale. Second, all of that work landed in the newest client, on top of the moving spec, which is precisely the treadmill described in the next section. Third, and most damningly, the crypto was never solved along the way: the same conference featured a dedicated talk, “Unable to Decrypt This Message,” whose stated purpose was to explain to the ecosystem why users see that error, and whose own summary concedes how hard it is, or was, to provide reliable end-to-end encryption across a federated network.⁴⁹ A protocol holds a conference track on its own flagship error message. That is the state of the thing.

How long the “next sync mechanism” took to exist

The lag has a timeline, and the timeline is the argument. The fix for Matrix’s sync problem was first proposed as MSC3575, opened on 20 December 2021.¹¹ It was never merged. It was closed, unaccepted, in its original form. Its simplified replacement, MSC4186, was not filed until 30 August 2024 — thirty-two months later — and native sliding sync only reached shipping clients that autumn, in Element X.^{13, 53} For the simplified proposal itself, the wait was even longer: MSC4186 was merged into the specification in June 2026.¹³

Do the arithmetic honestly, because it is worse than it first appears. Matrix shipped its first client in 2015.⁴⁷ The sync mechanism that client needed was proposed in December 2021.¹¹ A workable design was proposed in August 2024,¹³ and that design entered the specification in June 2026.¹³ In other words: for the entire life of the project, every Element client that shipped before 2024 ran on the long-poll loop that Element’s own engineers call “slow and inefficient”⁴⁹ — Element Web, Element Desktop, and the long-lived mobile apps, for a decade. The people who lived with it were told, correctly, that a fix was coming. The fix arrived after the protocol had already celebrated its tenth anniversary, in a different client, on the basis of a different proposal — and the ecosystem was then forced off the intermediary onto it, by an announced shutdown date, with no recourse for the users it caught.⁴⁶

Two precisions, because this claim is easy to overstate and a document that overstates it deserves the criticism it levels at everyone else. Element X is the exception, and it is a genuine exception: the project’s own directory now grades Element X Stable and describes it as the mobile client “with native OIDC, sliding sync and Matrix RTC for calls” — OpenID Connect authentication, and Matrix’s own real-time-communication stack for calls.⁷³ So the defensible form of the claim is not that no client has sliding sync. It is that every client with sliding sync is younger than the protocol, while the clients older than the protocol will never have it — Element Web and Element Desktop remain on the old loop, and the mechanism reaches them only through a rewrite measured in years, not as an upgrade. And there is an order of events in that last sentence which is worse than the sentence admits. The proxy was shut down in November 2024, and the migration was compulsory.⁴⁶ The specification did not acquire the mechanism until June 2026.¹³ The ecosystem was compelled to move onto a design the specification did not yet contain, and then waited nineteen further months for the specification to ratify what its users were already running.

There is a sharper way to put the governance point, and it is the one that matters for the rest of this document. The sync problem was diagnosed in 2021, and the 2021 answer was rejected. The 2024 answer was not a refinement of the 2021 answer; it was a rewrite that removed most of its features, admitted in the project’s own summary that the intervening proxy implementation had been “really buggy and really slow,” and shipped anyway — which is not an engineering failure so much as an admission that the specification process is the bottleneck. Matrix could not converge on a sync design for three years while its users waited. A protocol whose mechanism for agreeing on mechanisms takes three years does not have a scaling problem. It has a governance problem wearing a scaling problem as a disguise.

Forty minutes to walk into a room

Then there is the number that users actually remember. Joining the flagship developer room on the flagship server — #matrix:matrix.org, a room with more than seven thousand members⁶⁶ — has been reported to take around forty minutes, and the mechanism is exactly what the architecture predicts. When you join a room, your homeserver must first resolve and synchronize that room’s entire state, and the community’s own operators documented the consequence years ago in plain language: joining the Matrix HQ room “takes a few minutes and then fails,” because “the home server has to sync the entire room state when you join the room.”⁶³

The forty-minute figure is not an outlier anecdote; it is the ordinary shape of the problem, and the issue trackers of the SDK, the server, and the client are full of measurements of the same magnitude. A user of the JavaScript SDK reported in 2019 that with thousands of rooms, connection “spends more than 40 minutes” while throwing a timeout warning every eighty seconds.⁶¹ A homeserver operator in 2022 documented a login on a server of roughly 1,500 rooms taking “about half an hour — 40 minutes”, with the Synapse logs showing individual /sync requests that never completed at all.⁶² An Element Web user in 2024 reported the client being unable to keep up with the network for “upwards of 30-40 minutes” because its own request storm was starving /sync of resources.⁶⁴

Set that beside what a user is actually promised — instant launch, a room list, a timeline — and the product becomes legible. The first act of joining a conversation in Matrix is a bulk data migration performed synchronously, in the foreground, over a federation link, with no progress bar, no cancellation, and no partial result. Forty minutes is not a bug report. It is the architecture’s headline number, arriving on schedule, in the room where Matrix developers hang out. The competition gets this for free. IRC clients joined channels in milliseconds because joining was a line of text. Matrix made joining a room a distributed-systems problem, and then shipped it to users without ceremony.

5.4 The sync-and-state treadmill: clients are eternally behind, by design

A Matrix client must, on every /sync response, ingest room state, track room versions, apply (or faithfully mirror) state resolution, manage power levels, and render a timeline that edits and redacts itself. Each of those subsystems is a moving target, and the Matrix Foundation’s answer to “clients disagree” has always been more specification rather than less: more MSCs, more room-version events, more “extensible events,” more feature powers, and now an entire competing sync mechanism (sliding sync, MSC3575)^{11, 12, 13} that the newest flagship client implements while the ecosystem at large does not.

The result is a permanent, structural lag. Whatever client you write today, the spec you wrote it against expires out from under you, and the next spec demands features that your room’s homeserver does not yet speak. The only way to end the treadmill is to freeze the protocol — to declare a version stable and stop adding to it — and that is precisely the one thing Matrix will not do, because its entire self-image is forward motion. A client problem that the protocol’s governance refuses even to restrain is not a fixable client problem.

5.5 Encryption makes every client’s bug a security bug

The heaviest client burden is cryptographic, and crypto is the least forgiving place for a bug. E2EE in Matrix is enforced by the client alone: key requests, cross-signing, the device-verification dance, re-keying, backup ⁹ — all of that logic lives in client SDKs,¹⁶ which means every client re-implements a subtly different version of a scheme that was itself bolted onto the spec after the fact.

Users experience this as the two most famous Matrix sentences: “couldn’t decrypt this message” and “why can’t I read my own history?”¹⁰ A room that reads cleanly on an up-to-date Element Web can refuse to decrypt on a smaller client that has not yet implemented the latest key-sharing behavior — not because anyone is attacking, but because two implementations of the same moving spec disagree. Independent security research has demonstrated how deep this goes: the attacks published at the 2023 IEEE Symposium on Security and Privacy succeeded against Element and multiple independent clients at once, because the exploitable flaws lived in shared protocol paths that every client inherits — exactly the class of defect no single client team can fix alone.²⁹ Here “not fixable” is literal: a client cannot decrypt a message whose keys it was procedurally never entitled to see, and the protocol provides no mechanism for the client to correct that. The best client in the world cannot un-break a room another client encrypted into staleness.

5.6 The client graveyard, and the “fix” that just adds another corpse

Because maintaining a Matrix client against the moving spec is a treadmill, the third-party client scene is a museum. Projects launch, promise parity, fall behind, and are archived; the list of Matrix clients has always been longer than the list of living ones. The survivors are either capitalized (Element), or minimal (Nheko, Fractal-style efforts)^{25, 26}, or forks of Element that inherit its bloat. Whenever the ecosystem answers “the clients are broken” with “write a new client,” the result is one more partially finished client, one more sync scheme, one more set of users who cannot see the same room the same way.

Compare IRC and XMPP once more. IRC clients written in the 1990s still honor the wire protocol today, because it is stable and boring. XMPP clients interoperate because the core stanza format is stable enough that a competent developer can implement it in a weekend. Matrix clients can do neither of those things, because there is no stable, small, complete core a single developer can carry in their head — the spec is a living ecosystem of its own, and every client is a miniature re-implementation of an unstable federation. The “fix” for broken Matrix clients is not another client. It is another protocol. And that is a confession, not a solution.

5.7 The rewrite is the fourth client, not the first

Element X deserves to be read for what it is: not a fix, but a fork. The “next-generation” line is now Element Web (legacy JavaScript), Element X on iOS and Android (Rust), Element X Web under its new name, Element Pro, plus a growing shelf of modules and embedded components that each vendor maintains separately.⁴⁸ The user who complains that Matrix clients are broken, inconsistent, and mutually incompatible is describing an ecosystem that Element’s own product line now embodies. When the flagship vendor answers an architecture problem with a second client, the ecosystem does not get one good client; it gets one more implementation, one more crypto stack, one more sync configuration, and one more set of rooms that the previous client renders differently.

Worse, the rewrite is not a fixed point. The Rust SDK is itself a moving target, tracking a spec that is still moving, and the Element Web strategy is explicitly to “evolve it piece by piece” rather than rewrite from scratch — a decision the company itself calls the prudent one, since a from-scratch rewrite “would be risky and disruptive.”⁴⁷ It is the right call, and it is also the confession: the only safe way to modernize a client whose architecture is fused to its UI is to keep the broken one in production for years while the replacement is assembled around it. The strategy is correct precisely because it admits the failure.

And the destination is not a smaller surface. The new architecture’s own design notes list as objectives understanding “today’s state of the product and UX debt” and prioritizing stability, resilience, and performance — a design team’s inventory of the damage, presented publicly, of the reference client.⁴⁸ Element is not shipping a fix for the lag. It is documenting the debt in a conference deck and scheduling the repayment for an unspecified future, one MVVM refactor at a time.

5.8 The mirror is broken by construction

The client is the mirror the network holds up to itself. When the mirror shows a blurry, split, half-encrypted face, the temptation is to polish the mirror — yet another client, shinier, faster, newer. The polish never takes, because the reflection is not a property of any client; it is a property of the thing being reflected. The bugs that plague Matrix clients live in the agreements between servers, in a spec that refuses to sit still, and in an encryption layer that trusts a client the spec will not finish defining. A mirror cannot fix reality. Matrix clients are broken not because their authors are careless, but because their protocol is — and no client ever written can repair the very thing it is required to replicate.

The day someone “fixes” Matrix clients is the day they have invented a different protocol. That is not a milestone Matrix can reach while remaining Matrix.

5.9 The terminal is empty, and it is empty for a reason

There is one corner of the client ecosystem where Matrix’s cost model is visible all at once, and it is the corner a lot of this document’s readers live in: the terminal. Not a niche, not a preference — the place where chat happens over SSH, on a remote host, inside tmux, on a link too slow for a browser tab. It is worth asking what Matrix offers there, because the answer is more revealing than any individual client bug in 5.2 or 5.3.

Start with the specification, which is more generous than the ecosystem. The Client-Server API opens by describing a protocol designed to support both kinds of client: “lightweight clients which store no state and lazy-load data from the server as required” and heavyweight ones that keep a full local copy of the event graph.⁸ A stateless, lazy-loading client is not an afterthought in that sentence. It is half the design brief, and a terminal client is the obvious candidate.

Now open the project’s own client directory and count.⁷³ The “Featured clients” list — billed as “a selection of the most mature ones you can safely use” — contains Element Web/Desktop (Stable), Element X (Stable), Cinny (Stable), and Nheko (Beta), among others. There is no terminal client in it. In the full directory, the interactive terminal chat clients are gomuks, listed Beta, and iamb, also listed Beta.^{74, 75} The only terminal-class entries carrying a Stable label are matrix-commander and matrix-commander-rs, which the directory describes as “simple but convenient CLI-based Matrix client app for sending and receiving” — command-line tools for sending and receiving, not chat clients with a timeline, threads, or key management. The terminal-class entries marked Obsolete include Miitrix, a proof-of-concept client for the Nintendo 3DS whose terminal-based user interface is, in the directory’s own words, “implemented with printf,” alongside Syphon, gotktrix, and Quadrix.

So the honest summary is not that nobody has written a terminal Matrix client. Several people have. It is that the project does not rank a single one of them as mature, and every one of them is somebody’s spare-time project. The maintenance record makes the point sharper rather than softer. iamb was created in August 2021 and, after five years of active development, its latest release is v0.0.12 — a project that has never reached 1.0.⁷⁴ matui, self-described as “a very opinionated Matrix TUI” — that is, a terminal user interface — reached its own v1.0.2 only in September 2026, three and a half years after it started, with 125 GitHub stars.⁷⁶ gomuks is the healthiest of the three by any measure — popular, actively developed — and the project’s own directory still grades it Beta.⁷⁵

The most interesting case is WeeChat, because WeeChat is IRC’s reference terminal client and the natural home for exactly this use case. Its Matrix plugin exists, and its history is a compressed version of the whole chapter. The Python original stopped taking commits in July 2023 and its own README states that development has moved to a Rust rewrite and that the project “is in maintenance mode and will likely not be receiving substantial new features.”⁷⁷ The rewrite is alive and is the best-maintained Matrix terminal code in existence.⁷⁸ In other words: the most credible terminal path into Matrix runs through a plugin for a different protocol’s client, written and rewritten by one third party, with no Matrix Foundation involvement at all.

That last point is the one to sit with, because of what it mirrors. In 1.3 this document noted that Synapse’s performance is bad enough that the Foundation funded not one but two alternative homeservers, Conduit and Dendrite, on the reasoning that the reference implementation had to be replaced to be usable at scale. The identical argument applied to the client side has never been made. There is no funded terminal client, no funded lightweight client, and no second independent desktop client; the one rewrite the project did fund, Element X, came from the same company that ships the flagship (5.7). The Foundation will pay to replace a slow server. It will not pay to make the protocol pleasant to use over SSH. And the one server it did pay for has since passed through three volunteer-maintained generations, each breaking the previous one’s migration path (1.3) — so even the funded answer to “Synapse is too slow” has not proven durable, while the terminal client has no funder to abandon in the first place.

Why the terminal is where the architecture shows

This is not a story about a neglected niche. It is the point at which three earlier chapters intersect, and it is worth naming them precisely.

The sync tax lands hardest on the user least able to pay it. The WeeChat plugin’s own installation guide tells the user what to expect on a first connection: “The first connection can take a few minutes while the client syncs the account.”⁷⁸ That is 1.2 and 5.4 arriving exactly where they were always going to arrive. A browser client can spend forty seconds loading and be forgiven, because you were going to be staring at a page anyway. A terminal user is on a remote host, often over SSH, quite possibly on a slow or metered link, and very often inside a tmux session that other work depends on — and the first thing the protocol asks is a multi-minute blocking operation before a single character can be typed. The architectural decision that makes big rooms take forty minutes to join (5.3) is the same decision that makes the terminal client a bad idea. They are not two findings. They are one finding, observed from two ends.

The spec’s two client targets are mutually exclusive, and the project picked one. The specification asks for clients that “store no state.” Chapter Six established what a Matrix client must actually hold: cross-signing identities, device keys, a key backup, a passphrase, secret storage, and megolm sessions — six coupled credential systems whose reset procedure is order-dependent and non-atomic, and whose failure mode is permanent loss of the user’s own history. A client that stores nothing cannot hold keys. A client that holds keys is not lightweight. The two clients the specification promises to support are not two clients, and the project resolved the contradiction the way it has resolved every other one in this document: by surrendering a property. It made the machinery invisible (6.6) rather than optional, and the lightweight client — the one the terminal needed — was the thing left unfunded. That is not an accident of budgeting. It is the same trade, in a different room, made by the same logic.

Every feature the client must reimplement is a client-side rendering rule. Chapter Seven established that edits, redactions, reactions, and threads are relations and aggregations, interpreted by whichever client receives them. A terminal client must reproduce the flagship client’s interpretation of all of them, or rooms will read differently for different people — which, as 7.5 argued, is precisely the failure mode that makes a conversation untrustworthy. There is no conformance suite that settles whether a terminal client is rendering a thread correctly, because there is no conformance suite for any of this. The client surface is the part of Matrix with the most accumulated behaviour and the least shared definition of correct, and it is unsurprising that the volunteers who show up to write clients are the ones with the least appetite for reimplementing an Electron app’s opinions about a timeline.

Which is the sharpest form of this document’s conclusion, and it is worth stating as an operating rule rather than a slogan. On IRC, the properties a sysadmin relies on — a line protocol, a small state model, text on a wire, a client that stores nothing and a bouncer that stores everything — are legible in the ecosystem. You can see them in the client list. On Matrix, the same properties are claimed in the specification’s preamble and absent from the client list, because the protocol’s design has moved on to things a terminal client cannot express: a credential ceremony, a state-resolution algorithm, an editable timeline, and a full sync of every room you have ever joined. The terminal is not where Matrix is underserved. It is where Matrix is legible, and what is legible is not a chat client — it is a browser tab and a server that will hold every message you have ever read.

#Chapter SixThe security picture is worse than advertised

6.1 The flagship server has been breached before

Let’s start with the loudest data point, and it is one the Matrix team itself disclosed. In April 2019, the matrix.org homeserver was broken into through the team’s production Jenkins instance, and the intruder gained access to the production databases — the store holding identities, rooms, unencrypted message content, access tokens, and password hashes — as well as the GPG (GNU Privacy Guard) keys used to sign matrix.org packages.²² The keystone server of the entire network, the one the “decentralized” story points to as one node among equals, proved to be one misconfigured build box away from wholesale account disclosure.

The 2019 breach was not a relic of old infrastructure. In September 2021, Matrix disclosed CVE-2021-40823 and CVE-2021-40824: an end-to-end encryption flaw in which a malicious homeserver could silently gain access to a room’s keys in Element Web, Element Android, and multiple independent clients sharing the same code path — including Nheko, FluffyChat, and Cinny.¹⁰ A room-key theft that fully defeats client-side encryption, present across so many independent implementations at once, was itself read by the Matrix team as a signal that the spec’s wording around key sharing was insufficient. And the supply-chain vector in play in 2019 remains a live, documented hazard for exactly the Python/Node developer population in which Matrix is built and on which its package updates ride: typosquatted packages with real-world installation counts keep shipping commodity cryptominers and worse from the public registries.²⁴ The attack surface never moved; only the specific boxes behind it have.

The deeper lesson is structural, not about that one bug: Matrix’s homeserver stack is a Python/Linux constellation where the blast radius of any one package, plugin, or bridge is the server — and with the server, every account it hosts, every room it holds, every bridge it runs. A federation whose lynchpins are a handful of servers is a federation whose intrusion story is “hack the server, get the network.”

6.2 Encryption leaks metadata everywhere

Matrix’s E2EE (olm/megolm)⁹ encrypts the message body of room events, and nothing else. The homeserver still sees:

• Who is communicating with whom (the full event graph of every room).
• Room membership, membership changes, and every power-level mutation in cleartext.
• When users are online, when they read, when they send typing pings — all as plaintext metadata.
• The structure of conversations — message counts, intervals, response times — available to correlation attacks.

In other words, the server operator — the entity the entire decentralization story exists to protect you from — retains a complete graph of your communication. That is not what most people mean by end-to-end encryption. An E2EE protocol in which the network operator sees the entire social graph is metadata-insecure. The forensic literature documents this empirically: a peer-reviewed forensic analysis of the Synapse homeserver recovered extensive user activity patterns, device-management records, media metadata, and communication metadata from homeserver databases and system logs despite end-to-end encryption being active.³² What the encryption layer hides is the body of the message; what it leaves exposed is everything that makes a network graph.

6.3 Forward secrecy was “disabled,” then compromised

The megolm ratchet used in rooms⁹ does not have the fine-grained forward secrecy of Signal’s ratchet. When a room’s megolm session key is exposed (a device leak, a backup restored, a compromised device), an attacker who recorded ciphertext can, with the session key, decrypt all past messages in that session. The spec’s answer is periodic key rotation (re-keying), but that schedule is coarse, and in practice session keys are shared with every device in the room at joining, meaning anyone who ever legitimately had room access in the window has the material to decrypt that window’s history. Signal’s per-message ratchet forward secrecy doesn’t exist in Matrix rooms. That is a meaningful gap, and it’s baked into the design.

Formal cryptanalysis agrees, in print. The first formal security analysis of Matrix’s cryptographic core, published at the IEEE Symposium on Security and Privacy, concluded that Matrix’s state-sharing functionality — history sharing and account recovery — is in direct conflict with the standard cryptographic notions of forward secrecy and post-compromise security.³⁰ A computer-verified (mechanized) analysis confirmed that compromising a megolm session reveals the ratchet key inside it, allowing decryption of every message sent in that session afterward, and that megolm’s post-compromise security is provably weaker than the Sender Keys scheme used by Signal group messaging.³³ The original industry audit of libolm by NCC Group reached the same conclusion as far back as 2016.³⁴ Every independent examination — two academic, one industrial — finds the same structural gap.

6.4 Key verification is opt-in and trust-on-first-use

Matrix’s E2EE (end-to-end encryption) defaults to trusting a device key on first sight — trust on first use, TOFU.⁹ The “verify this device” flow — the emoji/QR existing-key comparison — is optional, confusing to users, and silently skipped by most. As a result, room-wide encryption provides a false sense of confidentiality: in most sessions nobody has actually verified the other end, so man-in-the-middle (MITM) interlocutors (a malicious homeserver injecting its own key for an avatar) are detected only by users who know to look at the security shield and actually do it. This is not theoretical. The researchers behind the 2023 IEEE S&P paper turned this exact trust design into working attacks: a malicious homeserver injects its own device keys into a room, and because verification remains opt-in, the attacks succeeded against Element and across independent clients that had never been configured to verify anything. Their published verdict is that, as deployed, Matrix provided “neither authentication nor confidentiality” against an actively hostile server.²⁹ Against every norm of modern secure messaging (Signal, WhatsApp make verification the explicit, deliberate act; Matrix makes it a checkbox buried in settings) Matrix’s is worse.

Meanwhile key handling is a UX minefield: users who lose a device lose read access to history (until refreshing), and when a device stops being online, messages can hang in “queued encrypted” limbo. The volume of “couldn’t decrypt” complaints across the network is exhaustively documented — the trackers for that specific failure have become a genre of their own. Every Matrix community has members asking “why can’t I see messages on my phone?” as a way of life.

6.5 Cross-signing recovery is a maze with unrecoverable dead ends

The previous section is about trust. This one is about the moment trust is demanded of an actual human being, which is where Matrix’s encryption stops being a protocol and becomes an unusable product. Consider the single most common catastrophe in anyone’s digital life: you lose your computer. It is stolen, or the disk dies, or you reinstall the OS, or you are handed a new laptop at work. You reinstall Element, you log in, and you try to get your account back.

This is not an edge case, and it is not hypothetical. It is documented, in the reference client’s own tracker, in the reporter’s own words:⁵¹

“I’ve just had to wipe my entire computer due to some OS corruption. I got Element back, and tried verifying my application-launched session. I open another session in browser. Matched the emojis. It then asks for my security key, on both sessions. I had previously reset my security key and downloaded a new one. I click ‘upload’ and click on the Security Key that I downloaded. Wrong Security Key. What? What do you mean ‘Wrong security key’? This is the ONLY Security Key I have! I literally just reset it! … If I AM doing something wrong, Element absolutely sucks at communicating it!”

Now read the diagnosis, from the maintainer who diagnosed it: “if you reset the security key, your cross-signing keys are still guarded by previous security key unless you also reset them as well. So, it’s trying to ask you for the previous key that you don’t have (presumably that’s why you reset it).”⁵¹ The interface was asking the user to produce a secret they had deliberately destroyed, in a dialog with no explanation of why the request was impossible, because the product has no state that distinguishes “this account’s identity was reset without its cross-signing identity” from any other broken account. It is a modal, a keypress, and a message that says “wrong key.” The state space of Matrix key management is larger than the vocabulary its interface has for describing it.

And the recovery is not a button. The procedure that maintainers actually give is a numbered ritual that only works in one order: export your room keys from a surviving session; log in and skip verification prompts; reset secure backup first; then reset cross-signing keys, which will now prompt you for the new key you just made; then go to every other session and either verify it or press setup on Secure Backup, entering the new key there too.⁵¹ That is an order-dependent, multi-session, cross-device migration procedure for a credential, delivered in prose in a support thread. It is not a user interface. It is a support ticket with extra steps and a real chance of permanent data loss if you get the order wrong.

The frequency is documented too, by the maintainers themselves, and it is the most damning number in this chapter. On the same thread, a second Element maintainer: “This is a chronic issue. Here’s some of the filed issues I could find: #16118 #16073 #16263 #16243 #16455 #16849 #16879 #16755 which doesn’t include the dozen or so times I’ve helped people deal with this in chat.”⁵¹ Eight filed issues in a tracker with thousands open, plus an uncounted number of humans quietly rescued in support chat. That is the true operational state of Matrix key recovery: a human-in-the-loop service, staffed by the project’s own overworked maintainers, that exists because the product cannot do it. The protocol is not failing here. The client is failing, and it has been failing in the same way, in the same place, for years.

Nor are the flows themselves sound, even when attempted. The “Reset cross signing” control in the desktop client asks the user to type their security phrase — three times, in a row.⁵² And the underlying sequence is documented as non-atomic: the client resets the keys locally, then updates the secret store, then uploads the keys, so a user who mistypes a password or forgets a passphrase mid-flow ends up “in a broken state, with local secrets not uploaded to server.”⁵² Abort halfway and you have made things strictly worse: the previous identity is gone, the new one was never published, and the client can no longer decrypt anything. An operation that can leave your account cryptographically bricked if you lose concentration is not a security feature; it is a hazard with a green checkmark.

This is the load-bearing wall, and it is worth being precise about which wall it is. Not the ratchet, which is defensible. Not the wire format, which is fine. The load-bearing wall of Matrix end-to-end encryption is a two-button, order-sensitive, non-atomic, self-inflicted recovery ritual in the reference client, whose failure mode is permanent loss of your own history. Cryptographers designed the scheme. A dialog box shipped it.

6.6 The fix was to make the encryption invisible, which is the admission

Having concluded that the verification ceremony is unusably confusing for ordinary humans, Element did not simplify the ceremony. It removed the requirement to perform it, and it hid the machinery. The company’s own summary of the next-generation client credits the Rust SDK and what it calls the “Invisible Encryption initiative” with delivering “radically improved encryption UX” and “radically improved encryption performance.”^{53, 54}

The design goal is stated without disguise, and the price is stated with it. To get into your own account on a new device, Element X asks you to confirm you are the rightful owner — and if you cannot: “If you can’t verify, you’ll have to reset your encryption (which will delete any message keys backed up on the server) — but going forwards, this will ensure that encryption is genuinely invisible and friction-free, and avoid confusing warnings about ‘unverified devices’.”⁵³

So the shipped resolution of “our key recovery is unusably confusing” is: make the key system invisible, and make the user’s failure to complete it cost them their message history. The ceremony was not made easier. It was made optional, and its failure mode was made deletion. A security control that only works reliably for people willing to lose their own history is not a security control; it is a warning label with a countdown.

The same vendor, describing the same feature, supplies the metric: the rewrite “has simplified verification and almost eliminated ‘unable to decrypt’ errors thanks to a new common cryptographic library written in Rust.”⁵⁴ Element’s own measure of cryptographic success is the disappearance of the error message. A system whose headline achievement is that users no longer see “Unable to decrypt this message” is a system in which users were seeing it — constantly, across every federated network, for the entire preceding decade. Chapter Five already noted the conference track devoted to that error. Here is the corroboration from the other direction: the fix for it was to stop showing it to you.

This is not a vendor that failed at usability research. It is a vendor that concluded the usability failed and chose concealment instead. And concealment is the one intervention the peer-reviewed HCI literature on this exact subject says does not work:

• Users never grasp what the encryption does. A quantitative survey of 125 respondents — the large majority of whom already used end-to-end encrypted tools — found only 12% could confidently explain what E2E encryption is, that three-quarters believed their encrypted communications could be accessed by unauthorized entities anyway, and that half believed SMS and landline calls were as secure as or more secure than the encrypted channel.⁵⁵ Hide the indicator, and the user has no way whatsoever to know whether the protection is on.
• Users understand confidentiality and never understand authenticity. Qualitative interviews found participants inferred E2E’s properties mostly from pre-existing beliefs about providers rather than from the interface; explanatory metaphors measurably improved grasp of confidentiality but “did not correct misconceptions about authenticity,” leading the authors to recommend interventions aimed at changing mental models rather than more explanation.⁵⁶ Authenticity — is this person actually who they claim to be — is the one property cross-signing exists to provide, and the one property users demonstrably never acquire.
• Key management is where E2EE usability collapses, and the trust dialog is where it confuses. In a peer-reviewed usability study combining a 50-participant survey with task-based testing of 12 participants, the overwhelming majority of identified problems were in key management — generating, importing, retrieving, and transferring keys, especially to a phone. One participant “did not understand why such handshake is necessary and what to do with the trust words shown on the graphical user interface during the handshake procedure.” Only one of the twelve participants actually knew and used PGP (Pretty Good Privacy) at all.⁵⁷ The “trust words on the graphical user interface” is the verification dialog. Matrix has hidden the one screen that this research says users cannot operate.

So the honest accounting of Matrix’s crypto is not that it is broken mathematics. The mathematics is respectable, and where it is weak the peer-reviewed record says so plainly (6.3). The accounting is that it is unusable to humans, in three compounding ways. The state space is too large to hold in your head: cross-signing identities, device identities, security keys, passphrases, key backup, and secret storage are six coupled credential systems with a reset flow whose order matters. The recovery paths are order-dependent, non-atomic, and human-supported. And the vendor’s chosen remedy for all of this is to remove the evidence from view, which does not remove the requirement — it converts a legible failure into an invisible one and then charges the user for it in lost history. Every ordinary person who has ever been confused by Matrix encryption has been failed by this design, and the design chose not to tell them.

6.7 User safety “improvements” undermine the model

To make E2EE usable at all, Matrix built in room key backup (“server-side key backup,” recovery code, passphrase)^{8, 9} — which fundamentally reintroduces a server-side store of the keys, a store the server operator can reach if they hold the recovery passphrase — or, far more often, simply because the user trusted them with it. The more Matrix makes encryption usable by centralizing key storage, the closer it comes to undoing itself: it is encrypting in a way that a server compromise can reverse. Layering “secure backup” on top of megolm means the place where the security guarantee actually lives is, once again, the same small cluster of homeserver infrastructure — exactly the place the security promise said we did not have to trust. The peer-reviewed record has flagged the same fragility: the 2026 forensic analysis of the Matrix stack explicitly catalogues theoretical IND-CCA breaks in the encryption schemes protecting key backups and secret sharing — the very machinery this “recovery” feature rests on.³²

6.8 Bridge compromise = total identity compromise

The IRC bridge ghost problem from Chapter Three is also a security problem. Every ghost — the bridge’s synthetic IRC identities on the matrix side and the matrix-side authentication of IRC users — is a piece of identity material that exists only on the bridge’s host. Compromise the bridge box, and you can impersonate, on Matrix, every IRC user who ever sent a message through that bridge; on IRC, every Matrix user who ever wrote. The bridge is the perfect single point of attack in the entire construct: all the identities of two protocols, collated in one place, with one operator’s security posture determining both sides’ safety.

6.9 Moderation surfaces are also security surfaces

Since moderation in Matrix is room-level, an attacker who gains admin anywhere gains the “admin” tooling of the room: kicking members (which, with E2EE, can lock them out of future-encrypted history), banning, and redacting — which does not remove history from federated copies. Redaction, notably, only clears a field on the event object; the ciphertext blocks themselves (for an encryption-enabled room) remain in the room’s event graph, in every federated copy, forever — a distinction the project’s own engineers were careful to draw when choosing the word “redact” over “delete,” on the grounds that users would otherwise assume a confidentiality guarantee the operation does not provide.⁷² If you intended to scrub a secret from an E2EE room, you cannot — the very event that contained it is still distributed. That asymmetry — “redaction conspicuous but not erasure” — is a security foot-gun, and it is fundamental to the protocol’s design.

6.10 The published record vs. the marketing record

None of the claims above is anecdote. The independent, externally reviewed record is now substantial and consistent:

• Centralization was measured. A peer-reviewed crawl of the public federation, published at ACM Middleware, found the network “imbalanced” and mostly centralized despite its decentralization goal.²⁸
• State consistency is formally hazardous. An analysis of the event-graph replicated data type published in IEEE Access documents the convergence and consistency challenges of the room-state model, independent of any operator’s choices.²⁷
• Encryption does not protect against the server. Two papers at the IEEE Symposium on Security and Privacy (2023, 2024) show that, as deployed, Matrix’s E2EE provides neither authentication nor confidentiality against an actively attacking homeserver, and that forward and post-compromise security are structurally absent from the state-sharing design.^{29, 30}
• Megolm is provably the weak link. A mechanized, computer-verified analysis confirms megolm’s post-compromise security is provably worse than the comparable Sender Keys scheme.³³
• Metadata persists in practice. The accredited forensic literature (Forensic Science International: Digital Investigation, 2021 and 2026) recovers exhaustive user, device, media, and communication metadata from both client and homeserver artifacts while encryption is on.^{31, 32}
• The usability of the encryption is a measured failure, not a complaint. Peer-reviewed human-computer-interaction work on end-to-end encryption (USENIX FOCI 2018 — Foundations and Practice of Usable Security and Human-Computer Interaction; EuroUSEC 2021, the European Symposium on Usable Security; Frontiers in Big Data 2021) finds, respectively, that users cannot explain what the encryption does and believe their encrypted messages are readable anyway; that they understand confidentiality but never authenticity, the property cross-signing exists to provide; and that key management generates nearly all observed usability failures while the verification handshake itself is not understood.^{55, 56, 57} Matrix’s cross-signing, key-backup, and multi-device recovery machinery is strictly more credential plumbing than these studies already found unusable in the simplest possible implementations.

Every one of these papers was written by people who had no operational stake in Matrix. They measured it, modeled it, forensically dissected it, or broke it. That is what “scientific proof” looks like for a claims inventory like this one: independent, peer-reviewed, reproducible, and — item by item — in agreement with what operators had already learned the hard way.

#Chapter SevenThe past is editable

Everything so far has been about the present: a protocol that will not settle, a community that cannot move, a bridge that will not hold, a client that cannot keep up, a security model that cannot be operated. This chapter is about the one thing a chat protocol is actually for, which is the record of what was said. Matrix’s position on that record is that it does not have one. The past is not a fixed thing that the protocol preserves and everyone reads from; it is a rendering, recomputed on request, from whatever the current state of a graph of events happens to say — and the specification provides first-class, user-facing ways to change what it says after the room has already read it, replied to it, and made decisions on the strength of it.

This is worth separating carefully from the security argument in Chapter Six, because it is a different failure and it is worse in the way that a leaky lock is worse than a lock that sticks. A redaction that fails to erase ciphertext is a confidentiality problem: the bytes exist, the adversary has them. A timeline that can be rewritten underneath a community is a truth problem. After an edit, the room contains a reply whose antecedent now says something different, and there is no field in the protocol that records the change, no way to ask the server “what did this message say at 14:02?”, and no way for a reader to notice that they are reading a different sentence than the one that was answered.

7.1 An edit is a new event, and the old identifier is what everyone else is holding

Editing a message in Matrix is not an in-place modification. It is a second event, carrying the replacement text in an m.new_content field and a pointer to the event it supersedes:⁶⁷

{
  "type": "m.room.message",
  "content": {
    "body": "* Deadline is Friday",
    "m.new_content": { "body": "Deadline is Monday", "msgtype": "m.text" },
    "m.relates_to": { "rel_type": "m.replace", "event_id": "$original" }
  }
}

Read the shape of that carefully, because the whole problem is in it. The original event keeps its event ID. And every other thing in the room that refers to a message refers to it by event ID: replies point at it with m.in_reply_to, thread roots and thread parents point at it with m.thread, and reactions point at it with m.annotation.⁸ None of those references are invalidated, versioned, or annotated when the text behind the ID changes. The specification’s instruction to implementations is explicit: the content property of the original event is replaced entirely by the m.new_content.⁶⁷

So the event ID stops being a name for a sentence and becomes a name for a slot, and the slot’s contents can be swapped at any point in the room’s life. Everything anchored to the slot moves silently. A reply that said “no, we pushed it to Friday” now sits under a message reading “we pushed it to Monday,” and it is still, in the strict and useless sense, a correct reply — to the event. Not to the words. There is no field anywhere that says “this was rewritten after you answered it,” because by the time the answer exists the rewrite has already been folded into the anchor the answer points at.

Two further details make this worse rather than better. First, the specification does not require a diff, a revision history, or any client-visible prior text; the original body is retained only as a fallback for clients that do not understand edits, and the fallback is the replacement text prefixed with *.⁶⁷ A capable client sees a clean sentence that was never said. An incapable client sees the new sentence and an asterisk. Neither sees the old one. Second, when two edits of the same message exist, the specification resolves which one wins by origin_server_ts, falling back to a lexicographic ordering of the event ID.⁶⁷ That means the content of a message in a federated room can be decided by clock skew. A member whose device clock is wrong does not get an edit rejected; they get an edit that silently loses, or wins one that should not have, and the room cannot tell them which happened.

One thing this chapter does not claim, because it is false: a moderator cannot rewrite your words. The specification requires the replacement and the original to have the same sender, so editing is author-only.⁶⁷ The danger is not that the admin edits you. It is that you can, that everyone can, that it is a headline feature of the flagship client, and that a room of four hundred people has no mechanism for distinguishing the sentence you answered from the sentence that now occupies its slot.

7.2 One event ID, two bodies, one homeserver

The cleanest evidence that Matrix has no canonical past is a corner of its own API. Implementing the replacement above requires the homeserver to perform the content swap on the endpoints clients actually read from: /messages, /context, /relations, and /sync when the relevant section is limited.⁶⁷ And then it specifies an exception:

An exception applies to GET /_matrix/client/v3/rooms/{roomId}/event/{eventId}, which should return the unmodified event (though the relationship should still be bundled, as described above).⁶⁷

One homeserver, one event ID, two different bodies, depending on which endpoint you ask. There is no canonical version of the message, because the specification deliberately declines to designate one: the timeline endpoints serve the rewritten text, and the single-event endpoint serves the original. Any tool that reads a message by ID — a bot, a bridge, an integration, a moderation export, a search index — gets a different answer from the one the room is displaying, by design, and nothing in the response tells it that it is looking at a different past.

And the redaction path runs the clock backwards. The specification is also explicit about what happens when someone redacts an edit:⁶⁷

When a message using a rel_type of m.replace is redacted, it removes that edit revision. This has little effect if there were subsequent edits, however if it was the most recent edit, the event is in effect reverted to its content before the redacted edit.

Read that again, because it is the purest time travel in this document. Someone writes “Deadline is Friday,” changes their mind, and the room now shows “Deadline is Monday.” A moderator redacts the edit — a normal, unremarkable, entirely legitimate moderation action, removing a revision rather than a message — and the room’s text reverts to “Deadline is Friday.” The words the author removed come back. The author is not notified, because there is no notification to send: the protocol has no concept of a rewind, only of a redaction. And no reader can tell, because from the room’s point of view nothing happened at all — the message simply reads what it reads, and the earlier sentence is gone again with no trace that it was ever superseded.

This is the failure mode the phrase “time travel” actually names. It is not a metaphor for a buggy client showing stale data. It is a specified, implemented, user-facing capability to move a conversation to a point it was not at, in either direction, after the fact, with the intervening history unrecoverable and unannounced.

7.3 Redaction is a black bar, and the project has said so out loud

It is worth being precise about what redaction is, because the word does a great deal of unearned work in the surrounding discourse. The protocol’s own account of the design is that redaction strips fields from events without affecting anything at the protocol level — that is, it removes content while preserving the structure the room needs to keep federating.⁷² The reference implementation’s maintainers were refreshingly blunt about the same point while working through what redacted media leaves behind: a redacted event is not a deleted event, it is a partially blacked-out one, “we nuke part of the event, we don’t delete it, we partially redact it,” the visual metaphor being the censored document in a film rather than the destroyed one.⁷²

The same thread records the origin of the word and the project’s own verdict on it. “Redact” was chosen over “delete” precisely so that users would not assume the operation conferred stronger confidentiality than it does — and the assessment of where that plan ended up is worth quoting in full, because it is a primary-source verdict on a decade of UX:

AFAIU the Matrix designers used “redact” instead of “delete” in the first place in an attempt to avoid users assuming that the operation provides stronger confidentiality that it actually does (too bad they have abandoned that terminology in Element).⁷²

They have. In the interface, redaction is presented as deletion, and users are shown a tombstone reading “message deleted” — a presentation the project’s own engineers describe as having abandoned the careful terminology the design was built on. What the room actually ends up with is the worst of both properties: the conspicuousness of censorship without the information of it. Every participant permanently sees a marker where a message used to be, nobody can learn what it said, the sender cannot prove what they wrote, and — as Chapter Six established for the encrypted case — the underlying ciphertext is not recalled from federated copies regardless. Redaction conspicuous but not curative is a security foot-gun; redaction conspicuous, not curative, and not even final is a governance one.

Two further asymmetries compound it. Redactions are events, so they federate on their own schedule: a server that has not yet received one renders the message, and a client that has not yet synced the redaction shows it. Two participants can look at the same room, at the same moment, and correctly display different content, with neither client being broken. And because redaction is a power-level operation rather than an authorship operation, the room ends up with an asymmetry nobody elected: a moderator can remove anyone’s words from the timeline, permanently and irreversibly in the interface, without being able to read them in an encrypted room, and without any record in the protocol that they were there first.

7.4 The specification also has an official way to add history that never happened

If rewriting the recent past is a feature, then rewriting the deep past is at least a proposal, and it is a merged one. MSC2716 defines a mechanism for a room creator to send events into a room’s history that did not occur in it — a batch of retrospective events, inserted ahead of the existing timeline and flagged with an historical property.⁷¹ The purpose is benign and understandable: moving a conversation from an old system into a new room without losing the record, and giving clients a way to present it as imported rather than native.

But look at how the flag works, because this is the whole argument. The historical property is described in the proposal as a hint: a thing to be used “as a hint/indication to clients that history didn’t originally happen in the room,” rendering a small “Historical” label in the corner so users can treat it as less trustworthy.⁷¹ It is a request to the client’s discretion. The event is in the room, in the DAG (the room’s directed acyclic graph of events), participating in the room’s state and its signatures, and the only thing standing between it and indistinguishable forgery is a boolean that a client may choose to ignore. The protocol does not enforce the distinction because the protocol does not have a way to: the events are the same kind of event, arriving through the same door, in the same shape.

Implementing this required a new room version, because it changes the redaction algorithm — which is itself a tidy illustration of how deeply Matrix binds “what a room is allowed to forget” into the hash of its own history.⁷¹ In the reference implementation the capability is experimental, flag-gated, and only honoured for events sent by the room’s creator.⁷¹ So the honest statement of this feature’s significance is narrow and specific: the room’s owner can add events to the room’s past, subject to a client-side courtesy label. Given that a room’s history is the only shared record its community has — there is no other archive, no export that carries the graph, and no portable copy, as Chapter Two established — this means that whether a given room’s history is a record at all is a function of who owns the room, not a property of the protocol.

7.5 “Reply in thread only” and why it cannot work

Now the second half of this chapter, which is a much smaller problem with a much larger blast radius, and which is the reason the first half matters. In every Matrix community with any volume, the moderator’s first move is some version of: please reply in thread, keep the main timeline clean. It is a reasonable request, it is universally made, and on Matrix it is very close to unworkable — not because people are obstinate, but because the protocol has no way to express the rule and the request actively makes the timeline problem worse for a large minority of the room.

The reason is that a thread is not a container; it is a pointer. There is no sub-room, no separate message log, no server-side thread. A threaded message is an ordinary event in the room, carrying a relation:⁶⁸

"m.relates_to": {
  "rel_type": "m.thread",
  "event_id": "$thread_root",
  "is_falling_back": true,
  "m.in_reply_to": { "event_id": "$last_event_id_in_thread" }
}

It is delivered to the room exactly like everything else. Where it appears is decided by the client, on receipt, with no server involvement. And the specification provides exactly one mechanism for influencing clients that do not understand threads — the is_falling_back flag, whose entire defined purpose is to instruct those clients to do the thing the rule is trying to prevent: display the message in the main timeline as a rich reply. The proposal is unambiguous that thread-ready clients should set it to true when the user is not deliberately quoting a specific message, so that non-threaded clients get the context.⁶⁸

So a threaded reply is by construction one event with two renderings, chosen by the client. “Reply in thread only” is not a rule about the protocol; it is a request that the majority of the room use one client’s interpretation of a rendering hint. The enforcement mechanism is social, it applies unevenly, and — this is the operational consequence — it does not reduce main-timeline volume for anyone on a client that renders the fallback, which is to say everyone on an older client, an alternative client, or the bridge.

There are five separate ways this degrades, and they compound:

• The rule holds only where the fallback is ignored. Clients outside the reference implementation — the ones Chapter Five catalogued as abandoned, rewritten, or unmaintained — are precisely the ones most likely to render the fallback, because the fallback is what they were told to implement. The admin’s request to reduce noise is, mechanically, a request that a specific client population keep seeing the noise.
• Clients disagree about the structure, and the spec is on record about it. The specification states that it is not possible to create a thread from an event that is itself the child of a relationship, and that it is therefore not possible to nest threads.⁶⁸ Both Element Web and the reference homeserver permit exactly that in practice; the contradiction is documented, with request and response payloads, on the specification’s own issue tracker, where a maintainer confirms the reference server only checks for relation-type relationships and therefore accepts what the spec forbids.⁷⁰ So two participants can be looking at structurally different conversations, in good faith, with no bug reportable on either side.
• The removal of the fallback is a proposal, not a release. The behaviour that produces the duplicate — the same message appearing in the thread and in the main timeline — is the spec’s own documented fallback mechanism, and the proposal titled “Transitioning away from reply fallbacks” exists to get rid of it.⁶⁹ The double-post is therefore not a client bug that will be fixed. It is a designed behaviour, written into the specification, load-bearing for a decade of clients that were built to rely on it, on its way out through the same MSC process that spent from December 2021 to June 2026 replacing one sync mechanism that was never accepted in its original form (see 1.1 and 5.3).
• The bridge has no threads to give. Chapter Three established that the IRC bridge flattens Matrix’s event model into text: edits become synthetic notes, reactions become mojibake, and thread structure does not survive the crossing at all.^{20, 21} An admin who mandates threads is mandating a structure across a boundary that discards it. The IRC half of the community is not being difficult; it is being handed a rule it has no way to satisfy, and it will satisfy it by continuing to post in the main timeline like everyone else on a non-threaded client.
• Threading concentrates replies on the most rewritable events in the room. This is the link back to 7.1, and it is the reason the two halves of this chapter belong in one. A thread is a tree of messages hung off a single event ID; every message in it points at the root, and the root’s text can be replaced server-side without invalidating any of them. Directing a room’s traffic into threads therefore directs it into the structure with the highest concentration of references to a single mutable anchor. You are not just reorganizing where people talk. You are concentrating the room’s memory on the exact objects that the protocol makes easiest to rewrite after the fact, and removing the surrounding linear context that would have let a reader notice the rewrite.

And the rule cannot be enforced in the first place, for reasons Chapter Two already established: Matrix moderation is a flat integer power ladder keyed to individual accounts in a single m.room.power_levels event.⁸ A power level can remove a message. It cannot remove a message from a main timeline that a client has already rendered, and it cannot stop the next one from arriving. There is no way to require a relation type, no way to mute an account from the root timeline, and no way to ask a client to honour a convention — only to ask the person. A rule that cannot be enforced and cannot be audited does not produce one norm. It produces two, plus a moderation log full of ambiguity, because the people who ignored the rule and the people who never saw the message are indistinguishable from the outside.

Which leaves the community with the two remedies the protocol actually offers for a noisy timeline, and they are mutually exclusive. Matrix’s structural answer to noise is more rooms — a room per topic, a space per project — and that is precisely the fragmentation engine of Chapter Two: every new room is a new island with its own membership, its own power levels, and no history. The other answer is threads, which fragments the conversation inside a room. Protocol gives a community a fragmentation dial with no off position, and the moderator is asked to choose where to lose people.

7.6 What a room actually loses

Stated as a table, because the mechanism is more damaging than the anecdote:

The uncomfortable summary of this chapter is that Matrix made a deliberate trade, and the trade is coherent. A federated protocol that cannot retract anything is unusable for moderation, because a community with no way to remove abuse has no reason to exist. So Matrix built retraction, and built editing, and built threads, and each is individually reasonable. The design problem is not any one of them. It is that all three were layered onto a timeline whose defining property — that everyone is reading the same history — was never made load-bearing. The result is a room in which the moderator has a red button with no delete behind it, the author has an eraser that erases other people’s replies too, and the community’s shared memory is a thing that is recomputed from the present every time it is read, and can be made to differ from one reader to the next by nothing more than a clock, a client, or a moderator’s good intentions.

Compare that to the model most people picture when they hear “chat protocol,” and to the one this document ends up recommending: in IRC, a message that has been said is said. It is a line in a log, it is quoted with its original text, it cannot be edited by the person who said it or by anyone else, and the log is the log. That is not a missing feature. It is the feature the entire medium is built on, and Matrix — which set out to be IRC’s successor and inherit everything it got right — gave it up in exchange for capabilities that turned out to be worth less than the thing they were purchased with.

#Chapter EightMission-critical, and the guarantees Matrix does not make

Everything up to this point has been an argument about fitness for ordinary use: whether a community can live here, whether a conversation survives a week, whether a client is tolerable. Emergency response is a different question, and the difference is not one of degree but of category. When a message is misrouted, the cost is an awkward thread. When it is dropped, the cost is counted in people. The same defects documented in the preceding chapters stop being irritations and become disqualifying, because they attack precisely the properties that emergency communication is built on — and they attack them by design, which is the part that cannot be fixed with a patch. This chapter states that argument explicitly, because a document that only implies it has not made it.

8.1 Mission-critical is a defined standard, and Matrix does not meet it

The standard is not a matter of taste or severity. Communication relied upon for life safety, for a medical or legal record, or for the coordination of an emergency response is normally held to a short and boring list of properties, and the list is boring because it is not negotiable:

• Delivery that is guaranteed and observable — the sender can establish that the message arrived.
• Authenticity a third party can verify — not merely asserted by the two endpoints.
• A durable, tamper-evident record — what was said cannot be silently altered or vanish.
• Accountability — an answer to who could read this, who changed it, and under what authority.
• Operability under stress — one obvious action, no ceremony, at the moment of use.
• A defined fallback — a specified behaviour when the network degrades.

Set against what the specification actually provides, the result is not a matter of degree:

Every entry in the right-hand column is a design decision rather than an oversight, and that is the whole difficulty. A room whose history can be rewritten can also be moderated; a protocol that never delivers a message reliably is one that federates at scale; a client that verifies nothing is one that ordinary people will actually use. Each decision is defensible in isolation, and this document has spent seven chapters saying so. The claim here is narrower and harder: the set of decisions that makes Matrix workable as a social network is the same set that makes it unusable as an emergency system, and no configuration option changes that, because the properties are not in the configuration. They are in the protocol.

8.2 Silence is ambiguous, and ambiguity is the danger

Start with delivery, because it is the property an emergency response leans on hardest and the one Matrix is least able to supply. The public record is not subtle: multi-minute initial syncs, with a timeout that cannot be changed⁶¹; sync timing out under ordinary use⁶²; initial sync requests observed taking 36 seconds to arrive⁵⁰; a forced logout-and-log-in migration with no recourse for the users it caught⁴⁶; and the best-maintained terminal client in existence telling its users that the first connection can take a few minutes while it syncs⁷⁸.

Set those numbers beside the question a sender actually has — did they get it? — and the protocol cannot answer it. Three states are indistinguishable to the sender: the event was accepted by the local homeserver; the event is queued behind a sync that is failing; the event was delivered to a client that has not synced and may never sync. There is no delivery receipt to wait for, no durable outbox holding the message until it is acknowledged, and no contract that says what the sender is entitled to see. A read receipt, where a client offers one, is an optional courtesy from another implementation — not a guarantee from the protocol, and not evidence of anything.

This is the single most disqualifying property in the chapter, and the reason is that every other failure documented in this document is at least visible. A crashed client announces itself. A redacted message leaves a black bar. An unverifiable device produces a warning. A dropped message produces nothing at all, and it is indistinguishable from a message that was never sent. In an emergency the sender’s next action — escalate, retry, switch channel, go and look — depends entirely on telling those two cases apart, and the protocol is built so that the sender cannot.

There is a second, quieter version of the same problem on the receiving end. Delivery is to a client, and the client is a moving target: 5.4 documented the sync-and-state treadmill, and the current flagship is a fourth-generation rewrite rather than an upgrade of the third. So “it was delivered to their phone” does not mean “they saw it,” and in an organization that has just been told the person’s handset was replaced, that gap is where the message goes.

8.3 Authentication that cannot be verified, when the message has to be trusted

The second pillar is authenticity: not who does this account belong to in the ordinary social sense, but whether a specific message in a specific room can be attributed to a specific person with a defensible chain of evidence. Matrix answers this in layers, and every layer is opt-in.

The bottom layer is that encryption is off by default. The specification’s own mechanism is that a client enables end-to-end encryption by sending an m.room.encryption state event^{8, 9} — that is, a room is unencrypted until somebody deliberately turns it on. In an unencrypted room the homeserver reads the plaintext, which means the operator of the server is a party to the conversation, is exposed to compulsion, and has a breach history^{22, 54}. An emergency channel that nobody remembered to encrypt is an ordinary chat room with a consequential name on it.

The next layer is verification, and here the document has already established the position: key verification is opt-in and trust-on-first-use (6.3), so the common case is a device that is trusted because it said it should be trusted. Above that sits the strongest result in this document — the formal analyses found that the specification requires neither cryptographic authentication of group membership nor mandatory out-of-band verification, and encoded both to show what follows from their absence^{29, 30}. The consequence is precise and worth stating without softening: the set of devices that can read an encrypted room is not authenticated. A hostile or coerced homeserver can present a device as a member of the group, and a client that has not verified anything has no basis on which to object.

Below all of that sits identity itself, and Chapter Two already convicted it: an identifier is @localpart:server, minted by one server, and the protocol does not bind it to anything a third party can check. Two servers will happily mint the same localpart, and nothing in the client distinguishes @incident-lead:alpha.example from @incident-lead:beta.example in-band. Bridging — the obvious way to reach responders who live on IRC — discards identity entirely (6.8).

So the honest position is that authenticity in an emergency rests on out-of-band human verification: a known phone number, a voice, a face, a password spoken in person. That is a process, not a protocol, and it does not scale, it fails during the one hour when everyone is busiest, and it is exactly the kind of guarantee an organisation is buying a system in order not to have to run by hand.

8.4 A record that cannot be audited, and a history that moves

The third pillar is the record, and this is where Chapter Seven’s analysis stops being a design preference and becomes an evidentiary problem. The mechanisms are already established and they are merged, not proposed: one event ID served with two different bodies (7.2); redaction as a black bar that the project itself has described as insufficient, with redacted media left on disk⁷² (7.3); and a merged mechanism by which a room can be sent history that never happened⁷¹ (7.4). Add state resolution, which means even a room’s membership at a given moment is a negotiated computation rather than a stored fact (1.2)⁵⁹.

None of that is a curiosity when somebody afterwards needs to establish what was said. It cannot: not from the protocol, and not from the server. The strongest available evidence for this point is not this document’s analysis but the forensic literature — two peer-reviewed forensic studies of Matrix, in which professional investigators with full access to client artefacts and server logs had to reconstruct events from evidence on both sides, because the homeserver’s own record is neither complete nor append-only^{31, 32}. Those studies are the strongest possible form of this argument, because they come from people whose professional task is exactly the question an incident review asks. If a forensic investigator cannot treat the server as the log, then a hospital, a newsroom, or a regulator cannot either.

It is worth being explicit about the asymmetry, because it cuts against the sender as well as the reader. An edit is a new event that reuses the original identifier, so a later reader sees the current text with no indication that it was ever different. A redaction removes content from clients while the media may remain recoverable from the server. A batch-send can insert a conversation that did not occur. In every case the identifier looks right, the timeline looks continuous, and the discrepancy is invisible to anyone who was not already looking. For a system of record, that is the definition of unusable.

Chapter Seven ended by contrasting this with IRC, where a line that has been said is said, and noted that this was a deliberate and coherent trade for moderation. It was coherent. It is also the precise property that a system of record exists to provide, and it is gone.

8.5 Accountability is a token, not an institution

The fourth pillar is the one organisations are usually buying: the ability to answer, after the fact and on the record, who had access to a conversation, who can change it, who authorised a deletion, and what happened. Matrix’s answer is power levels in a room^{38, 43}. One account at an elevated level can redact, ban, and purge, within the room, today.

What is missing is everything that would make that answer investigable. There is no immutable log of administrative actions, and no requirement that one exist. The room’s own power levels are state events, which means they are themselves subject to the same negotiation and redaction machinery described in 7.2. There is no separation of duties, no second approver, no mandatory reason code, and no protocol-level obligation on a server operator to report what its administrators did. So the question “who could read this room, and who authorised the deletion?” does not have an answer inside the system. It has an answer in someone’s memory, or in a procedure the organisation wrote itself.

Add the server operator to the picture and the position sharpens. In an unencrypted room the operator sees everything, and operators can be compelled: the vendor’s own published position is that governments are turning to Element and Matrix for exactly this kind of work⁵⁴, which is a legitimate product decision and simultaneously a fact that any adopter must price. The reference deployment has been breached before, and the breach was disclosed by the operator itself²² — to the operator’s credit, and without making the plaintext any less plaintext.

This is the point at which the argument stops being about the protocol and becomes about institutional design. Mission-critical systems are not trusted because their operators are good people. They are trusted because the system limits what a bad actor, a compelled operator, or an exhausted administrator can do alone, and because it can afterwards prove what they did. Matrix delegates that judgement to a token.

8.6 The protocol fails hardest exactly when the network is worst

The last pillar is the one that decides the verdict in practice, because it is the condition under which emergency communication actually happens. Emergency response is conducted when power is intermittent, backhaul is congested, and the only thing that works is whatever coped worst. Matrix’s transport is a long-poll loop over an always-on connection, and the measurements of what happens on a first or resumed sync are in minutes^{50, 61, 78}. That is the failure curve of a system that assumes the network is there and working.

The low-bandwidth end of the ecosystem does not rescue it, and the project’s own client directory is the evidence. The interactive terminal clients — the closest thing Matrix has to a client for a bad link — are graded Beta^{73, 74, 75}. The terminal entries the project grades Stable are CLI tools described as being for sending and receiving, not chat clients. The best-maintained terminal code in existence documents a first connection that takes minutes⁷⁸. There is no client in this ecosystem whose design target is a congested link.

Nor does the specification provide the transport profile that emergency services actually depend on. There is no store-and-forward, and in particular no asymmetric store-and-forward — the model in which a sender with no connectivity hands a message to a recipient who has some, which is the basis of most real emergency dispatch systems. There is no SMS, satellite, or modem fallback defined by the protocol. What exists instead is the bridge (Chapter Three), and a bridge is a single point of failure that also discards identity on the way through (3.4, 6.8).

So the protocol is weakest in precisely the conditions it would be deployed for, and every mitigation for that weakness lives outside the protocol. That is the finding that no amount of operational care can argue away, because the alternative is not a better-tuned client. It is a different transport.

8.7 The honest counterpoint, and what would change the verdict

The counterpoint deserves to be stated at full strength, because a chapter like this one that only argues one way is not an argument. Matrix is used for sensitive work, and the people using it are not being careless. The project markets itself for precisely this class of use, and documents governments turning to Element and Matrix for it⁵⁴. For a large class of threat models Matrix is strictly better than the mainstream alternative, and the properties it genuinely has — federation, no single vendor, a public specification, a genuine choice of client, and an auditable history of its own development — are properties that most systems cannot offer at any price. Nothing in this chapter is an argument that Matrix should never carry serious work.

The claim is narrower, and if it is accepted it is more serious for being narrow: Matrix does not supply the guarantees that mission-critical use requires, and a deployment that adds them is carrying its own safety rather than the protocol’s. The compensating controls are knowable and finite — a second independent channel; out-of-band verification of every device before it is trusted; an archive you control and can audit; a bridge to something with delivery receipts; manual re-verification after every device change; a written fallback for when the network is gone. Each is an operational burden. Each exists because the protocol omits the guarantee behind it. An organisation that has implemented all six has built a mission-critical system, and Matrix is a component of it rather than the thing that makes it safe.

Stated as a falsification test, the chapter stands or falls on this list, and every item is currently unmet:

That is the difference between unusable and unusable as specified. The first is a bug report. The second is a verdict on a design, and it is the one this document is making. Nothing here requires a bug to be filed: every item requires a decision to be reversed, by the people who made it, for reasons that were sound at the time. That is what a protocol becomes when it optimises for the future it is building rather than for the worst afternoon in its users’ lives — and for the organisations who would be relying on it, that is the only afternoon that matters.

#Chapter NineWhat is actually proven, and what is merely argued

A document like this one is owed an accounting. Critics of Matrix — and Matrix’s own defenders, who are considerably more numerous and considerably better informed than the people producing critical essays — have a legitimate complaint about the genre: every long anti-Matrix post eventually stops arguing and starts asserting, and the reader has no way to tell which sentences rest on a theorem and which rest on a grudge. This chapter exists to make that distinction explicit, before the afterword, so that the preceding eight chapters can be read with the right amount of skepticism.

The rubric has four grades, and they are not equal. Most criticism of Matrix is Grade D and should be discounted accordingly; some of it is Grade C and is very strong; a small amount is Grade B, which is where the real damage is; and a little is Grade A, which is close to unanswerable.

9.1 Grade A: what is machine-checked or proven

Three results sit at the top of the ladder, and they are the reason this document does not merely complain. In a mechanized symbolic analysis, the Olm and Megolm protocols and their composition were modelled in ProVerif, and the authors mechanically proved properties, mechanically reproduced previously known attacks, and then compared the result against an equivalent model of Signal with Sender Keys.³³ The finding is not that Matrix is vaguely weaker. It is that the Olm/Megolm composition has provably weaker post-compromise security than the Signal composition, and that the Matrix specification’s requirement to sign Olm pre-keys — a requirement the spec states without justification — is the only thing standing between the two.

The 2024 IEEE S&P paper went further and formalized the part of Matrix that the marketing never mentions: state sharing, the mechanism by which a new device gets the room keys it missed, whether from peers or from the server-side backup that the “recovery” feature depends on. Having defined that formally, the authors proved that it is incompatible with forward secrecy and post-compromise security in the same model. Their model also encodes what the specification simply does not require: cryptographic authentication of group membership, and mandatory out-of-band verification. The security properties hold only in the configuration users almost never configure.³⁰

And in 2023, researchers produced working attacks rather than bounds, exploiting insecure-by-design choices, protocol confusion, missing domain separation, and implementation bugs distributed across the sub-protocols — and demonstrated that the specification’ failure to require verification leaves clients with no authentication guarantee at all in the ordinary case.²⁹ This is the difference between a benchmark and a proof: nobody has to take anyone’s word for how Matrix fails, or about which guarantees survive the failure.

9.2 Grade B: what is impossible, rather than merely bad

Grade B is the category that carries the argument, and it is the one casual criticism always misses. A bug can be patched. A missing feature can be added. A Grade B claim is a statement that a desired outcome is unreachable within a given design, so that obtaining it requires abandoning something else — usually something the community valued when it chose Matrix.

Take the headline promise. Matrix advertises end-to-end encryption plus shared history plus account recovery. Those three are not compatible, and the incompatibility is not an implementation defect; it is a theorem about the design.³⁰ If a server can hand a stranger the keys to last Tuesday’s conversation, then last Tuesday’s conversation was never protected against that server, no matter what the UI says. Every “we added key backup so you don’t lose your history” release is therefore a small, documented retreat from the security promise, made in the name of usability, and made silently.

Second: you cannot move a community. Each account lives on the server named in its identifier, and each event is cryptographically signed by the homeserver that accepted it, embedding the room it belongs to. That is why history cannot be re-issued under a new room on a new server, why a server’s domain can never be changed, and why Element’s migration path is a documented sequence of one-way, per-account, high-stakes operations that the vendor’s own documentation says cannot carry history with them.^{39, 37, 35} The community-level conclusion then follows deductively rather than statistically: a community cannot migrate as a community, therefore it splits. Chapter Two did not need a trend to predict that. It needed a signature.

Third: redaction is cosmetic. In an encrypted room, the ciphertext and its signatures are already distributed to every server in the room and every client that ever received the event. There is no protocol operation that recalls them. A community that believes it has deleted a secret has deleted a reference to it.

Fourth, and least discussed: the convergence machinery that decides who is allowed to do what has never been formally verified. The independent researchers who found the first real state-resolution defects flagged formal verification of Matrix’s authorization rules and state resolution as the necessary next step, and the project publicly agreed.⁵ Six years later there is no verification, no mechanized model, and no theorem. The peer-reviewed analysis of the substrate they were studying is blunt about what it provides: transaction-based DAGs offer causal order and eventual consistency, but no finality and no guarantee for a strict consensus on access rights.⁵⁸ And the current proposal for fixing the remaining class of state-reset defects says so itself — the residual failures come from mismatched orderings, and removing that entire class of problem would require the protocol to have a single ordering: “If the protocol had a single ordering then this would remove this entire class of issues. This will be explored in a future MSC.”⁵⁹

Read that last admission carefully, because it is the most consequential sentence in this document. Matrix’s answer to “who is the admin here?” is an algorithm that resolves conflicting views by picking the most defensible one. Its own maintainers say that some of its failures can only be eliminated by a global total order of events — and a decentralized protocol, by definition, cannot have one. The component with the highest consequences, no fixed point, and the least verification is the one the whole security story rests on. In the industry this is called an unacceptable risk. In Matrix it is a future MSC.

9.3 Grade C: what is measured, and how well

Grade C is where most of the earlier chapters live, and its quality varies more than its advocates assume. The strong version of Grade C is measurement performed by people with no stake in the outcome, published in peer-reviewed venues, using the real system. The federation centralization crawl, the event-graph replicated-data-type analysis, the two forensic studies, the formal cryptanalysis, and the three HCI studies all clear that bar.^{28, 27, 31, 32, 55, 56, 57}

There is also a weaker but still legitimate Grade C: primary operational records published by the project or its users, which are not controlled studies but are contemporaneous, verifiable, and unfalsified by the party with the most incentive to hide them. The Element X Web deck’s 1.4 GB-to-90 MB memory figure, the sliding-sync proxy’s own bug and slowness assessment, the 36-second initial syncs, the forty-minute logins, the lost-computer cross-signing lockouts, and the state resets that repeatedly ejected users from the project’s own flagship developer room all belong here.^{48, 49, 50, 51, 52, 62, 63} Nobody commissioned that deck. That is precisely why it is evidence.

One Grade C item deserves its own paragraph, because it is the clearest demonstration in the record that Matrix’s state layer is not merely slow but actively wrong in production, in the room where its developers talk. In June 2020, several users were mysteriously ejected from #matrix:matrix.org. The investigation found state resolution concluding that their own homeservers were no longer in the room, and a Synapse maintainer’s assessment was blunt on two points: once a server reaches a wrong conclusion about room state, “those incorrect conclusions will tend to persist for the lifetime of the room,” with the only remedy being to leave, purge the room from the database, and rejoin; and the maintainers “think this is a security issue because we think it’s possible to engineer that situation,” while stopping short of claiming the ejections were deliberate.⁶⁰ The bug was fixed; the class of bug was not. State resets in later room versions kept being reported, and the answer given to a user in 2022 was that the resolution algorithm itself had not changed since room version 2.⁶⁵ A room that can eject its own members by accident, whose bad conclusions outlive the bug that caused them, and whose fix is a database wipe, is not a system with an occasional rough edge. It is a system whose access-control layer is best-effort in a domain where best-effort is not sufficient.

9.4 Grade D: argued, and the honest limits of this document

Everything else in these eight chapters is inference, and it should be labelled as such. The claims that the specification’s governance will never freeze the protocol; that every fix has centralized something or added permanent surface; that the open-source funding model cannot sustain a security-critical protocol; that Matrix’s security posture is a competitive disadvantage against centralized products that ship one client to one audience — all of these are arguments. They are arguments I think are well supported by the record, and the record is cited throughout, but no theorem establishes them and none could. They are predictions, and they should be weighed as predictions.

Which brings us to the question this chapter exists to answer honestly: is there scientific proof that Matrix is doomed? No. Nobody has proven that, and the people who write things like that are usually not the people who have read the papers. Worse, the strongest version of that claim is self-defeating, because the honest evidence does not say “Matrix will fail.” It says something more specific and more damning: the properties that make Matrix worth choosing are mutually incompatible with each other, and every fix the project has shipped has resolved the conflict by surrendering one of them. The sliding-sync proxy centralized. Key backup centralized. The default homeserver centralized. History sharing surrendered forward secrecy. The client rewrite produced a second client. The state-resolution fix deferred the ordering problem to a future MSC. Room version 12, creator succession, retention caps, and a shrinking identity-server all point the same way: toward a system that is easier to operate and less federated than the one that was specified, one release at a time, in response to real user pain, by reasonable people making locally correct decisions.

That is not a prediction of collapse. It is something worse for the project’s stated goals, and it is supported by the Grade A and Grade B results rather than by opinion: Matrix’s design is not going to be fixed; it is going to be traded away, in pieces, as the cost of being usable. The protocol has already lost the encryption, identity, and governance arguments. What is left, after a decade, is a very good server and a loyal community.

Which is why the advice at the end of this document is not “wait for version 7.0.” Release numbers are not the problem, and no future release can deliver a set of properties that has never coexisted. The advice is to decide which property you are actually buying, and to pay knowingly for the ones you are giving up. Federation, or a state model that converges. User-held identity, or an authority that can restore it when the account is lost. Openness, or a steward who answers the phone. Matrix is not badly engineered. It is specified for all three at once, and every deployment inherits the entire specification whether it uses that part or not. Nobody is going to hand you a release that resolves this, because the resolution is a decision about what a given deployment is for, and that decision belongs to the deployment. Make it deliberately and Matrix is a good tool, and much of this document is a list of things not to do with it. Inherit it by default and it will spend your security budget for you.

#AfterwordWhy people keep using it anyway

If Matrix is so immature, split, bridging-hostile, broken, and insecure, why is anyone on it? Because it fills a vacuum. Organizations and communities that want a non-commercial, self-hostable chat have, until lately, had a thin menu: XMPP (agonizing to deploy), IRC (battle-worn but text-only and bouncerless at the enterprise level), or Discord/Slack (walled gardens with data-monetization). Matrix is the only thing on the menu that promises everything and that anyone will deploy. So people deploy it, superglue it together, and call it networking — until the bridge dies, the spec changes, the server’s CPU spikes, the ghost identities go south, or the next supply-chain incident lands.

None of this is to deny the energy behind Matrix. The protocol and its community are genuinely ambitious and genuinely productive. But ambition is not maturity, activity is not stability, and enthusiasm must not be confused with security. When you choose Matrix, you are choosing a moving experiment where the ground under your community, your identity, and your encryption shifts as the spec does — and where the one thing you can count on (@you:bigserver) is also the thing you were promised you wouldn’t have to count on at all.

The lesson is not “read the small print.” The lesson is “decide which property you are actually buying, and accept the cost of the two you are not” — and then stop expecting a protocol specification to resolve a question about your deployment. It was never going to.

#SourcesCited material & links

Numbered references are linked inline throughout as ^superscripts. All URLs verified to resolve at the time of writing. Entries 27 through 34, 55 through 58 are independent, peer-reviewed publications or industry security reviews (IEEE S&P, ACM Middleware, ACM SACMAT, IEEE Access, Forensic Science International: Digital Investigation, the NCC Group audit, USENIX FOCI, EuroUSEC, and Frontiers in Big Data). Entries 35 through 54 and 59 through 72 are primary sources: vendor documentation and engineering write-ups, conference slides, specification proposals, project issue trackers, and incident reports — that is, the developers’ own record of their client and their encryption layer. Chapter Eight grades every substantive claim in this document by evidence class, and is candid about which claims are only argued.

1. The Matrix Specification — https://spec.matrix.org/
2. The Matrix Specification — Room Versions — https://spec.matrix.org/latest/rooms/
3. The Matrix Specification — Room Version 2 (state resolution v2) — https://spec.matrix.org/latest/rooms/v2/
4. State Resolution v2 for the Hopelessly Unmathematical — https://matrix.org/docs/older/stateres-v2/
5. Matrix Decomposition — An Independent Academic Analysis of Matrix State Resolution — https://matrix.org/blog/2020/06/16/matrix-decomposition-an-independent-academic-analysis-of-matrix-state-resolution/
6. Project Hydra: Improving State Resolution in Matrix — https://matrix.org/blog/2025/08/project-hydra-improving-state-res/
7. State Resolution v2.1 — Implementer’s Guide — https://matrix.org/docs/spec-guides/state-res-2.1/
8. The Matrix Specification — Client-Server API — https://spec.matrix.org/latest/client-server-api/
9. End-to-End Encryption Implementation Guide — https://matrix.org/docs/matrix-concepts/end-to-end-encryption/
10. Vulnerability Disclosure — CVE-2021-40823 and CVE-2021-40824 — https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing/
11. MSC3575 — Sliding Sync — https://github.com/matrix-org/matrix-spec-proposals/pull/3575
12. Matrix Sliding Sync Proxy (reference implementation) — https://github.com/matrix-org/sliding-sync
13. MSC4186 — Simplified Sliding Sync — https://github.com/matrix-org/matrix-spec-proposals/pull/4186
14. Matrix Spec Change Proposals (the MSC process) — https://spec.matrix.org/proposals/
15. Element Web (reference client) — https://github.com/element-hq/element-web
16. matrix-react-sdk — https://github.com/element-hq/matrix-react-sdk
17. Synapse (reference homeserver) — https://github.com/element-hq/synapse
18. Dendrite (second-generation homeserver) — https://github.com/matrix-org/dendrite
19. Conduit (Rust homeserver) — https://conduit.rs
20. matrix-appservice-irc (the IRC bridge) — https://github.com/matrix-org/matrix-appservice-irc
21. IRC Bridge Setup & Configuration — https://matrix-org.github.io/matrix-appservice-irc/latest/bridge_setup
22. We Have Discovered and Addressed a Security Breach (April 2019, matrix.org) — https://matrix.org/blog/2019/04/11/we-have-discovered-and-addressed-a-security-breach-updated-2019-04-12/
23. The Matrix.org Foundation — https://matrix.org/foundation/
24. Counterfeit PyPI Packages with 5000 Downloads Installed Cryptominers — https://arstechnica.com/gadgets/2021/06/counterfeit-pypi-packages-with-5000-downloads-installed-cryptominers/
25. Nheko (Qt Matrix client) — https://github.com/Nheko-Reborn/nheko
26. Fractal (GNOME Matrix client) — https://gitlab.gnome.org/GNOME/fractal
27. Jacob, Beer, Henze & Hartenstein (2021). Analysis of the Matrix event Graph Replicated Data Type. IEEE Access 9, 28317–28333. DOI: 10.1109/ACCESS.2021.3058576.
28. Jacob, Grashöfer & Hartenstein (2019). A Glimpse of the Matrix: Scalability Issues of a New Message-Oriented Data Synchronization Middleware. Peer-reviewed at ACM Middleware 2019, DOI: 10.1145/3366627.3368106; extended report: arXiv:1910.06295.
29. Albrecht, Celi, Dowling & Jones (2023). Practically-exploitable Cryptographic Vulnerabilities in Matrix. 44th IEEE Symposium on Security and Privacy, IEEE S&P 2023: eprint.iacr.org/2023/485.
30. Albrecht, Dowling & Jones (2024). Device-Oriented Group Messaging: A Formal Cryptographic Analysis of Matrix’ Core. 45th IEEE Symposium on Security and Privacy, IEEE S&P 2024: eprint.iacr.org/2023/1300.
31. Schipper, Seelt & Le-Khac (2021). Forensic Analysis of the Matrix Protocol and Riot.im Application. Forensic Science International: Digital Investigation 36, 301118. DOI: 10.1016/j.fsidi.2021.301118.
32. Wang et al. (2026). DFRWS Down the Rabbit-Hole: A Forensic Analysis of the Matrix Protocol and Synapse Server. Forensic Science International: Digital Investigation 56, 302049. DOI: 10.1016/j.fsidi.2026.302049.
33. Ginesin & Nita-Rotaru (2024). The Matrix Reloaded: A Mechanized Formal Analysis of the Matrix Cryptographic Suite. arXiv:2408.12743.
34. NCC Group Cryptography Services (2016). Matrix Olm Cryptographic Review. Findings on lack of backward secrecy and weak forward secrecy in group sessions, as announced by the Matrix team — matrix.org announcement, Nov 2016.
35. Element Support Documentation (Element Knowledge) — Frequently Asked Questions. On migrating between Matrix accounts: “Currently Matrix doesn’t support moving communication history over homeservers,” with a manual workaround (invite the new account to the same rooms, re-grant power levels, export and import E2EE keys). https://ems-docs.element.io/books/element-support/page/frequently-asked-questions-Dcv
36. Simmons, J. (2024). Migrating from EMS to self-hosted Matrix. A first-person account of leaving managed hosting, including the warning that migration has “a point past which mistakes will permanently wreck” federation access, that encrypted messages sent during the window “will likely be unreadable, even if you do everything right,” and that rooms with limited history visibility cannot be recovered. https://matrix.org/blog/2024/01/migrating-from-ems-to-selfhosted-matrix/
37. Element Documentation — Migrate From EMS to Self-Hosted. “It is impossible to change the domain of any Matrix server,” and therefore an export from a server whose Matrix IDs carry that server’s domain cannot be re-federated under a different name. https://docs.element.io/latest/element-cloud-documentation/element-matrix-services/migrate-from-ems-to-self-hosted/
38. Matrix.org — Room Administration. Official guidance on community and room upkeep: room upgrades create a new room and tombstone the old; the upgrading account’s homeserver performs the upgrade; aliases and the published room directory are per-homeserver; join rate limits during upgrades make it “easy to lose a room”; some clients cannot follow an upgrade; room version 12 introduces creator ownership semantics and additional_creators. https://matrix.org/docs/communities/administration/
39. Synapse issue #10377 — Optionally populate history on room upgrade. Maintainer analysis of why history cannot be carried into an upgraded room: events embed the original room ID and are cryptographically signed by the sending homeserver, so no single server can re-issue them under a new room ID. https://github.com/matrix-org/synapse/issues/10377
40. Element (element.io) issue #73 — Matrix account migration tool is broken. The cross-server account-merge tool accumulated bugs, lost support for the current authentication stack, and was removed from the Element Matrix Services portal rather than fixed. https://github.com/element-hq/element.io/issues/73
41. Synapse Documentation — User Directory. The directory indexes only users “visible” to the homeserver: local accounts, plus remote accounts sharing a room with a local user or present in a public room known to the server. https://element-hq.github.io/synapse/latest/user_directory.html
42. Matrix Specification issue #1386 — Clarify wording of users to include in user directory search. Maintainer statement of record in the spec’s own tracker: “Synapse never performs any federation queries as part of user-directory search.” https://github.com/matrix-org/matrix-spec/issues/1386
43. Synapse Configuration Manual. Operator-side controls relevant to community autonomy, including federation_domain_whitelist (per-domain federation restriction) and the server-level retention policy with its allowed_lifetime_min / allowed_lifetime_max caps. https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html
44. Synapse Documentation — Message Retention Policies. Retention is not part of the Matrix specification, is implemented as an experimental server-side feature, is disabled by default, and is enforced only by the servers in a room that have it enabled — so a room’s retention request is advisory and operator-bounded. https://matrix-org.github.io/synapse/latest/message_retention_policies.html
45. Sydent (reference Matrix identity server). Developed 2019–2025 under the Matrix.org Foundation, which states it cannot resource its maintenance; now developed by Element, and by its own maintainers most homeservers and clients use the single matrix.org instance or none at all. https://github.com/element-hq/sydent
46. Matrix.org (2024). Sunsetting the Sliding Sync Proxy: Moving to Native Support. The network’s shared sliding-sync proxy was decommissioned in November 2024 and clients were to force a logout-and-log-in migration, on the announced schedule, with no recourse for affected users. https://matrix.org/blog/2024/11/14/moving-to-native-sliding-sync/
47. Baker, D. & Duros, F. (2026). An Element Web for the Future. Element’s own FOSDEM 2026 retrospective: the 2015 prototype was “small, simple, and lightning fast — switching between rooms felt instantaneous” but lacked “end-to-end encryption, Spaces, and other core Matrix functionality”; as the platform grew “so did the complexity and technical debt”; the shared SDK “became tightly coupled and increasingly difficult to maintain” with “business logic often liv[ing] inside UI components”; and the Rust SDK remains a “long-term plan” for the web via WebAssembly, against a roadmap of a move to MVVM and a future “Rust-SDK under WASM.” https://element.io/blog/an-element-web-for-the-future/
48. Hunt, G., Kirkwood, D. & Langley, D. (2025). Element X Web (slides, Matrix Conference 2025). Vendor performance figures: the Rust SDK, “used in EX mobile apps,” delivers “instant login, launch sync” and a “15x memory improvement (1.4GB → 90MB of heap)”; the Element Web roadmap lists “Move to MVVM” and “Rust-SDK under WASM”; and the design work is explicitly about understanding “today’s state of the product and UX debt.” https://2025.matrix.org/slides/slides_SJFXGH.pdf
49. Enderlin, I. (2024). Sliding Sync at the Matrix Conference. By an engineer on the Matrix Rust SDK team: “Matrix previous synchronisation mechanism is slow and inefficient”; the sliding-sync proxy “was starting to feel really buggy and was really slow,” prompting the simplified MSC4186; and sliding sync now “works linearly whether the user has 10 or 10’000 rooms.” The same page lists the conference talk “Unable to Decrypt This Message,” whose stated aim is to explain why users see that error and which concedes how hard it is, or was, to provide reliable E2EE across a federated network. https://mnt.io/articles/sliding-sync-at-the-matrix-conference/
50. matrix-org/sliding-sync issue #16 — Initial sync is worryingly slow & big to get to clients. Observed initial /sync requests taking 36 seconds to arrive, and still taking ~5 seconds to execute after roughly two hours offline, with large request payloads. https://github.com/matrix-org/sliding-sync/issues/16
51. element-hq/element-web issue #16879 — Security Key mismatch: cross-signing guarded by previous key. The canonical lost-computer cross-signing lockout, in the reporter’s words (“This is the ONLY Security Key I have! I literally just reset it!”; “If I AM doing something wrong, Element absolutely sucks at communicating it!”), with the maintainer diagnosis that after a security-key reset “your cross-signing keys are still guarded by previous security key unless you also reset them as well,” the four-step order-dependent recovery procedure, and a second maintainer’s assessment that the problem is “chronic,” listing eight filed issues “which doesn’t include the dozen or so times I’ve helped people deal with this in chat.” https://github.com/element-hq/element-web/issues/16879
52. element-hq/element-web issues #26321 and #26322 — the cross-signing reset flow. #26321: the “Reset cross signing” button in the desktop client prompts for the security phrase three times. #26322: the reset sequence is not atomic — keys are reset locally, then the secret store is updated, then the keys are uploaded — so a forgotten password or passphrase leaves “the account in a broken state, with local secrets not uploaded to server.” issue #26321; issue #26322
53. Element (2024). Deep dive into Element X! The vendor’s own framing of the problem: Element X promises “instant sync, instant login and instant launch — never stare at a launch spinner ever again” and “radically improved encryption UX, thanks to matrix-rust-crypto and the Invisible Encryption initiative” — and the price of the design is stated outright: “If you can’t verify, you’ll have to reset your encryption (which will delete any message keys backed up on the server) — but going forwards, this will ensure that encryption is genuinely invisible and friction-free, and avoid confusing warnings about ‘unverified devices’.” https://element.io/blog/deep-dive-into-element-x/
54. Element (2024). In an increasingly volatile world, governments turn to Element and Matrix. The vendor’s own success metric for the encryption rewrite: it “has simplified verification and almost eliminated ‘unable to decrypt’ errors thanks to a new common cryptographic library written in Rust.” The same post supplies the rest of the 4.4 evidence: that “[t]here are currently 16 governments that make use of Matrix-based software for their communications” while, “as it’s usually the most security-conscious parts of government that pioneer the use of Matrix, we often can’t cite those deployments”; that senators Wyden and Schmitt “have put the US Navy’s use of Matrix across ‘23 afloat units and 3 shore sites’ into the public domain”; that NI²CE Messenger is “a low-side sovereign messenger”; and that Element Server Suite is “Element’s core revenue-generating product”, the revenue from it funding everything else, with Synapse Pro sold “under a commercial licence, which in turn will help fund our open source work.” https://blog.element.dev/in-an-increasingly-volatile-world-governments-turn-to-element-and-matrix/
55. Abu-Salma, B., et al. (2018). Exploring User Mental Models of End-to-End Encrypted Communication Tools. Quantitative survey, n=125. Only 12% could confidently explain E2E encryption; three-quarters believed their end-to-end encrypted communications could be accessed by unauthorized entities; half believed SMS and landline calls were as secure as or more secure than the encrypted channel. USENIX FOCI 2018: foci18-paper-abu-salma.pdf
56. Schaewitz, L., Lakotta, D., Sasse, M. A. & Rummel, N. (2021). Peeking Into the Black Box: Towards Understanding User Understanding of E2EE. Qualitative interview study, n=12. Users infer E2E’s security properties largely from pre-existing beliefs about providers; explanatory metaphors improved understanding of confidentiality but “did not correct misconceptions about authenticity”; the authors recommend interventions targeting mental models rather than further explanation. EuroUSEC 2021, pp. 129–140. DOI: 10.1145/3481357.3481521; open-access copy: casa.rub.de
57. Reuter, A., Abdelmaksoud, A., Boudaoud, K. & Winckler, M. (2021). Usability of End-to-End Encryption in E-Mail Communication. Combined 50-participant survey and 12-participant task-based usability test. Key management accounted for nearly all identified usability problems (generation, import, recipient-key retrieval, and external key transfer to mobile); one participant “did not understand why such handshake is necessary and what to do with the trust words shown on the graphical user interface”; only one of twelve participants actually knew and used the encrypted technology. Frontiers in Big Data 4:568284. DOI: 10.3389/fdata.2021.568284
58. Jacob, Becker, Grashöfer & Hartenstein (2020). Matrix Decomposition: Analysis of an Access Control Approach on Transaction-based DAGs without Finality. The peer-reviewed version of the state-resolution analysis summarized in source 5. Establishes that Matrix’s transaction-based DAG substrate provides causal order and eventual consistency but “no finality” and “no guarantee for a strict consensus on access rights,” finds security issues in popular implementations, and calls for formal verification of the conflict-resolution mechanism. ACM SACMAT 2020, pp. 81–92. DOI: 10.1145/3381991.3395399 (publisher page; summary at matrix.org).
59. MSC4297 — State Resolution v2.1. The current proposal for the remaining class of state resets. Its own text identifies mismatched prev_events and auth_events orderings as the underlying cause and states that eliminating the class entirely would require a single global ordering: “If the protocol had a single ordering then this would remove this entire class of issues. This will be explored in a future MSC.” https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/4297-state-resolution-v2_1.md
60. element-hq/synapse issue #7742 — users mysteriously ejected from #matrix-hq. The June 2020 investigation into users being removed from #matrix:matrix.org by state resolution, including the maintainer assessment that wrong conclusions “tend to persist for the lifetime of the room,” that the only remedy is to leave, purge the room from the database, and rejoin, and that the maintainers “think this is a security issue because we think it’s possible to engineer that situation.” https://github.com/element-hq/synapse/issues/7742
61. matrix-org/matrix-js-sdk issue #682 — cannot change sync timeout; multi-minute initial syncs. Contains the 2019 field report that with thousands of rooms a connection “spends more than 40 minutes” while emitting a local timeout warning every eighty seconds. https://github.com/matrix-org/matrix-js-sdk/issues/682
62. element-hq/synapse issue #12971 — Sync is timing out. The June 2022 login thread, including the maintainer statement that “Initial sync is notoriously slow. That won’t realistically be improved dramatically until sliding sync is supported,” the note that the response cache for /sync defaults to zero so initial syncs make no forward progress unless an operator changes it, and the operator’s report of being able to log in only after “about half an hour — 40 minutes” on a server with roughly 1,500 rooms. https://github.com/element-hq/synapse/issues/12971
63. Huang, A. (2022). Matrix Notes. Operator account of moving between protocols, documenting the join cost of the project’s own flagship room: joining Matrix HQ “takes a few minutes and then fails,” because “the home server has to sync the entire room state when you join the room,” alongside contemporaneous notes on send and receive latency. https://anarc.at/blog/2022-06-17-matrix-notes/
64. element-hq/element-web issue #25395 — excessive GET /relations and GET /event calls. A user report that their client’s own request storm starved /sync of resources, making it impossible to keep up to date “for upwards of 30-40 minutes,” with tens of thousands of requests per reload and duplicated GET /event calls. https://github.com/element-hq/element-web/issues/25395
65. element-hq/synapse issue #8629 — state resets still happen in v2 rooms. Community reports of state resets in current room versions, and the maintainer determination that the state resolution algorithm “hasn’t been changed since room version 2,” with the debugging burden placed on volunteer operators. https://github.com/element-hq/synapse/issues/8629
66. Matrix Rooms Directory — #matrix:matrix.org. The project’s own flagship developer room, listed at more than 7,200 members and world-readable, used as the reference point for join-cost discussion in 5.3. https://matrixrooms.info/room/matrix:matrix.org
67. MSC2676 — Message editing (m.replace). The merged editing proposal, and the source of this chapter’s central findings: the server replaces the original event’s content with m.new_content in place; the replacement is omitted from GET /rooms/{roomId}/event/{eventId}, which returns the unmodified event, while /messages, /context, /relations and limited /sync return the rewritten one; concurrent edits are resolved by origin_server_ts with a lexicographic event-ID tiebreak; replacement requires the same sender; and redacting an edit reverts the message to the content it superseded. https://github.com/matrix-org/matrix-doc/pull/2676
68. MSC3440 — Threading via the m.thread relation. Defines threading as a relation on an event rather than a container, and defines is_falling_back as the flag that instructs clients without a threading UI to render the message in the main timeline as a rich reply. Also specifies that threads cannot be nested and that a thread cannot be created from an event that is itself the child of a relationship. https://github.com/matrix-org/matrix-spec-proposals/pull/3440
69. MSC3676 — Transitioning away from reply fallbacks. The proposal to remove the reply-fallback behaviour, cited in 7.5 as evidence that duplicate rendering of threaded replies is a specified, long-standing mechanism on its way out through the MSC process rather than a client bug. https://github.com/matrix-org/matrix-spec-proposals/pull/3676
70. matrix-org/matrix-spec issue #1683 — the spec forbids thread roots that are replies; popular clients and servers allow them. Documents the contradiction with request and response payloads from /relations, including a maintainer assessment that the reference homeserver only checks for relation-type relationships and therefore accepts what the specification forbids. https://github.com/matrix-org/matrix-spec/issues/1683
71. MSC2716 — Batch-send historical messages. Allows a room creator to insert events into a room’s history that did not occur in it, marked with an historical property that the proposal itself describes as a hint to clients rather than a protocol-enforced distinction; requires a room version because it changes the redaction algorithm. https://github.com/matrix-org/matrix-spec-proposals/pull/2716
72. matrix-org/synapse issue #1263 — should redacted media be deleted too (SYN-216). The reference implementation’s own record of what redaction is: that it strips fields from events without affecting anything at the protocol level, that a redacted event is partially rather than wholly removed (“we nuke part of the event, we don’t delete it, we partially redact it”), and the maintainer assessment that “redact” was chosen over “delete” to avoid implying stronger confidentiality than the operation provides, “too bad they have abandoned that terminology in Element.” https://github.com/matrix-org/synapse/issues/1263
73. The Matrix ecosystem — Clients directory. The project’s own client list, including its “Featured clients” selection (“the most mature ones you can safely use”) and the per-project stability grades used in 5.9: Element Web/Desktop, Element X and Cinny listed Stable and featured; gomuks and iamb, the two interactive terminal chat clients, listed Beta; matrix-commander and matrix-commander-rs listed Stable but described as CLI apps “for sending and receiving”; and Miitrix, Syphon, gotktrix and Quadrix listed Obsolete. https://matrix.org/clients/
74. iamb — a Matrix client for Vim addicts. The most actively developed Rust terminal client with Vim keybindings, listed Beta on the project’s client directory. Created 8 August 2021; latest release v0.0.12, published 20 September 2026 — five years of development without a 1.0. Cited in 5.9 for the maturity claim. https://github.com/ulyssa/iamb
75. gomuks — a Matrix client written in Go. The longest-running Go terminal Matrix client; the project’s own directory describes it as “a terminal Matrix client written in Go” and grades it Beta, and the 1,700-star project is actively developed. Cited in 5.9 as the case where a healthy volunteer project still does not reach the project’s own “safe to use” bar. https://github.com/gomuks/gomuks
76. matui — a very opinionated Matrix TUI. A minimal Rust terminal client whose README states that room administration beyond moderation “is left to other clients” — a fair description of what every terminal client on this protocol has to concede. Created March 2023; latest release v1.0.2, published 20 September 2026; 125 stars. Cited in 5.9. https://github.com/pkulak/matui
77. weechat-matrix — WeeChat Matrix protocol script (Python). The Matrix plugin for WeeChat, IRC’s reference terminal client. Its README records that development “has moved to weechat-matrix-rs,” that the project “is in maintenance mode and will likely not be receiving substantial new features,” and that the reason was the “inherent limitations of WeeChat scripts.” Last commit July 2023. Cited in 5.9 as the compressed history of the whole client chapter. https://github.com/poljar/weechat-matrix
78. weechat-matrix-rs — Rust rewrite of the Python WeeChat Matrix script. The best-maintained Matrix terminal client code in existence, and the clearest statement of what the sync model costs a terminal user: its installation guide instructs that “the first connection can take a few minutes while the client syncs the account.” Cited in 5.9 as the primary record tying 1.2 and 5.4 to the client surface. https://github.com/poljar/weechat-matrix-rs
79. Element — The Matrix standard for independence and ownership. The marketing page’s own heading, “Trusted by secure organizations.”, the sentence naming “NATO, Space Force, the French Government and the German Bundeswehr”, and the twelve-logo wall beneath it, given in the page’s own image descriptions: HM Government, Försäkringskassan (the Swedish Social Insurance Agency), Dinum, Bundeswehr, BWI, United States Navy, Gematik, Dataport, United States Space Force, US Marines, hexagon.com, fedoraproject.org. The same page carries the assurance marks Cyber Essentials Plus, ISO/IEC 27001:2022 certification and an OpenChain ISO/IEC 5230 badge. The wall as evidence, and its elisions, are the subject of 4.4. https://element.io/en/matrix-benefits
80. Element — Defence and intelligence. The sector page’s heading, “Trusted by armed forces, alliances and partners”, and its customer wall: Ministry of Defence, US Navy, Bundeswehr, NATO, United Nations International Computing Centre, Raytheon, Roke, Boeing, Boxxe, Partner Force, Veilant. Also the two claims 4.4 sets against each other — the accreditation claim that “our self-hosted solution is accredited and deployed at SECRET and other classifications in multiple countries”, given without accrediting authority, scheme, scope, date or product identifier, and the self-hosting claim that US federal customers “run Element themselves on their own infrastructure at the necessary classifications, mitigating the need for FedRAMP certification”, alongside the offer of cross-domain solutions “between high-side and low-side environments”. https://element.io/en/sectors/defence
81. Element — Element Messenger for government and NGOs. The vendor’s own deployment descriptions: Tchap connecting “more than 300,000 civil servants across the French Government”, the Bundeswehr’s BwMessenger at “more than 100,000 active users”, and UNICC as a named customer replacing email and unsanctioned messaging. Cited in 4.4 as the public-scope account of the deployments the logo wall does not qualify. https://element.io/en/solutions/messenger
82. Element (2024). Senators implore Department of Defense to expand the use of Matrix. The vendor’s own description of NI²CE — “an experimental Matrix-based project that aims to complement existing NATO communication solutions with a secure Bring Your Own Device (BYOD) style messenger for ‘unclassified’ use” — with the senatorial letter’s request for an investigation into the DoD’s “failure to secure its unclassified telephone communications from foreign espionage, risking serious harm to U.S. national security”. Cited in 4.4; the ship count it is also cited for is not stated here but in source 54. https://blog.element.dev/senators-implore-department-of-defense-to-expand-the-use-of-matrix/
83. Wyden and Schmitt (2024). Letter to the Secretary of Defense regarding secure communications. The congressional record behind source 82: senators asking the DoD to expand its use of Matrix and to investigate its failure “to secure its unclassified telephone communications from foreign espionage” after Salt Typhoon, and asking what it can say about “the Navy’s use of Matrix”. Cited in 4.4 and the table as the only public, external source for a US military deployment figure. https://www.wyden.senate.gov/imo/media/doc/wyden-schmitt_dod_letter.pdf
84. Element — Forrester Wave landing page for Secure Communications. The sales page for the analyst report, carrying the third variant of the trust claim: “Trusted by the world’s most secure organisations.” Cited in 4.4 as evidence that the superlative is a marketing register rather than a fixed claim. https://try.element.io/forrester-wave-report-secure-communications
85. Matthew Hodgson (2024). Open source infrastructure must be a publicly funded service. The Foundation’s post written in the wake of the xz backdoor: that Matrix’s maintainership is “distinctly overstretched” while Matrix sits “at the heart of huge amounts of critical infrastructure, ranging from the Ukrainian MOD to NATO and at least 15 other countries and major international organisations”; that the funding gap is already visible as “a massive hole in funding for Matrix”; the diagnosis that “procurement departments want to have something concrete to procure as a one-off, rather than making an ongoing commitment to keep the project secure”, so they fund features and “ignore maintenance”; the ministry of defence’s refusal — “You have to understand, we’re responsible for taxpayer money here. We can’t just make a donation to your open source project.”; and the conclusion that “free and open source software has literally become shared digital public infrastructure”, so “FOSS maintenance should be funded by governments on behalf of the taxpayer. This funding should NOT be tied to specific feature development, but simply funding the core maintenance of the infrastructure.” Cited in 4.4 and the table. https://matrix.org/blog/2024/04/open-source-publicly-funded-service/
86. The Matrix Foundation (2024). Governing board: prospective members. A board paper written to recruit funding members, stating that “Element cannot afford $5M/y in this macro environment” and that “Many large deployments go live without contributing neither code, resources nor funding”, and recording that “Amdocs (who incubated Matrix) and Element (hiring the core team) shouldered most of the costs”. Cited in 4.4 as the strongest single admission that the largest deployments are non-paying. https://matrix.org/media/2024-01-governing-board-prospective-members.pdf
87. The Matrix Foundation (2025). Crossroads. The Foundation’s own account of its finances: 2024 revenue of $561K against $1.2M of operating cost in the first year it carried the full cost of operations, $283K of cryptocurrency donations liquidated, a $356K year-end deficit, an additional $610K needed to break even, and a $100K shortfall that would extend the runway by one month — alongside the bridging collapse, with bridges closing or scheduled for archival when the target was missed. Cited in 4.4 and the table. https://matrix.org/blog/2025/02/crossroads/
88. The Matrix Foundation (2025). Funding: homeserver premium accounts. The matrix.org homeserver moving to paid tiers because “[t]he alternative is to turn off the server”, the exposure of its “370k monthly active users”, and the finding that “none of the big players in the ecosystem have actually committed to one of the higher membership tiers”. Cited in 4.4 as the cost of being the operator of everyone’s account. https://matrix.org/blog/2025/06/funding-homeserver-premium/
89. The Matrix Foundation, FOSDEM 2024 — Opening up communication silos with Matrix 2.0 and the EU Digital Markets Act. The project’s own funding arithmetic, presented by its chief executive. The slide “Some Big Public Sector Matrix Deployments” plots “size of deployment” against “size of financial support to the Matrix core team in 2023” for Ukraine MOD, France (Tchap), gematik, NATO, UK Govt, US Govt, Poland MOD, Sweden, Bavaria Schools, Hessen Administration, NRW Schools, BwMessenger, BundesMessenger, openDesk and Phoenix Suite. The next slide states that there are “[l]ots and lots of large deployments not helping funding underlying dev”, that “‘Public Money For Public Code’ ⇒ Govts only want to fund new features”, and concludes that “Element ended up switching its development on Synapse to AGPL in order to sell AGPL exceptions to those who need them”. The closing ask: “much of github.com/matrix-org is written and maintained by the core team hired by Element, who donates their time to the project — please support them by buying enterprise Matrix deployments from Element if you’re a Government or Enterprise.” The same deck claims the Foundation “now runs entirely independently” and sets a £900K fundraising target. Cited in 4.4 and the table as the clearest statement of the funding model. https://archive.fosdem.org/2024/events/attachments/fosdem-2024-3345-opening-up-communication-silos-with-matrix-2-0-and-the-eu-digital-markets-act/slides/22568/2024-02-04_FOSDEM_DMA_with_Matrix_2_0_f7oic1B.pdf
90. The Matrix Foundation (2025). 2025 public annual report. The Foundation’s own summary that “[t]he main shadow on the picture has a financial shape, as the Foundation is still struggling financially”; the disclosure that “Element’s Platinum membership was supported by in-kind contributions and financial support in 2025, and thus doesn’t appear as revenue in financial reports”; the membership arithmetic, with the number of Silver members doubling but bringing only 30% more revenue “due to them mostly being small organisations in the Silver tier”, and after churning a Gold member “the one left (Automattic) now corresponds to 50% of our revenue”; the 2026 objective to “[b]uild financial independence from Element” by “[p]aying for the operational services they provide rather than have them as in-kind contributions for better clarity”; the WhatsApp bridge “on ice until funding is unlocked”; and the conclusion that “Whilst the wider world realises that Matrix is needed, it hasn’t concretised into proper support to our work yet.” Cited in 4.4 and the table. https://www.matrix.org/foundation/reports/2025%20Public%20Annual%20Report.pdf
91. Digital Public Goods Alliance registry — Element profile. The verified digital public good listing: “DPG since 09.06.2026”, owner “Element Creations Ltd”, licence AGPL-3.0, origin country United Kingdom; the self-reported “organisations using it” list of government and public-sector deployments beginning Australia, Austria, Belgium, Canada, Croatia, Estonia, Finland, France, Germany, Greece, Italy, Luxembourg, Netherlands, noted as “self-reported and updated annually”; the self-reported SDG justifications about operating sovereign communication infrastructure “without dependence on proprietary vendors” and against “vendor lock-in”; and the platform-independence disclosure of Scalar, a “proprietary integration manager for bots, bridges, and widgets”, and Firebase Cloud Messaging for push. Cited in 4.4 as the project’s own summary of itself. https://www.digitalpublicgoods.net/r/element
92. Peter Bright (2019). French government’s secure chat app left door open to outsiders. Contemporary reporting on the Tchap launch-day flaw, including the project’s confirmation to the press that “there was no security audit on their solution.” Cited in 4.4 alongside source 93; the disclosure and same-day remediation are noted there as evidence of maintainer conduct, not concealment. https://arstechnica.com/information-technology/2019/04/french-governments-secure-chat-app-left-door-open-to-outsiders/
93. The Matrix Foundation (2019). Security update for Sydent 1.0.2. The project’s own technical account of the Tchap launch-day flaw: that sydent “uses python’s email.utils.parseaddr function to parse the input email address before sending validation mail to it, but it turns out that if you hand parseaddr an malformed email address of form [address]@c.com, it silently discards the @c.com prefix without error”, so that a validation token requested for one address is sent to another while the address given is “marked as validated”. Note that the example addresses on the page are behind anti-spam obfuscation, hence the elision in 4.4. https://matrix.org/blog/2019/04/18/security-update-sydent-1-0-2/
94. TNW (2026). France’s ‘sovereign’ messenger Tchap was breached, and officials and the hacker disagree on how badly. The 2026 incident: ANSSI detecting a compromise of Tchap on 7 June, DINUM publishing an incident notice and blocking the account involved, the government’s account that the attacker “got in by hijacking a legitimate user account, a compromise of credentials rather than of the system itself”, the exposure limited to the public chat rooms any user can join, and the unverified attacker claims of 73,000 accounts and 643,000 messages, with “[n]one of the big numbers” confirmed. Cited in 4.4 and the table. https://thenextweb.com/news/tchap-france-sovereign-messenger-breach
95. IT for Business (2026). Tchap: fuite de données confirmée pour la messagerie sécurisée de l’État. French trade-press confirmation of the 2026 incident: DINUM’s communiqué that “le 7 juin 2026, l’ANSSI a détecté une compromission du service Tchap… à la suite d’une usurpation de compte”, apparently originating “dans l’environnement de l’Education Nationale”, the CNIL being notified, the ~13.5GB downloaded as the attacker’s claim, and the YesWeHack bug bounty launched six months before the July 2025 circular calling for Tchap to be generalised. The same article notes that Tchap had already revealed “une première faille permettant de contourner les mécanismes d’authentification” at launch. Cited in 4.4 and the table. https://www.itforbusiness.fr/tchap-fuite-de-donnees-confirmee-pour-la-messagerie-securisee-de-letat-104725
96. TechCrunch (2021). Element, a messaging app built on the decentralized Matrix protocol, raises $30M. The funding itemised for 4.4: $5M from Status in 2018, $8.5M in a 2019 Series A, $4.6M from Automattic in 2020, and $30M in a July 2021 Series B led by Protocol Labs and Metaplanet, with Automattic and Notion participating, “$48 million” in total. The same report gives Tchap as covering “some 5.5 million civil servants”, against the “more than 300,000” on Element’s current site. https://techcrunch.com/2021/07/27/element-a-messaging-app-built-on-the-decentralized-matrix-protocol-raises-30m/
97. Notion Capital — Element, portfolio entry. The lead investor’s own description of the company’s origins, used in 4.4 alongside source 86 to establish that the core team sat inside a corporate incubator before it was a company. https://www.notioncapital.com/portfolio/element
98. The Matrix Foundation (2023). The Matrix holiday update 2023. The Foundation’s statement that Element “can no longer financially afford to donate its work on Synapse and other server components to the Matrix Foundation under the permissive Apache licence”, the resulting AGPL relicensing, and the same post’s record of what the squeeze cost elsewhere: P2P Matrix, Low Bandwidth Matrix and Account Portability paused, Element-funded Dendrite work stopped, and the Third Room team disbanded. Cited in 4.4. https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/
99. The Matrix Foundation (2025). Dispelling myths. The Foundation’s statement that the move to monetise the matrix.org homeserver, “which is indeed operated under contract by Element”, should not be read as evidence that the Foundation is in trouble. Cited in 4.4 for the operator relationship, and noted there as the project’s own account. https://matrix.org/blog/2025/06/dispelling-myths/
100. Famedly / Conduit (Matrix homeserver). The upstream project that all three Rust forks in 1.3 descend from, and the record that its hosting is not incidental: the repository states that “Server hosting for conduit.rs is donated by the Matrix.org Foundation,” lists FUTO, Famedly, Prototype Fund (DLR and German BMBF) and individuals as supporters, and carries the project’s own Beta definition — “you can join and participate in most Matrix rooms, but not all features are supported and you might run into bugs from time to time.” Cited in 1.3 as the origin of the lineage and as evidence that the Foundation funded the original. https://gitlab.com/famedly/conduit
101. conduwuit — a well-maintained fork of Conduit (archived). The project’s own README, now frozen on an archived repository, and the single richest primary source for 1.3. It states the reason for the fork — to fix “the majority of upstream Conduit bugs or UX issues that are taking too long to be resolved, or unnecessary Matrix or developer politics halting simple things from being merged or fixed, and general inactivity” — gives the timeline (“conduwuit has existed since around November 2023, but only became more publicly known in March/April 2024”; the repository’s own creation date is 26 November 2023), records that it “has no external funding,” and concedes that the differences page became “heavily outdated” and that there is no seamless migration from Synapse or Dendrite. Its first line now declares Tuwunel “the ONLY official successor to conduwuit, no other project or fork is,” adding that anyone claiming otherwise is “wrong and spreading disinformation.” The repository is marked archived; its final release is v0.5.0-rc4, published 9 April 2025. Also the source for the withdrawn upgrade path: Conduit migration “no longer works”, debugging Conduit “is not one of our interests,” and a Conduit user upgrading “will have to wipe and reset your database.” https://github.com/girlbossceo/conduwuit
102. This Week in Matrix, 26 April 2024. The project’s own newsletter item on conduwuit, establishing that the Foundation was publicly featuring the fork within months of its creation. Cited in 1.3 for the fork’s rise; the archived README links to this issue as the moment conduwuit “became more publicly known.” https://matrix.org/blog/2024/04/26/this-week-in-matrix-2024-04-26/
103. matrix-construct/tuwunel — issue 22, “Upcoming Announcements & Project Information.” The successor project’s own transition record, opened days after conduwuit’s final release: the note that it follows “the abrupt termination of conduwuit preceding the holiday weekend”, the tag inventory recording that “v0.5.0 is the last (un)-official commit of conduwuit” and that afterwards “the project and binary has been renamed to tuwunel,” with the old CONDUIT_ and CONDUWUIT_ environment variables still recognised. Cited in 1.3 for the mechanics of the succession; the date of the project’s end is taken from source 101. https://github.com/matrix-construct/tuwunel/issues/22
104. This Week in Matrix, 5 December 2025. The project’s own newsletter item on Tuwunel, including the release announcement that it “is now deployed at scale serving the citizens of Switzerland in production,” the directory’s description of it as the “Enterprise successor to conduwuit,” and the funding appeal that follows. Cited in 1.3 as the point at which the Conduit lineage acquired an institutional user and a sponsor. https://matrix.org/blog/2025/12/05/this-week-in-matrix-2025-12-05/
105. continuwuity — introduction. The community fork’s own documentation, the counterpart to the archived conduwuit README: “It’s the official community continuation of the conduwuit homeserver,” formed because “[t]he original conduwuit project has been archived and is no longer maintained.” Its migration page is the load-bearing detail for 1.3 — “Conduwuit: Yes” but “Conduit: No, database is now incompatible,” alongside the same verdict for Grapevine, Dendrite and Synapse. The project’s stated development model is the opposite of the one that ended its parent: an open community project welcoming contributions from anyone. https://continuwuity.org/introduction
106. The Matrix ecosystem — Servers directory. The project’s own server list, the counterpart to the clients directory used in 5.9, and the evidence 1.3 is built on: it lists continuwuity (Stable) as “a community driven 2nd degree fork of Conduit,” Tuwunel (Stable) as the “Enterprise successor to conduwuit,” conduwuit (Obsolete) — still described in the present tense as “a well-maintained, hard-fork of Conduit” — and Conduit (Beta), all four simultaneously, alongside Synapse Pro, Synapse, Dendrite and eight further implementations marked Obsolete or Alpha. https://matrix.org/ecosystem/servers/

#GlossaryAbbreviations, and what they stand for

Matrix and the literature around it are dense in acronyms, and some of them — the defence and public-sector ones especially — are not self-explanatory. Every abbreviation used above is dotted-underlined where it appears; pointing at one on screen gives its expansion, and the table below is the printed equivalent, so the document reads the same on paper and in a PDF. Terms that are proper names rather than initialisms are listed too, where a reader is likely to trip over them.