Summary: The Matrix spec team accepted the entire MatrixRTC suite this week — MSC4143 (real-time communication over Matrix), MSC4195 (LiveKit transport), MSC4196 (the calling application), MSC4354 (sticky events), plus the four sliding-sync extension MSCs — which are the pieces of Matrix 2.0. Element's announcement is the operator-facing version: group voice and video that is E2EE by default, self-hostable per server, cross-vendor (connect2x's Tammy already implements it independently, and Element and Tammy called each other live at the Matrix Conference in Malmö). The part every community operator should actually take away: in the federated SFU model, a server that wants to start calls should run its own selective forwarding unit — so the SFU becomes the next service your community runs, because if your members call without one, their media and its metadata relay through somebody else's. The honest ledger too: "world's first" is vendor phrasing, the ~50-participant capacity figure is Element's and unbenchmarked, and the features that undermine E2EE (recording, transcription, call captions, SIP) went deliberately into the commercial ESS Pro product. Separately, Synapse 1.164.1 (October 28) carries the security bumps this site's October 22 eMudhra post said were coming for your server-side stack: certifi and rustls-webpki updated to distrust the compromised eMudhra intermediates, a msgpack memory-exhaustion fix reachable through the public room list API, and a pillow bump. If you run Synapse, that release closes your slice of the eMudhra cleanup.

When this site drew the homeserver map in July, the answer for community deployments was which homeserver to run. The missing piece of that picture was never server software — it was calls. Messaging federates fine; every community deploying Matrix eventually gets asked "and what about Zoom?". This week that gap got a real answer, and it arrived the way the good ones usually do: as accepted spec work with an independent implementation able to demonstrate interop, not as a product announcement alone.

What "accepted" actually means this week

