Short answer: self-hosted Matrix is not simply “private chat on your own server.” A homeserver stores account and room data, synchronizes events with other homeservers, and participates in a distributed room whose state is eventually consistent. Matrix end-to-end encryption protects message content when clients use it correctly, while homeservers still handle important metadata and operational functions. Synapse implements the protocol, but its release notes show a living system: stable features, experimental MSC support, performance fixes, security maintenance, and compatibility work all move at different speeds.
Start with the ownership boundary
Matrix separates user service from room ownership. The Matrix specification describes a homeserver as the place where clients synchronize account and communication data. When users from multiple servers participate in a room, room data is replicated across those participating homeservers and synchronized as an event graph. The room is not owned by one server merely because its identifier contains a domain.
That design is the source of both the autonomy and the complexity. An operator can own the registration policy, local accounts, database, media store, backups, upgrade process, and federation policy for one homeserver. The operator cannot unilaterally define the complete behavior of a federated room, erase every copy of an event, or assume that another server has the same moderation policy. A room's practical behavior is the intersection of protocol rules, room state, participating servers, clients, and administrators.
Federation also means that a homeserver is not just a web application with a login page. It must authenticate and authorize server-to-server traffic, resolve and cache signing keys, exchange persistent and ephemeral events, handle retries and backlogs, and maintain a database that can converge with remote state. The Server-Server API describes PDUs, EDUs, queries, signing, and delivery responsibilities. Those are the reliability boundary lines an operator must monitor.
Specification versus Synapse implementation
The specification is the interoperability contract. It defines client-server and server-server APIs, event formats, authorization rules, room versions, signing, encryption interfaces, and the conditions under which an event is accepted. The current specification documentation includes Matrix 1.19-era material and room version 12. It also makes clear that a room's event graph, authorization state, and federation behavior are not the same thing as a single server's local database view.
Synapse is an implementation of that contract. The current canonical source is Element's element-hq/synapse repository, which describes Synapse as a Matrix homeserver written in Python/Twisted with Rust components. The repository's current branch and release history should be treated as the operational source for Synapse behavior; an old archived repository is not the current code reference.
Implementation labels matter. A change can be stable, optional, experimental, deprecated, or merely under development. A Matrix Spec Change (MSC) is not automatically a universally deployed protocol feature, and a Synapse pull request is not a released behavior. For a deployment decision, read the target Synapse release notes, configuration documentation, upgrade notes, and client interoperability status together.
What encryption protects, and what it does not
Matrix encryption is a client-side protocol layer, not a synonym for “the homeserver sees nothing.” The Matrix implementation guide documents Olm and Megolm ratchets, device keys, room encryption state, encrypted events, and encrypted attachments. In a correctly configured encrypted room, clients encrypt message content before it is sent and recipient devices decrypt it.
A homeserver still brokers synchronization and stores data required by the protocol. It can generally observe account and device identifiers, room participation, event timing, routing relationships, traffic volume, and other metadata. It may store ciphertext and encrypted media, but ciphertext is not the same as invisible operation. Retention, backups, logs, push services, endpoint databases, key management, device verification, and recovery workflows each create a separate security boundary.
Encryption is also conditional. A room can be unencrypted; a client can mishandle verification; a user can approve an untrusted device; a device can be compromised; and a server or client can contain a bug. Historical reporting by Ars Technica described patched Matrix vulnerabilities that could let malicious homeservers decrypt or spoof messages. That is not evidence that current Matrix encryption is broken; it is evidence that the guarantee depends on deployed implementations receiving security fixes and users maintaining trustworthy devices.
Practical test: describe the threat model in terms of content, metadata, devices, backups, and administrators. “Encrypted” answers only part of that list.
Federation is a trade-off, not a feature toggle
Open federation gives users a larger addressable network and lets independent homeservers communicate without a central account directory. It also expands the set of remote peers, remote software versions, policies, abuse patterns, and network failures that can affect local users. A closed or allow-listed federation reduces exposure but also reduces interoperability and changes the administrative model.
| Choice | Operational benefit | Cost or risk |
|---|---|---|
| Open federation | Broad reach and fewer invitations to manage manually. | More remote peers, media, spam, policy differences, and incident surface. |
| Allow-listed federation | Predictable partner set and tighter traffic policy. | More administration; users cannot freely reach the wider network. |
| Single homeserver rooms | Less remote synchronization and simpler governance. | Less resilient to a local outage and less federated in practice. |
| Federated rooms | Multiple servers can hold room data and continue participation across providers. | State convergence, moderation coordination, and remote delivery need active operations. |
Server ACLs are one protocol control for rejecting a server from a room, but they do not replace abuse response, rate limits, media policy, account lifecycle controls, or a clear incident process. The specification says denied servers must receive a forbidden response at protected federation endpoints; the operational question is who maintains the policy and how quickly it changes when a peer becomes unsafe or unreliable.
Moderation under end-to-end encryption
Matrix moderation is layered. Room power levels can govern who may send events, change room state, invite users, kick or ban members, and redact content. Server ACLs can reject a server. Reports and ban lists can feed human or automated review. The Matrix moderation documentation describes power levels, reports, redactions, bans, and tools such as Mjolnir.
Encryption changes what a server can inspect. A homeserver cannot reliably classify the plaintext of an encrypted message merely by receiving the event. Moderation therefore shifts toward membership controls, user reports, trusted moderators, client-side signals, room policy, server reputation, and tooling that acts on identifiers or reports rather than indiscriminate content inspection. This can be an appropriate privacy trade-off, but it is not a promise of hands-off safety.
Moderation also has a scope problem. A local administrator can protect local users and rooms under its control, while a remote homeserver may continue to host its users' copies or participate in other rooms. Federation makes “remove this user everywhere” a much stronger claim than “deny this user here.” Policies should state which rooms, users, servers, media, and retention stores they cover.
What the current Synapse history shows
As of September 10, 2026, the GitHub release history lists Synapse 1.160.0 as the latest stable release, published September 2. The same history lists 1.161.0rc1, published September 9. A release candidate is a testable pre-release, not the same operational statement as a stable release.
Synapse 1.160.0 included optional support for MSC4262 profile updates for Sliding Sync, experimental support for MSC4502 targeted and unrestricted room member queries, a fix for stalled presence and to-device streams, thumbnail behavior for transparent WebP, and device-list performance work. The release notes say the Sliding Sync profile feature defaults to disabled and is limited to local users in the sync results. Those qualifiers are part of the feature, not footnotes to omit from deployment notes.
Earlier change history shows the same pattern. Synapse 1.158 introduced room version 11 as the default and added other protocol and module changes; later releases continued compatibility, database, packaging, and security work. Synapse 1.157.2 was explicitly a security release with several advisories. The useful conclusion is not a maturity score: it is that a production homeserver needs a release watch, a tested upgrade path, and a way to distinguish security releases from ordinary feature updates.
The repository is also changing between releases. For example, a September 8 commit on the develop branch reports a large speed-up for recursive relation queries and describes a failure mode in which those requests could starve delayed events and cause MatrixRTC calls to drop. That is valuable engineering evidence, but it is a development-branch change until it appears in a released version. Do not promise that an unreleased fix is present in a stable deployment.
Reliability is a systems problem
Messaging reliability is more than “the process is running.” A homeserver can answer login requests while federation queues are delayed, device-list updates are stale, media storage is full, workers are overloaded, or a database is approaching failure. The distributed model adds another dimension: a local healthy status does not prove that remote servers can resolve the name, validate keys, connect over HTTPS, or deliver events back.
- Federation reachability: verify DNS, certificates, well-known discovery where used, federation endpoints, signing-key retrieval, and remote delivery.
- Database health: watch latency, locks, connections, replication or worker dependencies, disk growth, and restore procedures rather than only process uptime.
- Event and device backlogs: track outbound federation, presence, to-device, device-list, and room synchronization lag.
- Media and encrypted attachments: set size, retention, quarantine, backup, and storage policies. Encrypted media still consumes resources and can carry abuse or availability risk.
- Upgrade discipline: stage releases, read upgrade notes, test rollback assumptions, and prioritize security releases without treating every release candidate as production-ready.
- Recovery: test restoration of the database, signing keys, media, configuration, and secrets as a complete system. A database-only backup does not recreate a working homeserver.
Independent coverage can help expose this distinction. In 2026, InfoQ reported community scrutiny of a serverless Matrix homeserver demonstration, including questions about federation and incomplete protocol behavior. The lesson is broader than that demonstration: a login screen or a successful local message is not proof of federation compatibility, encryption completeness, or production reliability.
A sober self-hosting decision framework
- Define the trust boundary. Decide which metadata a homeserver operator, hosting provider, administrators, clients, backups, and remote servers may see.
- Choose federation deliberately. Start with open, partner-only, or no federation based on the communication need and abuse capacity, not on a generic privacy slogan.
- Specify the client baseline. Encryption, verification, cross-signing, key backup, push behavior, and encrypted media support vary by client and version.
- Map moderation authority. Document room administrators, server administrators, ban-list ownership, report intake, escalation, and what “removal” actually means.
- Operate to a release policy. Follow the canonical Synapse repository and release notes, pin versions, test upgrades, and separate stable, experimental, and development behavior.
- Measure user-visible health. Test login, sync, sending, federation, device verification, media, search where enabled, and recovery—not only HTTP status.
Limitations and what this article does not claim
This is a technical decision framework, not a security audit or a Synapse deployment guide. It does not claim that Matrix is private by default, that E2EE hides metadata, that federation guarantees delivery, that self-hosting improves uptime, or that a particular Synapse release eliminates all vulnerabilities. The cited release, specification, and project pages change over time; verify the exact version, client, room version, and configuration before making a production decision.
The release and commit observations above are a snapshot taken on September 10, 2026. A release candidate, a develop-branch commit, a project roadmap item, a blog announcement, and a shipped stable behavior have different evidentiary status. Treat them accordingly.
Sources and further reading
- Matrix Specification — protocol overview, event graphs, rooms, federation, and API references.
- Matrix Server-Server API — federation transport, PDUs, EDUs, queries, signatures, and server ACLs.
- Matrix Room Version 12 — current room-version rules and authorization changes.
- Matrix end-to-end encryption implementation guide — Olm, Megolm, device keys, encrypted events, and attachments.
- Matrix community moderation documentation — power levels, reports, bans, ACLs, and moderation tooling.
- This Week in Matrix, September 4, 2026 — Synapse 1.160.0 announcement and community-reported ecosystem updates.
- Element's canonical Synapse repository, its release history, and develop-branch commits.
- Ars Technica: patched Matrix E2EE vulnerabilities — independent historical security reporting.
- InfoQ: scrutiny of a serverless Matrix homeserver demonstration — independent reporting on the difference between a demo and complete protocol behavior.