The Matrix Conference 2026

Federation is working. But does the experience reflect it?
In this workshop, we'll share early vision work for how interoperability shows up across Element — in search, directories, and shared rooms — and then open it up. We want to pressure-test our assumptions, hear what resonates, and understand what we're missing.
Come ready to react, challenge, and shape what comes next. Your input will directly influence where this vision goes.

Currently user search can only be done locally, which would at best get a list of all users known to the server.

This talk aims at explaining the research we did regarding speccing and implementing a spec change proposal for the user federated search (MSC4258).

We will also explained the different solutions we thought about and the associated tradeoffs regarding data privacy, performance and complexity.

This talk is also about a collaboration between 2 public sector teams from 2 different countries :)

At FOSDEM 2026, we presented our plan to move Element Web to be powered by the Rust SDK by rewriting incrementally into reusable components. In this talk, we'll share our progress and insights so far, showcasing our prototype version of the client based on the Matrix Rust SDK along with improvements this has allowed us to bring to the web and desktop version we all know.

The timeline is the most interacted-with piece of any chat software. It's where messages live! It's hard to have a chat app without one.

Unfortunately, the matrix protocol has... compromises... in the timeline made for the sake of federation. From the incosistent ordering between sync and history on Synapse, to the inability to jump to pinned messages from before you joined, to the mystery of what happens when you join a room your server previously left.

The good news is we have a solution! The bad news is it's gonna take a while. This talk is a rundown of every step needed to get a next-generation timeline. I'll explain stitched ordering, timeline fragments, and why we need state DAGs.

Introducing a new communication tool into an existing organisation or community usually means training users and addressing their common pain points as best as possible. Over the last few years, Element Server Suite (ESS) has empowered administrators to integrate Element in a way that makes sense for their organisations, through tools like Element Admin and recent improvements in the rest of the Matrix stack.

This talk will go through what the Element stack has to offer in terms of administration tooling, UX improvements for onboarding new users and integration with existing user directories. This includes concrete user-facing features like QR code login and many features introduced with Matrix Authentication Service, but also leveraging new features in the Matrix spec like extensible profiles.

This talk will first present an amazing demo where someone from the Swedish Matrix public sector deployment will magically be able to talk to someone on the French one, and perhaps perhaps we will even be joined by someone from the NATO one, what an amazing time to be alive!

A presentation will follow to talk about how we manage to pull this through, being on a technological or human cooperation level.

Join the Matrix.org Foundation Trust & Safety team members Travis and Jim as they walk through the progress the ecosystem has made in building a safer network, and invite you to join us in building the future of safety on Matrix. We'll talk about Reporting v2, a flagship project for the Foundation Safety team, and how you can help.

Based on Trixnity Messenger, different customization options of the Matrix messenger client are shown.
We start easy with some white-labelling and re-route some parts of the app.
We continue with some adaptations of the existing UI and by adding a new feature that integrates seamlessly.
Lastly, we explore the possibility to re-use the messenger's UI logic to build a completely new UI layer on top.

In a comprehensive digital workspace, the ultimate measure of success for Matrix is invisibility. End-users shouldn't manage a separate Matrix profile, understand what a homeserver is, or manually exchange Matrix IDs. But how do you take a protocol designed to be the center of its own universe and cleanly relegate it to a silent, powerful chat engine under the hood of a broader platform?

This talk explores the architectural reality of "disappearing" Matrix into a cloud collaborative platform. We will explore how to hide Matrix-flavored concepts to users, and map platform-native user management or ACLs onto Matrix.

By looking at custom identity servers, and application bridges, we will share the practical engineering required to keep the protocol completely transparent to the user.

A fast-paced tour of everything we’ve been up to at Element in the past year, as well as what to expect in the future.

This year's highlights centre on Element's work to make Matrix genuinely interoperable for governments and large organisations in the wild. We’ll cover what’s gone into ESS Pro and Element Pro, as well as the migration from Classic.

We’ll also give an overview of all the goodies that have landed in Element X, Element Call, Element and Web. Not to mention our continued investment in protocol research.

The European Commission defines tech sovereignty as Europe’s ability to act independently in the digital world by developing and controlling key technologies, data, and infrastructure, while reducing reliance on non-EU providers. In June 3, the European Commission has published a tech sovereignty package. What’s included in the package? What’s positive? What the Commission didn’t get quite right and can it be fixed? And what’s in it for Matrix and Free and Open Source Software in general? The talk will provide a gentle introduction into some of the elements of the tech sovereignty package and try to answer all these questions.

Matrix already provides the essential primitives for a decentralized calendar: room memberships, federated state exchange, spaces, and support for custom event and room types. This session explores the technical integration of RFC 8984 (JSCalendar) within the Matrix protocol. We will examine how the JSON-based representation of JSCalendar can be mapped to Matrix state events and what pieces are missing. The presentation concludes with a live demonstration of a working prototype within Tammy.