The October 30 spec update reports a blur of acceptances from the Matrix Conference hackathon (Malmö, October 20–23): MSC4143 (MatrixRTC — real-time communication over Matrix), MSC4195 (LiveKit transport), MSC4196 (voice and video calling application), MSC4354 (sticky events — the state mechanism MatrixRTC's membership signalling rides on), and the four sliding-sync extension MSCs (receipts, account data, E2EE, to-device messages). All but two stragglers — federated scheduling among them — are now in, and Matrix 2.0 follows shortly, per the Foundation.

Translation for non-spec-wonks: MatrixRTC stopped being an Element product feature and became part of the open standard's future. "Accepted" means the MSC team merged it as accepted — it lands in the next spec release, and server implementations now have a stable target to build toward. Synapse already advertises v1.16 and v1.17.

The independent-implementation test is the part worth trusting. connect2x's Tammy implements MatrixRTC on its own, and Element demoed Element Call and Tammy placing calls to each other at the conference — cross-vendor calling through the open standard, which is the thing that separates "spec" from "vendor protocol with a spec-y name." Conference recordings are up if you want the deeper cuts.

The SFU is the next service your community runs

The architecture Element published is the part that changes deployment checklists:

  • Each Matrix server can run its own conferencing server — a selective forwarding unit (SFU). Element Call currently uses LiveKit; the standard does not force that choice.
  • A server that wants to start calls effectively needs an SFU. Participants without one borrow another participant's SFU to publish through.
  • Calls can be pinned to a chosen set of SFUs to reduce points of failure.
  • Users receive media directly from the SFU publishing it.

Element frames "you don't need your own SFU to join" as a rollout simplification, and it is. Read it with the sovereignty layer intact, though: E2EE covers content — the SFU relays encrypted frames and cannot hear the meeting — but the SFU still sees and carries everything the content plane can't hide: who is connected to whom, when, from where, and how much bandwidth your meeting consumes. If nobody in your community runs an SFU, your members' calls route through whatever other participant's SFU picked them up. That is somebody else's server doing the work, and somebody else's logs holding the shape of your meeting.

The the chat argument, applied to real-time media: a homeserver that fits in 256 MB was the bar for communities; an SFU is a genuinely bigger service — media relay, TURN, port ranges, capacity headroom. Not every community needs it next week. But "federated calling" and "your community owns its calling" are different claims, and the SFU is where they diverge. Run one before you invite outside participants.

What shipped around it, and what it costs

Element Call is being merged natively into Element Web and Desktop — no more widget-in-a-frame, and the standalone call.element.io single-page app is headed for retirement. Worth knowing for anyone currently self-hosting the old Element Call: the standalone app used basic shared-key encryption, while the native integration keys E2EE to your real Matrix identity. That is a real upgrade and a migration to schedule, not a flag flip. Mobile clients are replacing the embedded web view with native MatrixRTC, and both platforms are converging on a Rust SDK (matrix-rust-rtc); Element Web is moving off the old JavaScript SDK as part of the same Rust rewrite.

Capacity numbers, stated plainly: Element says about 50 calling participants on ESS Community and other Synapse deployments, about 200 on its commercial Synapse Pro. Those are the vendor's figures, not benchmarked facts — treat them as order-of-magnitude.

The honest split: end-user features stay open source. Features that undermine E2EE — call recording, captions, transcription, SIP interop — are deliberately in ESS Pro, because doing them in the open stack means shipping server-side plaintext handling. That is the privacy-correct design, and it also means the open deployment has no recording story: communities that must record meetings are choosing between the commercial product or an honest "our calls aren't recorded," and most meetings didn't need recording anyway.

Two cautions from the announcement, because Element's phrasing runs hotter than the evidence: "the world's first decentralised, E2EE, multiparty VoIP protocol" is a superlative with asterisks (multiparty VoIP existed before; what's new is the open-standard definition plus federation plus default E2EE — that is the defensible claim), and "easy to deploy" describes ESS Community's packaging, not the underlying mechanics of an SFU fleet. Also, if you run Continuwuity per the July map, check its changelog for MatrixRTC endpoint support before promising members calls — the vendor numbers here are Synapse's.

Element is already previewing the next transport: cSFU, a new SFU and VoIP stack that isn't even WebRTC, demoed at the conference with DINUM's Visio. Transport pluralism is the point of the design — it's the same bet XMPP and email made, and it's the difference between a standard and a product ecosystem.

Synapse 1.164.1: the eMudhra cleanup you still owe

This site's October 22 post on the eMudhra intermediates — private keys that were numbers you could type, one of them being 4 — ended with "the server-side cleanup is yours." Here is the homeserver slice of that cleanup: Synapse 1.164.1 (October 28) bumps certifi and rustls-webpki to distrust the compromised eMudhra intermediates, so the Python trust store inside your Synapse finally stops trusting certificates chained to those keys. If you run Synapse and didn't individually pin your dependency trust stores, the upgrade is the patch.

Also in that release, one issue worth singling out: a msgpack bump fixing a memory-exhaustion problem reachable through the public room list API — the kind of unauthenticated resource exhaustion that hits small self-hosted servers hardest, since they run the most exposed surfaces with the least headroom. Plus a pillow bump (media pipeline) and a disk-hygiene fix: media uploads that exceed media_upload_limits no longer leave orphaned files behind — quietly useful for anyone running a long-lived homeserver with a full-disk alert.

Credit where the pattern deserves it: October's Gitea, Keycloak, and Nextcloud advisories each shipped with release notes that named none of the security content, and this site spent most of a month documenting that gap. Synapse's changelog, by contrast, says "we've been busy this week addressing the onslaught of security advisories reported in our dependencies... update as soon as you can." That is what a security release note looks like after you scrub the marketing out of it.

Where this leaves a community deployment

The pieces, in order of what to do: upgrade Synapse to 1.164.1 (the eMudhra trust and msgpack fixes are current, not future); decide whether group calling is actually on your community's list — if yes, budget the SFU as real infrastructure with real metadata, not a sidecar container; watch your homeserver's MatrixRTC support land and migrate off the standalone call widget when your client stack ships the native path; and ignore the retirement of call.element.io until you're ready to move, since it keeps working in the meantime.

For the map-keepers: matrixrooms.info's census counts 20,477 discovered federateable servers, 4,077 of them publishing room directories (19.9%). Among online servers, Synapse holds 76.6%, and the Rust continuations — Continuwuity at 9.6%, Conduit at 2.5%, Dendrite at 1.3% — now account for over 13%. The landscape shifted in July and kept shifting; the calling layer just gave it something new to shift toward.

One closing note on sustainability, because the values matter more than the protocol news: the Foundation funds the spec work on donations while governments deploy Matrix at national scale — the Register's conference coverage named the funding gap directly, and Computer Weekly profiled Luxembourg's sovereign service and Austria's doctors moving off email as the case studies. The communities that benefit most from a standard are rarely the ones funding it; if your community's Matrix deployment works, the maintenance fee is upstream contributions or donations — that is how the stack stays owned by nobody.