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
Advancing real time communication on Matrix
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.
Introducing slots for interactive rooms
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.
Sticky events: reliable, ephemeral data delivery
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).
Transports: keeping real time communication decentralised
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.
A MatrixRTC SDK for developers
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.
Building on MatrixRTC: live demos
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.
I have not have issues in game with Linux. But with Steam feels like game rebuilds shaders with every launch. With Heroic I don't seem to have issue, but my wife does. Hopefully you find solution!