Digital sovereignty is a board-level priority, but ambition often outpaces reality. In this session, Forrester analyst Dario Maisto presents findings from his latest report, drawing a clear line between sovereignty, privacy, and security, and examining the practical challenges organisations face in reducing dependency on dominant tech stacks, from productivity suites to communication. He explores how open standards and open source can support sovereignty goals, introducing a Minimum Viable Sovereignty framework for setting realistic targets.

The session also addresses the limits of open source, including project health, maintainer sustainability, and commercial support, as key factors in mission-critical viability, leaving attendees with a grounded framework for evaluating sovereignty initiatives.

The Matrix.org Foundation is the key to Matrix' independence from any commercial vendor. It exists to protect the neutrality of the Matrix protocol, promote Matrix as an open standard, give a voice to the members of the ecosystem and ensure trust and safety within the open network. This keynote will give an overview of the latest about the Foundation and will include a presentation from the Governing Board on the activities led by the various Committees and Working Groups.

The privacy paradox (the theory that people say they care about their privacy but behave as if they do not), assumes that user behaviours are irrational, uninformed, and based on choosing convenience above their own data protection.
My research points to a different perspective: people do care, and they also behave inconsistently, but not always out of convenience. At its core, it seems that people behave inconsistently because they feel they have no agency and that “there is no point” in trying to protect their personal information. In this sense, we all live more in a state of privacy helplessness than in a paradox – a paradox implies a choice we don’t all have.

Regulations like the GDPR can’t be the sole solution for such a widespread and structural issue, nor are they a substitute for measures which focus on actual empowerment. Geopolitical considerations are also leading private organisations and governments to more carefully ownership and control of their data, which leads to questions around autonomy and digital sovereignty.

In this talk I will go through the reasons why decentralised, end-to-end-encrypted public infrastructure, built on open standards, could be the structural answer to these problems. Matrix is one of the few working examples of this kind of technology being deployed in the public sector at scale. Matrix based communications are a key case study to show why open technology is essential to address individual concerns around helplessness, as well as national level issues associated with digital sovereignty (or lack of it).

When messaging across interoperable platforms or different clients in a decentralized network, there is a common set of functionalities defined by the common protocol or API bridging the conversation, but there may also be unique functionality exclusive to each client. These differences may sometimes have important implications in the user experience and privacy of the conversation partners, but there are no design patterns or agreed standards for dealing with them. For example, imagine that someone sends a "view only once picture" but the receiver's client lacks this functionality: would you expect the receiver to simply show the picture? To show an error message saying "message not supported"? Or should the sender client prevent the use of "asymmetrical functionality" in the first place?

In this design workshop, we will introduce the concept of "seamful design", briefly present cases where asymmetrical functionalities may harm user experience, and engage all attendees in a prototyping activity to explore potential workarounds through design. Based on the prototyped design ideas, we will discuss trade-offs, challenges and potential best UX practices for designing around functional asymmetries in interoperable messaging.

Matrix was created with the idea of federation at the core, but nowadays there is matrix.org which contains a majority of the users of the wider matrix network, nullifying the benefits of it. This has since also started generating significant cost for The Matrix Foundation and lead to shutdown of some previously offered bridges. The Homeserver Decentralisation Working Group aims to improve the situation.

Intended for people who don't know much about encryption or Matrix, this session will give an overview of how your messages are kept safe, using end-to-end encryption.

We'll very briefly review what we are trying to do: be sure who we're talking to, and be sure no-one else can read our messages. Then we'll discuss how Matrix does this: devices talk to each other with something called Olm, and messages in rooms use Megolm.

By the end of this session you should be confident talking about how Matrix keeps your data safe, and you should know enough that you are able to dig deeper when you need to.

Waldur is a multi-tenant cloud and HPC resource-management platform. In Estonia it powers the state cloud (Riigipilv) and the national scientific computing infrastructure (ETAIS), where deployments routinely involve personal and sensitive data. Yet support for all of it happens across scattered channels: Slack, Signal, email, whatever a given user reaches for. The context for any single deployment is split across all of them. To debug a problem you reconstruct the story from fragments in different apps, there is no durable history tied to the project, and sensitive conversations end up sitting in third-party consumer tools.
We are building a Matrix integration for Waldur using the Application Service API, giving every project its own room. Room membership mirrors project membership: members are invited and synced automatically from their existing project roles, so the people in the conversation are exactly the people with access to the resource. The chat renders directly in the Waldur UI, and for support staff who prefer it, the same chat is also available on the go.
We have finished implementing the first version and are now pushing it to our first users for testing. This talk introduces the problem, walks through the solution we are building, and shares our future plans for Matrix inside Waldur.

