At FOSDEM 2026, members of Element’s VoIP team - Robin Townsend, Timo Kandra and Valère Fédronic - presented a deep dive into the future of real time communication on Matrix.
Their talk gave an update on MatrixRTC, Matrix’s framework for bringing voice, video, and other live, interactive experiences directly into rooms. Their contributions to Matrix enable everything from large-scale calls and collaborative tools to multiplayer games, virtual worlds, and entirely new ways for people to interact in real time.
Watch the whole presentation
We’ve been working on MatrixRTC as part of our work at Element, to build the foundations for large-scale, secure VoIP solution into matrix. This work is done by the same team that is behind Element Call. Element Call, the VoIP part of Element, sits on top of MatrixRTC.
Matrix has traditionally focused on persistent, asynchronous messaging. Real time communication (sub 100ms), however, introduces a very different set of requirements. It demands low latency, flexible participation, and should be ephemeral. At the same time, it must preserve Matrix’s core principles of decentralisation, federation, and security.
Historically, Matrix clients only supported 1:1 peer-to-peer WebRTC calls, using Matrix rooms primarily for call-oriented signalling and persisting what was effectively ephemeral state into room history. As calls grew larger and use cases expanded beyond simple voice and video, it became clear that real time communication needed first-class support in the Matrix protocol itself, with the flexibility to support multiple use cases beyond 1:1 calls.
MatrixRTC is our attempt to make real time applications native to Matrix, striking a balance between decentralisation and the practical demands of scalable, low-latency, end-to-end encrypted media and data exchange. Through concrete demos and implementation details, we showed how this approach enables entirely new classes of applications, including calls, games, virtual worlds and collaborative tools.
MatrixRTC introduces the concept of slots, which allow room administrators to add real time communication features to their rooms. These slots can be anything from voice or video calls to 3D virtual worlds or multiplayer games. Each slot combines an application - which specifies the type of data participants exchange - and an identifier, allowing multiple parallel sessions in the same room.
The first application we’re adding to the specification is m.call, which covers basic voice and video calls. But third-party apps are fully supported, enabling developers to create custom experiences like virtual simulations or collaborative games.
Slots are managed via state events, ensuring that they are persistent, authorised, and can be moderated by room admins. When participants want to join a slot, they connect by sending membership events and publish their media over a chosen transport. A transport in this context is a WebRTC SFU (Selective Forwarding Unit). Currently supported is the LiveKit SFU. FullMesh WebRTC or a websocket solution are also considered while designing with MatrixRTC.
Other features, like delayed events, notifications, and encryption, are also part of the specification. For deeper technical details, past Matrix Conference talks and the Matrix Spec Proposals repository are excellent resources.
It is essential to provide a good experience before joining a session. A client should be informed immediately via sync about any ongoing MatrixRTC session. To avoid polluting room state with this information, sticky events are introduced. These events are ephemeral, low-privilege, and can be encrypted. During a limited lifetime (for example around an hour), their delivery is guaranteed over sync. They are stored in the room timeline rather than in the authoritative room state that is subject to state resolution. Sticky events are ideal for real time session participation, letting clients join ongoing calls or sessions and immediately receive the necessary data, even if they missed some events earlier due to gappy-syncs (more on sticky events here).
Each participant chooses their transport, which can be a home-server resource or a peer-to-peer connection. For Element Call, we currently use LiveKit media servers, which handle the heavy lifting of fan-out for media streams. This approach allows large calls to scale gracefully while keeping the system federated, decentralised and efficient. For example, in a typical office environment, many users converge on the same homeserver, minimising connections needed to participate in a large call.
With these protocol improvements, we also refactored our codebase, creating a MatrixRTC SDK that simplifies building real time applications. The SDK handles the complexities of connecting to multiple SFUs, authenticating with Matrix, managing sticky and delayed events, and exchanging media. Developers can now use this SDK to build applications, such as games or collaborative tools, without having to handle the underlying real time infrastructure directly.
For instance, we demonstrated a simple HTML template application using the Godot game engine, leveraging the MatrixRTC SDK. Through this setup, developers can access observable real time data to integrate it into games. The MatrixRTC SDK is used as an abstraction for core capabilities such as user identity and account setup, device verification, encryption (not shown in the demo), media connectivity via an SFU, and the existing Matrix backend infrastructure.
To showcase what’s possible, we built two multiplayer games using MatrixRTC. Players communicate over federated servers, exchange real time events, and interact seamlessly despite network variability. Although live demos sometimes face latency challenges, the system handles rollbacks and syncing to ensure a smooth experience.
We showed Godot-MatrixRTC-FlappyRoyal, a game similar to FlappyBird, and Godot-MatrixRTC-Keyboard-Kart, a racer-like multiplayer game.
Games and other applications can be run as widgets, providing an added layer of security. The trusted Client handles encryption and key management, so users never expose their full Matrix account or keys to external real time apps running inside the Widget.
Currently, the MatrixRTC SDK is available in JavaScript, but the widget architecture allows the low level Matrix responsibilities to be done in other SDK’s. The Matrix Rust SDK, for instance, supports the widget postmessage api. Widgets are based on iFrames. With Wasm becoming more mainstream, this opens the door for real time applications beyond the web stack, from Godot-based games to custom simulations.
MatrixRTC represents a significant step forward for Matrix, enabling decentralised, real time, and interactive experiences in rooms while maintaining the federated, secure principles of the ecosystem.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。