Last week I wrote about the Matrix homeserver landscape — which server to run, and why Continuwuity is the practical choice for community deployments. This week the protocol itself moved. Matrix 1.19 shipped on July 8, and it includes a feature that was broken for five years: encrypted room history sharing.

The Problem

Matrix has supported end-to-end encryption since the beginning. Encrypted rooms work. Messages are encrypted on your device, only recipients with the right keys can decrypt them, and the server never sees plaintext. This is the reason you'd choose Matrix over Slack or Discord for a community that cares about privacy.

But encrypted rooms had a usability gap that made them impractical for many community use cases. When a new member joins an encrypted room, they can't read messages from before they joined. The decryption keys were shared only with devices that were present at the time. New keys are generated periodically (Megolm sessions rotate), so even existing members can lose access to older messages if their session data is purged.

For a fire hall or town office using Matrix as their primary communication tool, this is a real problem. A new volunteer joins the team channel and sees... nothing. Every conversation that happened before they arrived is invisible. They can see new messages going forward, but the institutional memory — decisions, discussions, context — is locked behind encryption keys they don't have.

Unencrypted rooms don't have this problem. History visibility settings (world_readable, shared, invited, joined) control what new members can see, and the server serves plaintext events. Encrypted rooms have the same visibility settings, but they're meaningless without the keys to decrypt what the server shares.

What Existed Before — And Why It Was Removed

Matrix actually had encrypted history sharing about five years ago. MSC3061 proposed a mechanism for sharing historical keys with new room members. It passed Final Comment Period and was implemented.

Then a security disclosure in October 2024 revealed shortcomings in the implementation. The details are in the Matrix Foundation's security disclosure for matrix-js-sdk and matrix-react-sdk. The core issue: the original implementation didn't carefully enough specify which devices it was safe to share keys with, and it sent keys via individual to-device messages — one message per key. An attacker who could intercept or manipulate to-device traffic could potentially access historical encryption keys they shouldn't have.

The feature was pulled. Encrypted rooms went back to the "no history for new members" state while the cryptography team at Element worked on a proper fix.

What MSC4268 Does Differently

The new proposal, MSC4268, addresses both problems:

Device safety specification. The proposal explicitly defines which devices are safe to share keys with. Rather than trusting any device that claims membership, it checks device verification status and trust levels. A device must meet specific criteria before historical keys are shared with it.

Bulk key-sharing format. Instead of sending a separate to-device message for each key, the new implementation specifies a format for bulk-sharing keys. One message carries many keys. This reduces the surface area for interception and makes the protocol more efficient — important for rooms with long histories and many key rotations.

The result: a new member joins an encrypted room with shared or world_readable history visibility, and the client receives the historical decryption keys it needs. The member can read past conversations. The keys are shared safely, with verified devices, in bulk.

Custom Emoji — MSC2545

The other headline feature in v1.19 is custom emoji and sticker packs (MSC2545). This proposal has 603 comments — the most commented MSC as of the release — and has been in development for over six years.

Clients like FluffyChat, Cinny, and Nheko have supported the proposal through its iterations. Now it's in the spec, which means all clients can interoperate with stable identifiers for image packs.

For community deployments, this is less critical than encrypted history sharing, but it's the kind of feature that matters for adoption. A community that's used to Slack's custom emoji or Discord's sticker packs gets the same capability in Matrix, federated, without a vendor.

What This Means for Community Deployments

If you deployed Matrix for a community before v1.19 and ran into the "new members can't see history" problem, the workaround was to run unencrypted rooms for anything that needed historical visibility. That meant choosing between privacy and usability. Communities that needed both — a town office discussing personnel matters, a community organization with sensitive deliberations — had to pick one.

With v1.19, you can run encrypted rooms with shared history visibility and new members get access to past conversations. You get both. This removes the main argument against using encrypted Matrix rooms for community communication.

To use it:

  • Your homeserver needs to support v1.19. Continuwuity v26.7.x supports the current spec. Synapse and Dendrite, both in maintenance mode, have received compatibility updates.
  • Your clients need to support MSC4268. Element's clients have it — their blog post covers the implementation. Check other clients' release notes.
  • Set the room's history visibility to shared (the default for new rooms) or world_readable if you want anyone who can find the room to read history.

The Broader Pattern

The encrypted history sharing story follows a pattern worth noting for anyone deploying FOSS infrastructure. A feature ships. A security flaw is found. The feature is pulled. The community fixes it properly. Five years later, the fixed version lands in the spec.

This is how FOSS projects handle security — visibly, with disclosure, with the fix going through the same spec process as the original. The contrast with proprietary platforms is the point. When a proprietary messaging platform has a vulnerability in a feature, you find out when the vendor's PR team decides you find out, and the fix lands in an update with a generic "security improvements" changelog entry.

Matrix's process is auditable. The original MSC, the security disclosure, the replacement MSC, the spec PRs, the client implementations — all public, all traceable. For a community deciding whether to trust a platform with their communications, that auditability is the feature. Encrypted history sharing working correctly is a bonus.

Spec Release Cadence

Matrix 1.19 includes 6 MSCs across the spec since v1.18 in March 2026. The release cadence has settled to roughly one spec release per quarter. v1.18 was March 26, v1.19 was July 8. The Matrix Foundation also announced The Matrix Conference, scheduled for October 20-23 in Malmö, Sweden.

For operators, the quarterly cadence means you should track spec releases and check your homeserver's compatibility with each one. Continuwuity's development on Forgejo makes this easy — release notes are published with each tag, and the CI badges track spec compliance.

The Matrix Authentication Service (MAS) continues to mature — v1.19 brings provisioning API support, synced email bindings, and MSC3824 SSO redirect-action forwarding. For community deployments using Keycloak or another OIDC provider, MAS is worth watching as a Matrix-native authentication option that may simplify the SSO stack over time.