An overview of the UX design and technical implementation challenges faced when implementing "live-update" support for Profile Fields in Matrix.

Are you operating a large server, bridge or bot? Are you managing lots of spaces or rooms?
Do you sometimes need to modify rooms outside of your regular account?
Try Matrix Wrench. It's is a powerful, open-source web app to view and edit room states. It works with access tokens from users and AppServices.

Last year we started the endeavour of bringing Matrix and MLS together. The work on this subject led to some pretty exciting developments. Here you will be the first to learn about them!

I'll show you how to deploy a working Matrix server, live, in just a few minutes using Continuwuity. Then we'll get down to brass tacks and set up everything that makes Matrix great:

• Native, next-generation video conferencing
• Moderation bots, and all the tooling you need to manage and scale a public Matrix community
• Bridges beyond Matrix to message family on Whatsapp and signal or merge communities on Slack or Discord
• Bots, bots, bots! Ping racing, reminders and handy custom tools

I've got a plan, but this sessions is for you, so we'll go off the rails to follow what you want to know. The intention is that everyone has something useful to take home!

Convincing users to move to NI2CE messenger and move away from the tools they are used to working with remains an issue. I would like to share my thoughts and discuss how other organisations where the use of Matrix messengers is optional deal with this.

At Element, we've been thinking about how you can be sure you are chatting to the right person, not an intruder, without reading out numbers or emoji over a video call.

One approach we've been experimenting with is the use of X.509 certificates issued by a trusted certificate authority. I'll be talking about how this helps (and when it doesn't), as well as covering the technical details of the implementation.

2026 has seen the resurgence of Next Generation Matrix research funded by Element, as we get back to futureproofing Matrix for the medium-long term.

The main project has been the return to P2P Matrix: embedding homeservers inside modern Matrix clients, speaking the very latest Matrix room versions, supporting arbitrary overlay networks. This opens up the world of Matrix for pure mesh communications, and can radically improve metadata footprint (given in a world with no servers, there's nowhere for metadata to gather). Funded by the Dutch Government, we announced this at last year's Matrix Conference in the Matrix State of the Union, and work began in earnest in April. With first releases due in July, we should have an awful lot to talk about by the time of The Matrix Conference in October!

Alongside this, there's also been a bunch of work around next generation encryption and yet more ways of marrying together Matrix and MLS, the IETF standard for group key exchange. One of the more interesting directions has been Project Tachyon: what happens if you layer all of Matrix over Decentralised MLS, using MLS to define which devices can participate in the conversation - but use clientside Matrix state resolution for decentralised authorisation having decrypted the traffic? In return you entirely solve the metadata problem: the server doesn't even know rooms exist; all it does is pass DMLS payloads around over to-device messages.

In this talk, we'll do a deeper dive into the latest P2P Matrix and DMLS work - and explore how Tachyon might also provide an answer to the eternal question of "Portable Matrix": how do you run Matrix over an existing store-and-forward protocol like SMTP, XMPP, ActivityPub, etc?

The federation protocol is how Matrix homeservers communicate between each other. In private federations this isn't particularly challenging as the network is trusted but in the public federation this isn't true. This talk dives into what protocol improvements are in the works to make the public federation more secure against Byzantine actors, particularly against "backdating": intentional misuse of the concurrency primitives to manipulate the authorisation algorithm. We'll explore why this problem is hard, what some of the failure modes are, and how we are working on addressing them.

Some of this work was presented in a peer-reviewed article.

Robrix is a "new" FOSS Matrix client written entirely from scratch in Rust, with some cool power user features like a dockable-tabs view of multiple rooms side-by-side, just like your favorite IDE. It's simple and flexible enough for casual chatters as well, and can seamlessly transition into a sleek mobile-friendly adaptive UI for narrow screens.

Robrix runs smoothly and consistently across mobile & desktop platforms, thanks to the underlying Makepad UI toolkit and Robius abstraction crates, which we also wrote ourselves in Rust. After several years of hard work on those components, we have finally reached the milestone of publishing Robrix to major app stores.

Join us to learn more, see some fun live demos, and give it a try yourself. We'll also preview some of our future ideas, such as making Matrix the best medium for coordinating and managing multi-agent workflows (even better than Telegram!).

Europe's need for sovereign, secure communication platforms is no longer up for debate. Matrix has established itself as a powerful open foundation for secure collaboration. However, public sector organizations also need to satisfy strict legal and compliance requirements while integrating with existing identity, security, and operational systems.

Drawing on real-world deployments in regulated environments, this session explores how organizations build on Matrix to address these challenges through identity and access management integrations, auditing and compliance, workflow automation, granular room governance, and user-friendly account recovery. Attendees will gain practical insights into building secure, auditable, scalable, and sovereign collaboration environments ranging from out-of-band channels to decentralized partner networks.

The Matrix Rust SDK is one of the most complete, mature, and performant SDK in the world. To illustrate our point, we will show off how to develop a Matrix CLI client from scratch with the Rust SDK live on stage, step by step, up to having a fully functional client, with a room list, a timeline, the ability to send and to receive messages, along with full end-to-end encryption support.

Hey! You may have just seen our talk about the future of integrations, or didn't see the point and hung around the bar. No matter! You will want to come to this workshop where we will teach you how to sculpt Element Web into the perfect client. We will impart the wisdom, hear the feedback and make dreams become reality.

A notification seems simple: a message arrives, and the phone vibrates. But in the Matrix ecosystem, a single "ping" triggers a complex chain of events involving E2EE decryption, push rule evaluation, and state synchronization. This talk dives into the architectural challenges of implementing a robust, privacy-respecting, and energy-efficient notification engine in Trixnity.

In which Matthew gives all the latest updates on Matrix - including ecosystem uptake, new clients, new servers, new MSCs, Hydra Phase 2 and 3 progress, P2P Matrix, MatrixRTC maturity, where (D)MLS fits in, and more!

This presentation outlines the development experience of a post-quantum cryptography (PQC) wrapper for the vodozemac library, tailored for its use in MSG
GOV, a Matrix-powered E2EE messenger for the Brazilian federal government. Our wrapper is designed to support multiple PQC algorithms, including ML-KEM and Brazil's state-mandated cryptography. The talk details the practical software engineering challenges associated with the hybrid integration of flexible PQC features into the Matrix protocol, extending both the key agreement and the Double Ratchet algorithm while maintaining backwards compatibility.

The Matrix Rust SDK has grown from an experimental client SDK into the
foundation that powers Element X and other Matrix applications. Along the way,
it has gained support for major Matrix features while tackling some interesting
engineering challenges.

In this talk, we'll explore recent additions to the SDK, including threads,
spaces, QR code login, shared encrypted history, migration from Element Classic
to Element X, and the centralized redecryption mechanism. We'll look at the
problems these features were designed to solve, the architectural decisions
behind them, and some of the lessons learned along the way.

When you operate communication infrastructure for one of Europe's largest defense organizations, "good enough" is never good enough.
At BWI, we do not just run Matrix. We trust in the idea behind it: that secure, open communication should be a public good.

When we introduced Matrix into the Bundeswehr, we made a deliberate decision: everything, always, end-to-end encrypted. No exceptions, no fallbacks. That single switch revealed the hard problems. Olm and Megolm, built on the Signal Protocol, are the gold standard of modern encryption, but they were not designed for large rooms with thousands of participants at government scale. Those cracks are what brought us to MLS, the IETF standard built for exactly those harder problems: scalable group key management, stronger forward secrecy, post-compromise security. MLS does not just change how keys are managed. It changes how little the server needs to know. And that is not a side effect. It is a design goal. The less the server knows, the less it can leak, and required by VS-AP0024, the BSI guidance we operate under.

That settled the what. Rust settles the how. Not as a language choice, but as the foundation that makes formal verification of the functional core possible, and memory safety everywhere else a given.

We wrote MSC2546 ourselves, defining how MLS integrates into the Matrix protocol at the spec level. Now we are ready to share what happened next.

In this talk, Timm and David from BWI will show you what it takes to bring MLS into a real production stack: what changes in the SDK, what it means for backend modules, and how Rust becomes the common thread that holds it all together. Expect no polished success story. Expect honest engineering: what was built, where it broke, and what it cost. And at the end, the first thing they shipped with it. A new way to have a conversation that leaves no trace. Come find out when to change the locks.

Join our journey.

When you operate communication infrastructure for one of Europe's largest defense organizations, "good enough" is never good enough.
At BWI, we do not just run Matrix. We trust in the idea behind it: that secure, open communication should be a public good.

This talk traces that journey. It begins with our decision to adopt Matrix as the sovereign communication backbone for the German armed forces, and the architectural ambition that drives our work: a communication stack where the functional core is formally verifiable, and memory safety is a given everywhere else. An engineering target we are actively working toward.

As a first step toward that goal, working with Element, we brought a Rust-based cryptographic SDK into existence, the Matrix Rust SDK, a unified crypto platform shared across all our client applications, born from our security requirements and built to last. Rust was not an aesthetic choice. It was a deliberate decision rooted in memory safety, auditability, and the practical requirements of formal verification tooling.

Our work did not stop with the SDK. The same questions that shaped our cryptographic foundation led us to ask harder ones about the backend: what would a homeserver look like if security and formal verifiability were first-class requirements from day one, not afterthoughts? We have been exploring that question, and in this talk we want to share what we have learned so far, the decisions we faced, and where those explorations have taken us.

Join our journey.