Healthcare has always had its share of chronic conditions, but not all of them are clinical.

For years healthcare communications have been trapped in paper-based systems, slow email chains and endless telephone tag. More worrying still, the creeping adoption of consumer-grade chat apps is now putting private patient data directly into Big Tech's hands - whose entire business models depend on harvesting it.

Now there’s a prescription for change.

CompuGroup Medical (CGM) – one of the world’s leading e-health companies – and Element are partnering to transform how healthcare professionals exchange information securely in real time.

Healthcare organisations need to exchange information quickly and securely, while maintaining strict control over sensitive patient data. Traditional centralised messaging platforms don’t match those requirements. They create vendor lock-in, fragment communication across organisational boundaries, and leave healthcare bodies dependent on a single commercial provider for infrastructure they can't fully inspect or control. That challenge is only growing as governments and public sector organisations across Europe place increasing weight on digital sovereignty. 

By combining CGM’s deep medical sector expertise with Element’s communications technology, we’re building tailored tools that provide sovereign, interoperable and secure communications for healthcare.

Supporting CGM’s healthcare messaging platforms

CGM has developed two powerful messaging solutions, CGM TI-Messenger and the CGM Messenger, both built on the Matrix open standard.

CGM TI-Messenger: The recently launched CGM TI-Messenger, certified by gematik (Germany’s national digital health agency), enables Germany’s healthcare professionals and organisations to exchange information securely and in real time as an alternative to email and phone-based workflows.

The TI-Messenger initiative is transforming German healthcare’s traditional systems, and puts patient privacy first. It serves as a powerful real-world blueprint for interoperable, sovereign communications by creating a massive nationwide private federation that will connect more than 150,000 separate healthcare organisations.

CGM Messenger: CGM Messenger (built on Matrix, rather than Germany’s Matrix-based TI-Messenger standard) brings the same standard of secure, real time collaboration for use outside of Germany’s TI-Messenger infrastructure. 

Designed for global adaptability, it connects disparate healthcare teams, clinics, and administrative staff by embedding sovereign and end-to-end encrypted messaging directly into existing healthcare IT systems. CGM and Element are establishing a new global benchmark for safe, efficient, and interconnected digital health ecosystems.

Matrix is a game changer for healthcare

The Matrix open standard provides fundamental benefits for healthcare communications:

• Digital sovereignty: Every healthcare organisation retains total ownership and control of its own data.
• Seamless interoperability: Separate hospitals, clinics, and labs can connect and talk to each other instantly, even if they use Matrix-based products from different vendors - making Matrix the ideal way to connect thousands of separate organisations.
• Competitive ecosystem: Because the standard is completely open, it supports a competitive ecosystem of vendors, which naturally drives freedom of choice and rapid industry innovation.
• Powerful security: End-to-end encryption and layered security protections ensure sensitive patient data stays confidential.
• Beyond chat: Matrix-based communication can be embedded directly into software, medical machinery and the Internet of Things (IoT) to transmit patient data instantly and securely.

As Jens-Uwe Thieme, General Manager Patient Portal & Platform Components at CGM, puts it:

Powered by Element Server Suite Pro

This partnership is powered by Element Server Suite Pro (ESS Pro), our enterprise-grade Matrix infrastructure platform.

Healthcare organisations need communication systems that are not only secure, but also scalable, resilient, and maintainable over the long term. ESS Pro is designed to meet those requirements while supporting the evolving standards around Matrix and TI-Messenger compliance.

ESS Pro supports both single-tenant and multi-tenant deployments, including configurations specifically designed for TI-Messenger environments. Its multi-tenant architecture for TI-Messenger was recently security validated by gematik.

It also provides enterprise capabilities, including:

• Long-term support aligned with Matrix and TI-Messenger standards
• Identity and access management
• Advanced administration and auditing tools
• Security notifications
• Auto-scaling infrastructure to handle changing traffic demands
• Multi-tenant ‘small hosts’ capability

For us, this partnership reflects a broader shift happening across healthcare and the public sector.

Organisations increasingly want a communication infrastructure that is open, sovereign, interoperable, and secure by design - without compromising usability for healthcare professionals.

We believe Matrix is uniquely positioned to support that future, and CGM is exactly the kind of partner to help us build it.

In a landmark demonstration of the power of the Matrix open standard, two of Sweden's major public sector agencies, Försäkringskassan (the Swedish Social Insurance Agency) and Trafikverket (the Swedish Transport Administration), have successfully federated their entirely separate real time communications systems. 

By using Matrix as a common digital communications infrastructure, Sweden’s public sector can ensure its digital sovereignty by every agency having a choice between competitive vendors that all support the same open standard to enable government-wide federation. For example, Försäkringskassan uses Element (branded as SAFOS Chatt), while Trafikverket uses Rocket.Chat. Two separate organisations, two different vendors, one seamless conversation.

Sweden’s initiative to embrace digital commons for real time communications has been led by eSamverkansprogrammet (eSam), a member-driven collaboration initiative involving more than 40 member agencies. It was eSam that announced the go live.

eSam added that it intends to expand the initiative, involving more authorities and end-users to build momentum and practical experience. It also sees more vendors getting involved to complement the current examples of Element, Rocket.Chat and Mattermost. The eSam project, known as dSam, also has plans to formally recommend that eSam adopts Matrix as a common standard for secure and interoperable communication between Sweden’s authorities.

Vendor-agnostic federation

Sweden's public sector is laying the foundations for a truly sovereign communications infrastructure. It rejects vendor lock-in in favour of a decentralised open standard that puts agencies in control. By embracing Matrix-based federation, Sweden unlocks a genuinely competitive marketplace where vendors must compete on quality and value. The result is an entire public sector that can connect and communicate in real time, regardless of which solution each agency chooses. And because Matrix is open source, that freedom extends even further as organisations can build directly from FOSS components if they choose. Either way, they do so with the confidence that they will interoperate seamlessly with every other public agency in Sweden. It is a model that is simultaneously digitally sovereign, pragmatic and future-proof.

Försäkringskassan (SAFOS) presented on the importance of an open standard for interoperable communication at The Matrix Conference 2025, which was reported on at the time by Computer Weekly. With Sweden’s Social Insurance Agency and Transport Administration having just gone live with Matrix-based federation, it’s entirely fitting that The Matrix Conference 2026 will be in Malmö, Sweden!

In a recent blog post about the need for open standard federation, we created a map of Europe’s major Matrix-based public sector deployments. It shows the breadth of Matrix adoption across Europe, and some of the solutions, vendors and providers already in place.  

The importance of interoperability

Matrix was born out of a vision for end-user independence; freedom from centralised systems, siloed products and surveillance capitalism. It's a vision that resonates deeply with governments and public sector organisations, particularly in an era defined by the stranglehold of vendor lock-in.

We take it for granted that anyone can pick up a telephone and call anyone else, or send an email regardless of provider. These are digital commons, built on common standards, and they transformed how the world communicates. Yet the more recent generation of communications infrastructure - from Microsoft Teams and Slack to WhatsApp, Signal and Zoom - has deliberately abandoned this principle. These platforms are engineered to be siloed, prioritising vendor growth over user freedom and interoperability.

One of the biggest challenges in public service is bringing together the multiple organisations that serve citizens. A world of siloed messaging apps and vendor-specific collaboration tools makes co-ordination between organisations much more difficult. Whereas a return to digital commons - in the case of communications, an open standard such as Matrix - proactively encourages real time communication between separate organisations. For example Police, Fire and Ambulance crews can easily communicate with each other from their own separate, specialised systems provided they all operate from the same interoperable standard.

In a world of Matrix-based communications, it’s easy for health insurance firms, hospitals, local clinics and high street pharmacies to communicate in real time while simultaneously enabling each party to pick and choose its own technology solution. Indeed, thanks to gematik’s work on the Matrix-based TI-Messenger standard, it’s already a reality for Germany’s healthcare ecosystem. It’s becoming the reality in Sweden too, led by eSam, Försäkringskassan and Trafikverket.

More than digital sovereignty

Europe’s push for digital sovereignty is entirely correct and logical, but it must ensure that the post-Big Tech era is built on the principle of digital commons. Otherwise it’s just trading the flaws of US Big Tech for the flaws of European Big Tech. That might be an economic win for Europe, but it falls far short of transforming the way the public sector communicates, and the resulting operational efficiencies and service improvements it could deliver citizens.

Matrix is more than an open standard. It’s an opportunity to overhaul public service. That’s why Element is so proud to play a significant role in maintaining the Matrix open source project, and to be working with so many governments and public sector organisations to help them adopt Matrix-based communications.

Our hyper-connected world is synonymous with progress. Digital transformation promises efficiently-run smart cities, improved economic performance, better healthcare outcomes and all the rest of it. 

Simultaneously, interconnections also create vulnerabilities; from ransomware crippling public services, to cyber attacks designed to damage critical national infrastructure, or silently extract sensitive data for years on end.

Against this backdrop, air-gapped communications remains the gold standard for security. In matters of national security, the safest network is always the one which is physically separated from the internet and the rest of the world.

Venting an innovation vacuum

It’s no surprise that air-gapped communications, designed to operate in isolation, have not felt much evolutionary force. The majority of air-gapped networks are running legacy platforms; relics of a bygone age. Unaffected by the smartphone era, many air-gapped networks still use Jabber, Sametime or Skype for Business.

In a world that’s grown used to WhatsApp and Signal, poor usability feels like a considerable constraint. It can drive users to bypass approved systems in favour of unofficial tools, creating security risks. 

That’s why we ensure Element has the very latest modern user interface with read receipts, threading, embedded voice and video calling and easy message editing. Such features improve the overall productivity of a secure environment; even emoji reactions can have practical benefits in conveying simple information quickly. And while many air-gapped environments only support desktop communications, Element can support handheld devices for use within an air-gap with a consumer-style messenger app.

We’ve also designed Element to support the use of X.509 client certificates for identification and encryption - including hardware-based tokens. Big screens can support GridView, so teams can monitor a dashboard of multiple rooms simultaneously, and chat rooms can include live data feeds from trusted systems within the air-gap.

In short, there’s no reason why an air-gapped communications platform should look or feel any different from a highly-polished online system. The difference is simply that it’s separate from the internet, rather than decades away from the real world. See what modern air-gapped communications looks like in practice.

Deploying into the airgap

Historically, air-gapped systems have been challenging to install and maintain. We’ve made installation as straightforward as possible. Ahead of deployment into a live environment, Element integrates with DevSecOps workflows and supports independent security validation. The distribution includes enterprise features and compliance readiness, for a complete solution.

In a similar manner, although unconnected to the internet, we’ve made sure our air-gapped solutions are easy to maintain with vendor-backed Long Term Support (LTS) to provide a regular cadence for maintenance, and security updates. It’s also backed by our service level agreement (SLA) and comes with Level 3 support. We sell our air-gapped solutions directly, but also through a number of partners who benefit from the stability and support we provide, leaving them free to focus on their customer.

From isolation to controlled integration

As one might expect, Element supports single and multi-site air-gapped environments. It also supports, if desired, secure connectivity to other Matrix-based networks using our cross domain gateway to securely bridge partitioned networks. The cross domain gateway acts like an airlock on a submarine or spaceship, creating a safe passage between two environments. The hardware sits in a highly-trusted environment, where it decrypts, inspects, applies data-loss-protection rules and re-encrypts data as it passes from one domain to the other.

A high-security environment that can message to a low-side network has multiple uses.

For national security and policing, cross domain connectivity can safely support communications between high-side and low-side environments with policy-enforced information flow. It can ensure that sensitive information is shared carefully between high and low side environments to speed information sharing, enforcing data classification labels, rather than relying on manual processes in time critical situations.

For military use, using Element for cross domain communications can support connectivity between separate systems. Vessels, vehicles and equipment for example can connect their respective communications platforms across different classes of network security. For remote cross domain connectivity, the air-gapped environment can be securely connected with less-trusted networks to secure field operations.

Proven air-gapped partnerships

Element’s air-gapped customers include primes, systems integrators and defence contractors as well as various MoDs that we serve directly. When it comes to our partners, they typically run multiple air-gapped environments for a range of their own customers. Many of their air-gapped deployments need to federate across multiple locations. Typically the air-gapped solutions support around 200-500 people, although they can be significantly larger.

Element Server Suite Pro (ESS Pro) is often used to replace legacy solutions, such as Skype for Business or Jabber, or as an alternative to a vendor-locked solution. Although an air-gapped system usually operates in isolation, there is still a strong desire to use a solution based on the Matrix open standard as it ensures a competitive vendor ecosystem for a potential future migration, rather than being tied into a specific vendor and forced to ‘rip and replace.’ 

Defence contractors have also switched to ESS Pro having initially built customer solutions using Element’s FOSS components, or ESS Community. They have done so based on ESS Pro’s improved scalability, management, LTS and technical support.

End users primarily use the desktop version of Element Pro, although there is some usage of the Element Pro app mobile devices approved for dedicated use within the air-gapped environment. End-users enjoy an intuitive modern interface similar to the likes of WhatsApp and Signal but with enterprise performance and functions.

Installing air-gapped

Each ESS Pro release also provides access to an air-gapped bundle containing all the resources that could be fetched from the internet when installing that release. Element’s simple instructions make it easy to import these resources into your own private registry and provide the configuration for ESS Pro such that your installation will use your private registry. And as the same bundle is used as part of ESS Pro’s automated test suite, you know it is all going to work just as smoothly as if you had internet connectivity.

Air-gapped secure communications

See what modern classified communications looks like - built for how defence and national security actually operates.

Download report

For years, end-to-end encryption (E2EE) has been the gold standard for digital privacy. But it has always come with a silent trade-off: when you add a new member to an encrypted chat, they arrive at a blank slate (as in, they can’t see conversation history). Any previous conversation - no matter how vital to their onboarding - remained locked away, accessible only to those who were already there. You start taking the screenshots of the chat to provide the new member with the necessary context and get them up to speed. Sound familiar?

Today, we are changing that. We are thrilled to announce that Element now supports seamless, secure history sharing for new chat members, effectively ending the ‘blank slate’ era of encrypted collaboration (more on this here). Whether it’s a new colleague getting up to speed on a project, a person you simply forgot to invite to a new chat, or a community member joining a long-running discussion, you no longer have to worry about whether they have the context they need.

By combining the rigour of Matrix’s decentralised, secure architecture with the seamless experience users expect from modern messaging, we’re proving that you don't have to choose between strong security and fluid collaboration.

The challenge of "locked" history

In a standard E2EE environment, messages are encrypted with keys that are only distributed to the participants present at the time the message is sent. When a new person joins, they simply don’t possess the cryptographic keys needed to unlock the chat history. 

For many users, this felt less like a security feature and more like a broken experience. Organisations and communities were often forced to choose: keep history visible but unencrypted, or keep it encrypted but siloed from new joiners. Neither was the ideal solution. If you forgot to invite a person to a new chat, got a new team member, or a new person joined a working group they couldn’t see the conversation history.

How it works: Privacy by design, convenience by choice

Our new feature bridges this gap without compromising the integrity of your E2EE environment. When a chat admin chooses to allow new members to see historical messages, Element now intelligently and securely shares the necessary historical decryption keys with the new participant when they are invited. Instead of broadcasting history in the clear, we’ve developed a secure mechanism to share key bundles directly with authorised new members.

Chat admins retain full authority. You can decide chat-by-chat whether to enable history sharing, ensuring that sensitive discussions remain protected while collaborative ones become truly productive. Crucially, your data remains end-to-end encrypted. The keys are shared via private, encrypted "to-device" messages, ensuring that the history is never exposed to the homeserver or any third parties.

How to use it?

If you want the history of the chat to be shared with new members, just go to the room’s Privacy & Security settings and set the “Who can read history?” to “Members (full history)”. That’s it.

When creating new encrypted rooms, by default the history is not shared. The room header displays whether the history is shared so the members are aware of it at all times.

A note about existing rooms

If you notice an existing room in which history is shared, but should not be - you can change that in the Security & Privacy settings before inviting new members. Note that according to the Matrix specification, all historical messages should be made visible to new members if the message was sent while room history was set to shared. However, because some rooms may have accidentally had history sharing on without users realising that, there is currently an additional constraint in place that keys for such past messages are only shared with new members when the room is currently set to share history.

Future enhancements

History sharing does not work yet when a user joins a room via a Space proactively. They need to be invited to the room since the keys for the past messages can only be provided by an existing member of the room (the one who invites them).

We’re really pleased with enabling easy, secure history sharing for new chat members. As far as we know, it’s unique to Element. We’d love feedback on your experience of using it; like any new feature it can doubtless be improved and polished as we get insights from our end-users. 

Across Europe, sovereign communications systems are already being deployed, and crucially, they don’t have to exist in isolation. An overlooked part of achieving genuine digital sovereignty is ensuring that an organisation has the ability to switch easily between vendors to guard against vendor lock-in. 

It’s a sentiment that was perhaps best expressed by Karsten Wildberger, Germany’s Federal Minister for Digital, at the Summit on European Digital Sovereignty in November 2025: “Digital sovereignty means having choices, so no single technology and provider becomes a dependency that can be used against our interests. It is always good to have choices in order to avoid dependencies.”

Without the ability to easily switch between vendors, an end-user organisation remains beholden to a specific vendor. It gives a vendor too much power over the end user organisation. For example, it’s preferable to swallow a doubling in price than to ‘rip and replace’ an incumbent solution.

At the more alarming end of the spectrum, it creates major vulnerabilities. A recent example is Ukraine suffering the loss of satellite imagery supplied by Maxar Technologies, as the US vendor implemented a decision made by the US government. In a similar incident, email services to Karim Khan, chief prosecutor at International Criminal Court (ICC), were suspended as a result of a US government sanction. The ICC has since gone through the rip and replace pain of moving from Microsoft Office to openDesk, a sovereign alternative.

Interoperability delivers digital sovereignty

Governments’ adoption of digitally sovereign solutions, to avoid a dependency on a single vendor, is the right strategy to take in an increasingly sharp geopolitical climate. Even a vendor that is currently trusted cannot be trusted into an unseeable future. A vendor can be acquired, possibly by a company that’s headquartered in a non-trusted country. A vendor could be completely compromised as a result of a cyber attack, or nation-state sponsored malicious insider. A vendor could grow into a monopolistic position - especially if a government standardises on that vendor - and then abuse its dominant market position.

While a solution could be from a European vendor, enable self-hosting, and might even be open source, it’s still not offering sovereignty if it’s proprietary style ‘vendor-locked’ software. This is especially true for chat-based solutions.

Chat should never be a proprietary-style vendor-locked solution

Chat apps have developed during a quite centralised era of computing. That those using WhatsApp can only communicate with others using WhatsApp has, somehow, never been seriously questioned. Likewise, it’s only Signal to Signal, Slack to Slack, Teams to Teams, Threema to Threema, WebEx to WebEx, Wire to Wire, Zoom to Zoom. They are all walled gardens - siloed systems - that don’t interoperate.

Chat has never suited a proprietary model, because it often involves people who use different technology. The original open internet is a huge success because it enables communication through common standards. People can upload information stored and managed on their own system, and make it available to others via the Web.

Email is similar; it doesn’t matter what email system you use, you can send an email to anyone because it’s based on a standard on which all vendors operate. No one ever asks if you use Microsoft Outlook, Gmail or Apple Mail as - thanks to interoperability - it doesn't matter.

As a result (despite email being arcane and insecure) there’s still a healthy competitive ecosystem of email providers and switching between them isn’t a massive headache. Decades of emails can be seamlessly managed during an email migration, unlike years of chat history moving from Slack or Teams to some other proprietary system. As for WhatsApp or Signal, well, as consumer messaging apps they shouldn’t even be used within the workplace.

The role of Matrix for sovereign communications

Matrix is an open standard for decentralised communications. The protocol enables self-hosting, resilient communications, interoperability and end-to-end encryption. 

There’s well in excess of 200M people already using Matrix, and more than 150K Matrix deployments. More than 25 governments around the world have already deployed Matrix-based systems. There are more than 40 software vendors in the Matrix ecosystem, and at least 30 major primes, systems integrators, services firms and hosters offering Matrix-based solutions. 

The German healthcare system has developed its own standard, TI-Messenger, built on top of Matrix, that’s already implemented by public healthcare insurers. It’s currently being rolled out to local healthcare providers and will eventually support the vast majority of Germany’s 83M citizens. 

The Matrix ecosystem provides the ‘digital commons’ that ensures genuine digital sovereignty. Governments and public sector organisations have complete ownership and control of their communications solutions, with the ability to easily choose and switch between vendors, and federate with each other through their own sovereign systems.

Sovereignty without isolation - Matrix-based federation

Choosing a communications solution based on an open standard to ensure digital sovereignty brings another significant benefit. The Matrix open standard not only ensures a competitive ecosystem - it enables each independent Matrix stack to connect with any other (assuming both parties want to connect, of course). 

It’s the very opposite of a standard proprietary-approach, where all parties have to use the same vendor. The Matrix open standard enables solutions from different vendors, and those developed in-house, to federate. This means sovereignty does not come at the cost of interoperability, which is a balance that ‘walled garden’ proprietary systems cannot deliver.

In other words, all 27 EU members, and the EU itself, could all have their own sovereign Matrix-based solution for communications. And they could all remain in their specific solution (which is perhaps tailored to meet their own country-level requirements), while all being able to federate with each other.

We’re already seeing this play out. Germany’s public sector has multiple Matrix-based systems including the openDesk office suite, BundesMessenger and BwMessenger. Meanwhile, The City of Cologne runs Rocket.Chat enabling it to benefit from Matrix-based federation if it wishes. The French government is standardised on Tchap, which also sits within LaSuite; France’s sovereign office suite. 

Sweden has SAFOS Chatt, its own Matrix-based chat. Elsäkerhetsverke, the Swedish Electrical Safety Authority, uses Rocket.Chat and could therefore use Matrix-based federation to connect with other organisations. The European Commission and the UNICC use Element, NATO ACT uses its Matrix-based NI2CE Messenger. EU-Lisa and NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE) both operate on Rocket.Chat so, again, can also federate using the Matrix open standard.

If they so desire, all of these country-specific communications platforms can federate - ensuring digital sovereignty and enabling cross-border federation. All without a dominant vendor, and all completely without any level of vendor lock-in.

Taken together, these deployments form a growing, federated network of sovereign communications across Europe - not a patchwork of silos, but an interconnected ‘network of networks’ ecosystem. Digital sovereignty, when built on open standards, enables communications without vendor dependency.

Since we launched the Element Server Suite (ESS) Community edition, we’ve been thrilled by the momentum. We are seeing a whole wave of new deployments and steadily growing engagement within the community. It’s clear that more people than ever want a robust, manageable way to host their own Matrix stack.

However, we’ve also heard a consistent question from those of you running older, "pre-ESS era" deployments: “How do I get my existing data into ESS without starting from scratch?”

Today, we are excited to answer that question. Available starting today, we are officially releasing an initial version of the ESS Migration Tool.

Why migrate to ESS?

For many long-time Matrix admins using Synapse, maintenance can be a manual burden including handling complex configuration, managing dependencies and keeping up with security updates.

By migrating to ESS, you leave that heavy lifting to Element’s ESS distribution. ESS is designed to make your life easier; once migrated, you can keep your system up-to-date, secure and packed with the latest Element features just by running a simple command. Furthermore you get all the components needed for a basic Element/Matrix stack out-of-the-box, curated and coordinated between each other, easy to deploy and maintain.

Introducing the ESS migration tool

The ESS migration tool is a dedicated tool designed to bridge the gap between your current Matrix environment and a modern ESS deployment. The tool automates the most tedious parts of moving to a Kubernetes-based ESS architecture:

• Configuration parsing: It takes your existing Synapse and Matrix Authentication Service (MAS) configuration files and parses them to discover secrets and linked files.
• Transformation: It converts those configurations into values files compatible with the ESS Helm chart.
• Kubernetes integration: It automatically generates the necessary Kubernetes Secrets and ConfigMaps.

The goal is minimal disruption. You can set up your new ESS environment and continue providing service to your users while immediately gaining access to powerful integrated features like Element Admin and Element Call.

A "breeze" for MAS migrations, too

Matrix Authentication Service (MAS) is the next generation of authentication and user management in Matrix. If you haven't moved your deployment to the MAS yet, ESS is your secret weapon. By migrating your environment to ESS Community first, you can utilise our built-in MAS migration tooling which automates the majority of the transition - check out the MAS migration guide. If you already have a MAS-enabled environment, no problem, you can still use the migration to get into ESS!

Getting started

The migration tool is available as a Python package and is licensed under AGPLv3. You can find basic instructions in the ESS Community repository. To help you through the process, we’ve prepared a comprehensive step-by-step migration guide as part of the tooling itself.

The roadmap: What’s next?

This first release is just the beginning. Our priority was to get this tooling into your hands as early as possible to gather feedback from the community. Over the coming months, we will be adding more functionality, including:

• Automated imports: Direct database and media file imports.
• Environment discovery: Automatic imports from existing Docker or Kubernetes contexts.
• System health: Integrated prerequisite checks to ensure a smooth transition.
• Expanded stack support: Migration support for Element Web, Matrix RTC/Livekit, and reverse-proxy configurations.

A note for commercial customers

While today’s announcement is a major milestone for our Community version, we haven't forgotten our Enterprise and Sovereign users. A top priority for our engineering team is facilitating a seamless "lift" from the ESS Classic stack to the modern ESS Pro environment.

The development to support customer migration paths is just around the corner and we are currently in the final stages of internal validation and will have more detailed news to share very soon. If you are an ESS Classic customer, you will be notified as soon as the Pro migration path is ready - and if you'd like to discuss your specific needs - please reach out to our support team.

Join the conversation

We want to hear about your migration experience. Your feedback directly shapes the future of this tool. If you run into any issues, let us know.

• Talk to us: Join the ESS Community Room.
• Report issues: Create a ticket in the ESS Community repository.

Start your migration today and experience the next generation of Matrix hosting!

First previewed during the Matrix Conference and detailed in the Glimpse into the Future blog post, the vision for a faster, more intuitive way to organise conversations is now a reality as Spaces are now officially available on Element X! 

This update brings a sophisticated digital architecture to the experience, replacing long room lists with structured, context-driven communication.

What are Spaces?

Think of Spaces as the digital architecture of your communication. Instead of an overwhelming list of individual rooms, Element uses Spaces to group related conversations into navigable, virtual containers. This structure delivers two primary benefits for organisational scaling:

• Effortless room discovery: Spaces provide an immediate overview of a specific team or project. Users can instantly see all relevant channels - for example, every room belonging to "Team X" or "Project Y" - ensuring that the right people always find the right conversations.
• Simplified access management: Element allows rooms to be configured so any member of a Space can join them without needing an invitation. This streamlines onboarding while still offering the flexibility to keep specific rooms within that Space "invite-only" for sensitive topics.

By organising by department, project, or interest, Spaces allow for seamless context switching. Users can move from a focused "Product Team" environment to a "Company News" world with a single tap - ensuring mission-critical focus and general updates stay perfectly separated.

Automated organisation for admins 

Spaces isn’t just about better organisation for users; it’s a powerful tool for administrators. If you are using Element Server Suite Pro (ESS Pro), you can now mirror your organisation’s actual structure directly within the app.

With automated memberships and permissions, admins can automatically assign users to the correct Spaces and rooms. For example, all members of your “IT Department” can be automatically added to the “IT” Space with the appropriate access rights the moment they join. This gives admins granular control over who can access, read and participate in conversations, ensuring your workspace remains secure and organised.

What’s new?

Spaces on Element X isn't just a port of the old system; it’s a complete redesign built for speed, reliability and clarity. As we modernise Element across Web, Desktop and Mobile, we are ensuring that Spaces feel like a native, seamless part of your workflow.

1. A smarter, cleaner chat list 

To keep the chat list clean and actionable, Element X utilises a high-level filtering system. Instead of clunky folders, a quick filter at the top of the chat list allows users to instantly narrow their view to a specific Space. This ensures that only the rooms relevant to a chosen context are visible, removing the noise of unrelated conversations.

2. Discovery at your fingertips 

The dedicated Spaces tab serves as a central hub for joined and created Spaces, enabling users to actively manage their environment and expand their reach. This interface allows for the immediate discovery of rooms within existing Spaces that a user has not yet joined, while providing admins with direct controls to manage memberships, adjust settings, or link new rooms to the structure. It also facilitates the creation of entirely new Spaces, offering a unified location to build and govern organisational architecture from a single, intuitive interface.

3. Flexible room creation 

Organisation starts the moment you create a room. You can now choose exactly where a room belongs during the setup process. Attach it to a specific Space so your teammates can find it instantly, or keep it "spaceless" for your own private or general chats.

4. Context before you join

No more guessing what’s inside an invite. With Space previews, you can see a description, the member count, and who invited you before you hit accept. This transparency ensures users understand the scope of a community before entering. 

Ready to dive in?

The wait is over. Spaces is one of the final pieces of the puzzle in making Element X the ultimate replacement for the "Element Classic legacy apps." It’s faster, it’s prettier, and it’s ready for you to use.

To get started, simply update your app to the latest version and look for the new Spaces icon!

Meedio will use Element Server Suite Pro (ESS Pro) as the server-side solution for its new communications platform. Launching in Q2, the Meedio solution will include its own front-end client including a Matrix-based video conferencing solution. Meedio will be available both on-premise and as a hosted service.

The Danish headquartered company will offer sovereign communications across Europe, with a particular focus on the Healthcare, Education and Public Sector. Meedio recently won a framework tender to supply Germany’s 1,100 universities with communications solutions, and holds TÜV and KBV certification for the German healthcare industry. Its hosted solution will initially be based out of Germany, with hosting available from other European countries as the service expands. 

Meedio’s communications solution brings another competitor into the Matrix-based communications ecosystem, giving public sector organisations and businesses yet more options when it comes to choosing between Matrix vendors. Meedio joined the Matrix.org Foundation as a Silver member in January 2026, and participated in The Matrix Conference 2025.

Infrastructure to enable customer focus

Using ESS Pro as the server-side solution for its Matrix-based service gives Meedio the ability to focus on its customer propositions. Rather than creating and maintaining backend functionality - such as scalable performance, identity and access management and record keeping - Meedio is free to dedicate all its development resources to its front-end products and services.

“So much of our success comes from listening to our customers, and giving them solutions to match their exact requirements,” says Runi Hammer, the founder and CEO of Meedio. “We’ll compete in the Matrix ecosystem by differentiating on the frontend client, such as our video conferencing and medical case boards. By using ESS Pro we have the best server-side solution available, so we can just focus on what we do best; delivering solutions to our customers.”

Runi Hammer

CEO Meedio

ESS Pro also provides a highly cost-efficient way of delivering a powerful hosted solution to small and medium size businesses across Europe. By using ESS Pro, Meedio can provide dedicated hosting to large customers, and multi-tenant hosting for smaller customers.

Matrix co-opetition

Meedio already has a strong installed customer base as a result of its enterprise-grade Matrix-based video conferencing solutions in healthcare, education and contact centres. Meedio will be expanding its Matrix-based frontend clients with domain-specific messaging, collaboration and integrations. It will both compete with, and complement, Element and other Matrix-based vendors.

"We're really excited to partner with Meedio - enabling them to provide excellent domain-specific Matrix clients by leveraging the best possible Matrix distribution from the team who created Matrix - Element Server Suite Pro.

“By joining the Matrix.org Foundation C.I.C. they show their commitment to the underlying Matrix project and we look forward to collaborating with them further."

Matthew Hodgson

Co-founder, CEO/CTO Element

Meedio delivers on-premise and hosted solutions for organisations with as few as five end-users, through to large public sector organisations and enterprises.

It’s great to see another European government, this time Belgium, using the Matrix open standard as the foundation for digitally sovereign communications. Matrix enables digital sovereignty through decentralisation, self-hosting and interoperability. As a result, it gives governments full control over their data and operations. 

By choosing Matrix, Belgium ensures it can work with any Matrix-based provider, switch vendors if needed, and avoid the long-term lock-in that plagues traditional communication platforms. Even European communications vendors, such as Wire or Threema, are built around vendor dependency. And yet vendor lock-in is the very opposite of digital sovereignty.

Whereas with Matrix, a government can create its Matrix-based communications solution solely in-house by building on FOSS components. Belgium is doing exactly that, which is testimony to just how much independence a government has over its Matrix-based communications.

With great sovereignty comes great responsibility

When a government standardises on Matrix, it is building critical communications infrastructure on open source software. It’s therefore imperative that the same government does its part to ensure the open source project on which it relies is healthy and sustainable. The open source project doesn’t sustain itself automatically. It relies on funding, active participation and collaboration. 

A government that spends millions on in-house development forking an open source project is far from an open source champion. Nor is it favourable for tax-payers or the local industry, as much of that development is reinventing what already exists in the commercialised product. Three or four years down the line, a government is left with a bespoke stack that’s hugely expensive to maintain and several steps removed from the ‘digital commons’ that was so appealing in the first place.

Working with the commercial upstream vendor is far more cost effective than building from FOSS components, particularly over the medium and long term.

Mindful procurement

With European governments scrambling to free themselves from vendor-locked systems, the exuberant embrace of open source software can see some parts of government struggle to maintain pace. Senior officials from a non-technical background, and public sector procurement processes, are often fairly unfamiliar with open source software. Fuelled by the strategic imperative of technological independence, procurement teams and others can adopt a seemingly independent ‘vendorless’ approach without fully understanding the implications - that they are sawing off the very branch they are sitting on by not ensuring the health of the underlying open source project, and thus the code they rely on.

It’s quite an irony that some governments who want to free themselves from proprietary platforms are simultaneously starving the upstream vendors that develop and maintain the open source alternative on which they intend to rely - incentivising it to become more and more closed source to survive - and preventing it from keeping up with the proprietary competition.

Organisations like the Open Source Business Alliance have already published guidance to help governments appreciate the complexity of responsibly procuring open source software - ensuring that upstream vendors who maintain the overall project are suitably financed to ensure the underlying software is developed and maintained.

Learning from others

In Germany ZenDiS - which is building the digitally sovereign openDesk office productivity suite - ensures that upstream projects are directly involved and properly funded via subscriptions to the vendors’ commercial offerings; paying for what they use, to keep the overall open source healthy. Projects like BwMessenger and BundesMessenger, both developed by BWI GmbH, also demonstrate strong collaboration with the Matrix ecosystem.

Sweden’s SAFOS initiative, the European Commission’s Element deployment, the Dutch Ministry of Defence and many others all show a similar pattern; governments embracing open source while actively supporting the vendors and communities behind it.

Working with upstream vendors doesn’t just support the overall open source project. Vendors provide more experience of the technology, enterprise-grade scalability and high availability, Long Term Support distributions, well-maintained integrations, and crucial features such as identity management, group-synchronised access control and audit capability. There is a significant difference between free-of-charge software for community use and software that’s designed for a nationwide government deployment. That’s precisely where an upstream vendor adds demonstrable value, and lower total cost of ownership. And it’s that revenue that helps, in turn, fund the overall open source project.

The hybrid ideal

As one of our European government customers said to us recently: “It’s not about FOSS vs paying for subscriptions. It’s not buy vs build. It should be a hybrid approach that works for all parties.”

Sovereignty is about choice, and by adopting open standards like Matrix governments will preserve sovereignty and interoperability. Open standards give governments an ecosystem of vendors to choose from. And that is far more sovereign than locking an organisation into a multi-million a year team to maintain an in-house fork. Besides, working with commercial vendors provides the support, stability and assurance that the upstream project needs to improve and compete with proprietary incumbents.

Through ready-to-use products, operational expertise and accountability, a vendor relieves a government of considerable complexity, cost and risk. With the combination of open source and professional software, a government ensures complete digital sovereignty, and can yet still customise its solution to suit its exact requirements; a level of bespoke customisation that a software vendor typically wouldn't deliver.

Solutions like Element’s enterprise offerings provide exactly that balance; cost-effective, secure and professionally maintained - and yet ensuring the openness and flexibility that guards against vendor lock-in.

The strategic importance of digital sovereignty and the interoperability provided by an open standard revolves around a government having complete control of its data and visibility on the technology stack used. Requirements of that magnitude deserve investment, for both the solution itself and the wider open source project that is there to benefit everyone.

The Cyber Resilience Act (CRA) is a major new piece of EU legislation that aims to bring security-by-design into how digital products are developed and brought to market across Europe. Adopted at the end of 2024 and applying from late 2027 (with some requirements coming into effect towards the end of this year), the CRA introduces baseline cybersecurity requirements for any product with digital elements placed on the EU market. This ranges from connected consumer devices to infrastructure software and secure communications systems.

The regulation aims to address long-standing security failures driven by misaligned incentives. Until now, software and hardware producers have often faced limited consequences for shipping flawed products, particularly in complex supply chains. The CRA seeks to change this by embedding security obligations directly into the lifecycle of digital products, shifting responsibility towards those who place them on the market. For open source projects and the organisations that steward and commercialise them, this represents a significant shift; while the CRA promises improved security and clearer accountability, it also raises important questions about scope, responsibility, and sustainability.

These challenges were explored in detail by Denise R. S. Almeida, Head of Policy & Compliance at Element and Data Protection Officer for the Matrix.org Foundation, in a presentation delivered at the Matrix Conference 2025. Drawing on Element’s experience developing and stewarding Matrix-based products, Denise highlighted how the CRA applies to open source software in practice and shared how organisations can begin preparing during the current implementation phase.

Watch the presentation about CRA from the Matrix Conference 2025

Understanding the Cyber Resilience Act

The CRA is a regulation, meaning it applies uniformly across all EU member states. Unlike other frameworks such as the GDPR, which are primarily assessed at an organisational level, the CRA operates at a product-by-product level. This reflects a deliberate shift in regulatory thinking; risk is no longer determined by company size, but by the nature of the product itself - particularly its ability to connect to networks, process data remotely, or form part of a wider digital supply chain.

The regulation was originally motivated by security concerns in areas such as the Internet of Things, but its scope is intentionally broad. Any product with digital components placed on the EU market must now be designed and developed with security in mind from the outset - supported by documentation, incident reporting processes and ongoing vulnerability handling.

Commercial intent and open source

One of the most significant and complex aspects of the CRA for open source communities is how it treats commercialisation.

In principle, non-commercial open source software is out of scope. However, many open source projects are published under permissive licences that explicitly allow commercial use. This has led to understandable concern about where responsibility lies if open source code is later incorporated into a commercial product.

Under the CRA, obligations attach to the entity that first places a product on the market with commercial intent. Publishing open source code alone does not trigger manufacturer responsibilities. If a third party forks a project and commercialises it, responsibility for CRA compliance rests with that party - not with the original developer or maintainer. This distinction is critical in ensuring that individual contributors and hobby projects are not inadvertently burdened by regulatory obligations.

Roles and responsibilities across the supply chain

The CRA introduces a clearer delineation of roles within the digital supply chain, including manufacturers, importers, distributors and open source stewards. Importantly, the role of an open source steward can only be held by a legal person, such as a company or foundation. Natural persons - individual developers - cannot be stewards under the regulation, a safeguard designed to protect volunteers and independent contributors.

Because the CRA applies at a product level, a single organisation may hold multiple roles across different products. This is particularly relevant for organisations like Element, which develops both commercial offerings and community-facing open source projects within the Matrix ecosystem.

For products first placed on the market by Element and offered commercially, such as Element Server Suite Pro, Element assumes the role of original manufacturer. This brings with it full responsibility for CRA compliance, including security requirements, incident handling and conformity assessments. These products will also carry a CE mark, which can be self-certified and signals compliance with the regulation.

By contrast, for community projects made available without commercial intent, Element acts as an open source steward rather than a manufacturer. While strong security practices remain essential, these projects do not require CE marking or the full set of manufacturer obligations. This distinction helps preserve openness while maintaining clarity around accountability.

Security requirements and operational impact

For manufacturers, the CRA introduces a number of concrete obligations. Products must be supported by appropriate cybersecurity measures, technical documentation and clear information for users. Manufacturers are also responsible for collecting and reporting security incidents and vulnerabilities to relevant EU authorities.

For organisations that already invest in security frameworks and structured vulnerability handling, these requirements will often build on existing practices. However, the CRA formalises these expectations and introduces additional coordination across engineering, security, legal and communications teams. Compliance is not a one-off exercise, but an ongoing responsibility throughout a product’s lifecycle.

Freeriding, incentives and sustainability

The CRA may also have an indirect but important effect on long-standing challenges within open source ecosystems, including freeriding. Organisations that currently package open source software into commercial products without taking responsibility for security may now be required to develop their own compliance processes from scratch.

By contrast, products backed by a clearly identified original manufacturer and a valid CE mark may become more attractive and trustworthy. While licensing remains a key mechanism for shaping behaviour, the CRA introduces structural incentives that could encourage more responsible engagement with open source supply chains.

Risks and unresolved questions

Despite its aims, the CRA introduces real risks for open source projects. Compliance requires time, legal and commercial expertise, and funding - resources that are often scarce in open source environments. There is also concern about how enforcement will be balanced across manufacturers, importers, and distributors - and whether obligations will be applied fairly in practice.

Another open question is whether the CRA could unintentionally push organisations towards proprietary solutions in order to simplify supply chain management. Ensuring that open source remains a viable and attractive option will require careful implementation, clear guidance, and sustained dialogue between policymakers and the open source community.

Why early engagement matters

The CRA is intentionally high-level, with detailed guidance still under development - just as we were working on this blog post new draft guidance has been published and is open for consultation until the end of the month. This makes early engagement essential. Organisations and communities need time to map products, understand roles, assess gaps and adapt internal processes. Just as importantly, they need to share experiences and concerns to ensure that implementation supports security without undermining sustainability.

Handled thoughtfully, the Cyber Resilience Act has the potential to strengthen trust in digital products and align closely with open source values such as transparency, collaboration, and secure-by-design development. But achieving that outcome will depend on continued engagement, shared learning, and a clear recognition of the realities faced by open source projects.

What this means in practice at Element

At Element, this work is already underway. Whilst this is not an exhaustive list, it is already very clear to us that for a product such as Element Server Suite Pro, which was first placed on the market by Element, we are the original manufacturer under the Cyber Resilience Act. On the other hand, Element Server Suite Community is not intended for commercial use, so falls outside the scope of the CRA. 

This means that for our commercial products we are responsible for meeting the CRA’s requirements across the full product lifecycle, including secure development practices, vulnerability handling, incident reporting and regulatory compliance. As part of this, we will be providing Software Bills of Materials (SBOMs) and applying a CE mark to these products. 

Being the original manufacturer also means being the organisation to which security disclosures are directed and the entity accountable for the product’s security posture. This aligns with a principle that already underpins how we operate; if we develop and commercialise a product, we take responsibility for it.

The CRA also brings important clarity for open source more broadly. If a third party forks an open source project and commercialises their version, responsibility for CRA compliance rests with that party, not with the original developer or maintainer. In practice, this means that organisations choosing to deploy and purchase products such as Element Server Suite Pro or Synapse Pro can rely on Element to demonstrate how the regulatory and security responsibilities associated with the CRA are being met. This clarity benefits both users and the wider open source ecosystem by making accountability explicit.

On Monday the General Dutch ⁠Intelligence Agency (AIVD) and Dutch Military Intelligence and Security Service (MIVD) announced a sustained Russian-backed campaign targeting Signal and WhatsApp users. 

It follows a similar warning in February, from Germany’s Domestic Intelligence Agency (BfV) and Federal Cybersecurity Office (BSI).

The attacks are based on relatively straightforward social engineering. Signal or WhatsApp users are targeted by fake Support Chatbots and then duped into divulging PIN codes or adding the attacker to conversations through ‘link device’ functions. Much like email phishing, it’s straightforward but effective; the Dutch agencies have acknowledged that the attackers are likely to have gained access to sensitive information.

The attacks are yet another example of why consumer messaging apps are not appropriate for use within governments. Intelligence agencies and other cyber experts have continuously warned that the likes of Signal and WhatsApp are frequently targeted because their end-to-end encryption gives government users a false sense of security. Yet end-to-end encryption is pointless when you can’t trust who is in the conversation.

Signal and WhatsApp are designed for consumer use only. They do not offer organisation-level administration or management, leaving government officials vulnerable to anyone who is able to contact them. Consumer messaging apps are - from an IT department point of view - “insecure by design” and therefore the very opposite of what governments should be using. 

Secure by design

Element Server Suite Pro protects against the type of social engineering attacks targeted at Signal and WhatsApp because it provides an enterprise-grade messenger. 

Most government deployments of Element are either ‘internal-only’ or for use within a ‘closed federation’ of trusted partners. As a result, it’s extremely difficult for an external attacker to even target government employees. 

End-users are managed through an organisation’s existing directory service - the systems that are trusted to identify and control access to all the organisation’s applications, as well as supporting single sign-on. In addition to protecting against external threats, end-user management also guards against accidental invites, such as the Signalgate incident.

Element's identity and access management stops Signalgate incidents

As a further line of defence, within Element Server Suite Pro, room administrators are able to insist that end-users verify their devices to ensure that devices are trusted. 

Adopting the correct security posture

Governments and other organisations that have to prioritise security are generally good at assessing risk, and adjusting their security posture accordingly. Many of our customers, for example, use Element for communications within their air-gapped environments. Some are even introducing cross domain gateways to connect high and low side communications.

Yet other parts of those same organisations can still have a blind spot when it comes to messaging apps. While budgets exist for air-gapped networks, or to replace a collaboration suite, many find it difficult to win a new budget to provide a sovereign messenger as an alternative to the unsanctioned use of (free of charge) consumer messaging apps.

Yet governments typically require dedicated, hardened communication systems that incorporate strict access controls, monitoring, and security policies rather than relying on consumer messaging services. 

Sovereign and secure

Talking of the latest attacks, Vice-Admiral Peter Reesink, director, Dutch Military Intelligence and Security Service, says: "Despite their end-to-end encryption option, messaging apps ​such as Signal and WhatsApp should not be used as channels for classified, confidential or sensitive information." 

Signal is a centralised vendor-controlled service, from a US headquartered organisation and runs its entire service on AWS. WhatsApp is owned by US headquartered Meta, one of the world’s largest data mining companies. Neither Signal or WhatsApp offer any level of sovereignty, and both are designed purely for consumer use - creating a raft of vulnerabilities for workplace use. And as Australia’s government concluded in March 2025, they also erode the democratic process through a lack of record keeping.

As European governments embrace digitally sovereign IT strategies to improve national security, they should also move decisively to ban government officials from using Signal and WhatsApp for government-related conversations. 

Simultaneously, they need to give officials a sovereign and secure alternative.

At FOSDEM 2026, the world’s largest open source conference, Neil Johnson (Element’s Chief Engineering Officer) explored the critical role of sustainability in open source software - with a focus on decentralised networks like Matrix.

Before we begin, most people can see why the sustainability of an open source software project is important. Open source software underpins almost all pieces of critical infrastructure, and we need to find ways to safeguard these projects. 

However, why is it especially important in a decentralised network? The whole promise of a decentralised network is the absence of a single point of failure, leading to a network that is both resilient at the technical and governance levels.

However Decentralisation without sustainability is just deferred centralisation. Without long-term, structured support, power inevitably consolidates in a few central nodes. This does not just apply to Matrix, we see it in the internet at large, where we have increasing centralisation due to a failure in finding sustainable ways to support our infrastructure - we also see it in political systems. 

So what does sustainability mean for Matrix? Matrix is a very ambitious project and Matrix sustainability means building a project capable of having the same transformative impact over the next 50 years that email has had over the last 50.

Watch the whole presentation

A brief history

Matrix began in 2014, when the founding team first came together within a larger organisation. Early successes led to the creation of Element to help fund ongoing development. From there, the Matrix Foundation was established as an independent, nonprofit entity, while Element continued as a for-profit company to sustain growth and feature development.

As the project grew, it became clear that funding features was only part of the story. The true cost of development includes maintenance, support, and long-term infrastructure - all of which are cumulative and increasingly complex as the system scales.

The challenge of sustaining open source

Maintaining open source software is critical, yet traditional funding models often struggle to capture the ongoing value required. While professional services can indirectly support maintenance, this approach does not cover all the essential work. Much of what ensures Matrix’s long-term health - including core protocol development, SDK maintenance, and infrastructure operations - falls outside the scope of paid services, making dedicated support and sustainable investment vital for the ecosystem’s future.

Element contributes significantly to the ecosystem, including:

• Significant sponsorship of the Matrix spec core team and heavy investment in spec authorship.
• Maintaining Element clients, matrix.org home servers, the Rust SDK, the JS SDK, Synapse, MAS, and the admin console.
• Conducting protocol research, building long-term features, and supporting trust, safety, and compliance.
• Advising on public policy and providing legal, financial, and operational support for the Matrix Foundation.

While more and more ecosystem participants are starting to support these efforts, especially via the Governing Board, the need remains vast. Moreover, the success of Matrix paradoxically introduces new challenges: large organisations may deploy Matrix without contributing upstream, which can create gaps in sustainability.

Funding the ecosystem: open source vs. paid features

So if feature sponsorship and support contracts are not enough, what did we do instead? We need some way to hold back value without limiting growth of the eco-system at large.

Element’s approach balances open source freedom with practical sustainability:

• FOSS (Free and Open Source Software): Core features that empower end-users, including standard client functionality, cryptography, spaces, and threads.
• Paid features: Specialised enterprise functionality such as clustering, high availability, or regulatory compliance.

Licensing also plays a role. Moving from Apache 2 to AGPL ensures companies that fork the code contribute improvements back to the community. Element’s CLA guarantees that contributions remain available to the project, even under changes of leadership.

This strategy has allowed support from organisations including NATO, the European Commission, and other public institutions, demonstrating that sustainable funding is achievable in decentralised networks.

Investing in the long-term horison

Sustainability enables Element and the broader Matrix ecosystem to plan for the future. Some key initiatives currently underway include:

• Matrix 2.0: A collection of 28 MSCs (Matrix Spec Change) authored largely by Element, designed to improve client and server capabilities and allow Matrix to compete with centralised alternatives.
• Element X migration: Transitioning users to the next-generation mobile client for a smoother, more modern experience.
• ESS Community: A distribution of the Matrix stack that simplifies deployment and reduces friction for new users and organisations.
• Accessibility improvements: Ensuring Matrix can be used by everyone.
• Matrix RTC and VoIP: Building secure, real time communication with the same cryptographic guarantees as messaging.
• Rust SDK: Providing a performant, reliable foundation for all Matrix clients.
• Protocol research: Including federation security, MLS, and peer-to-peer initiatives, ensuring Matrix can evolve over time.

ESS Community: making Matrix easy to deploy

Deploying a complete Matrix 2.0 stack - including Synapse, MAS, a LiveKit backend, and the Sliding Sync proxy (while it existed) - was complex, particularly for smaller organisations or casual users. To simplify this, Element provides Element Server Suite Community (ESS Community), our official open source distribution for non-commercial Matrix deployments.

ESS Community is designed for easy setup and experimentation, making it ideal for evaluations, small to mid-sized deployments (1–100 users), or casual use. It offers a fully packaged stack aligned with Element’s robust enterprise practices, while allowing installations to complete quickly - even in live demonstrations. 

By lowering the barrier to entry, ESS Community enables new organisations to adopt Matrix easily, contribute back to the ecosystem, and explore the full capabilities of Matrix without the overhead of enterprise-grade deployments.

It’s important to note that ESS Community is a community-focused distribution. It is distributed under AGPLv3, emphasising its open source, community-driven nature while making clear that users are responsible for their own deployments. ESS Pro is designed for organisations, offering company directory integrations, audit logs, compliance tools, Mobile Device Management, Cyber Resilience Act compliance, and other enterprise-focused capabilities.

The Element X experience

If you haven’t made the move from the Element Classic app to Element X yet, now’s the time! Element X represents the next‑generation Matrix client - a complete rethink of the Element experience from the ground up. Rather than being a simple update to the existing app, Element X was rebuilt with performance, reliability, and usability at its core, drawing on modern architecture and the new Matrix 2.0 stack.

At the heart of Element X is the goal of delivering a fast, familiar, and dependable user experience across platforms. This means prioritising the things that matter most to people every day:

• Smooth migration from legacy apps — keeping continuity so users can transition seamlessly from classic Element clients to Element X without losing context or functionality.
• Full support for core Matrix features — including Spaces and Threads, with ongoing improvements to make these experiences feel intuitive and complete.
• Incremental delivery of smaller features — tackling gaps in functionality one at a time, with the aim of completing all major remaining work by April 2026. This phased approach lets users benefit from improvements now while long‑term work continues behind the scenes.
• Consistent ecosystem adoption — encouraging users and organisations across the Matrix ecosystem to standardise on Element X as the default experience, helping unify workflows and expectations

Takeaways

Thanks for following along! Over the course of my talk at FOSDEM (and this post), we’ve explored why sustainability is essential for decentralised communication, how Element X is shaping the future of Matrix clients, and how ESS Community makes it easier than ever to deploy and experiment with Matrix. We’ve also highlighted the challenges of maintaining open source software and the importance of supporting upstream development to keep the ecosystem healthy and growing.

With that in mind, here are some key takeaways:

Decentralisation without sustainability is just deferred centralisation. Supporting the Matrix ecosystem in a structured, long-term way is essential to ensure it remains truly decentralised and resilient.

Use Element X. If you haven’t already, it offers the best experience and represents the future of Matrix clients - fast, reliable, and fully featured.

Try ESS Community. It’s simple to install, robust, and enterprise-ready, making it easier than ever for new organisations to adopt and explore Matrix.

Support upstream development. Choose vendors who actively contribute to the ecosystem — sustainable funding is what drives ongoing innovation, reliability, and the long-term success of decentralised communication.

By investing in these areas, we ensure that Matrix continues to grow as a truly decentralised, user-controlled communication platform capable of serving both individuals and organisations for decades to come.

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.

Looking ahead

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.

At FOSDEM 2026, Denise R. S. Almeida (Head of Policy & Compliance at Element and Data Protection Officer for the Matrix.org Foundation) presented a practitioner perspective on the recently proposed Digital Omnibus. This ambitious legislative package proposed by the European Commission seeks to harmonise key concepts and simplify requirements across a range of digital regulations, including the General Data Protection Regulation (GDPR), the Data Act, and the ePrivacy Directive, with the goal of reducing administrative burdens and boosting innovation. However, as many have pointed out, simplification cannot be used as a justification for deregulation - especially when it comes to core definitions associated with our human rights.

She shared her perspective on what the proposal could mean for open source projects and communities using Matrix as a case study, highlighting both the opportunities and the risks it introduces.

Watch the whole presentation

Understanding the Digital Omnibus

The Digital Omnibus is a complex effort to harmonise overlapping European regulations. Its explicit goal, as defined by the European Commission, is to make compliance simpler, reduce bureaucracy, and ultimately free organisations to focus more on innovation. For open source projects, which often operate on limited budgets and volunteer-driven resources, these changes could be particularly meaningful.

Key proposals include simplified cookie rules to address consent fatigue, improved access to data, alignment of terminology across different regulations, and the creation of a unified reporting system for incidents and breaches. While nearly 200 pages in length, these proposals collectively aim to reduce friction in the regulatory environment and provide a clearer path forward for developers, organisations, and communities alike.

Opportunities for open source communities

There are a few ways the Omnibus could benefit open source projects. One of the most significant is streamlined reporting of breaches and incidents. Today, organisations must navigate multiple frameworks and timelines across different authorities. A single reporting system would allow teams to dedicate more time to understanding root causes and preventing incidents, rather than juggling administrative obligations. This poses to be the most impactful operational shift introduced by the Omnibus.

Another key opportunity is standardisation of Data Protection Impact Assessments (DPIAs). Many open source projects face the same privacy and security challenges but often tackle them independently, reinventing the wheel each time. Standardised DPIAs could provide templates and shared best practices, giving projects a head start on compliance while maintaining user trust.

Overall, reducing legal complexity and creating clearer guidance could allow open source teams to focus on development, community engagement, and innovation, rather than legal paperwork. For a sector where every contributor hour counts, these changes could have a tangible impact on productivity and creativity.

Risks and concerns

While the Omnibus focuses on the idea of “simplification”, there are also key risks, particularly around changes to the definition of personal data under the GDPR. This is effectively a risk of deregulation, the consequences of which must not be taken lightly. Currently, personal data is defined as any information that can directly or indirectly identify an individual. The Omnibus adds new nuance, expanding on the definition which could introduce ambiguity:

Ambiguity in such a foundational definition carries serious implications and would essentially amount to a form of deregulation and, as many others argue, could represent a constitutional shift to the European approach to personal data protection. It could increase complexity, confuse compliance efforts, and even create loopholes for excessive processing of personal data without any protection obligations. For open source projects, clarity and transparency are essential: contributors need confidence that sharing data and collaborating openly won’t expose them to legal uncertainty. Any dilution of core protections risks undermining the trust and transparency that open source communities rely on.

While harmonisation and simplification are welcome, they must not come disguised as deregulation or be pushed forward at the expense of personal data protections or the principles underpinning European digital sovereignty. Open source relies on predictability and clarity in law; introducing complexity into a core definition threatens both.

Why participation matters

The Omnibus is still open for consultation until March 11, 2026, in the form of the Digital Fitness Check call for evidence. This provides a critical window for the open source community to contribute. Everyone is  encouraged to review the proposals, identify potential risks, and provide feedback. This is an opportunity to ensure that regulatory harmonisation  supports innovation without compromising fundamental human rights, such as privacy.

Open source communities bring a unique perspective, balancing practical development constraints with strong commitments to user rights. By engaging with the consultation, developers, project maintainers, and contributors can help shape a framework that protects users, reduces administrative overhead, and allows open source projects to thrive.

Striking a balance

The Digital Omnibus represents a dual challenge: it promises simplification, clarity, and reduced bureaucracy, but it also introduces a serious risk of deregulation as well as complexity in areas that benefit from clarity, such as the core concept of personal data in the GDPR. Open source projects could benefit from the Omnibus if these proposals are implemented thoughtfully, but only if the foundational protections for personal data remain strong and unambiguous.

Therefore communities must actively participate, share insights, and highlight overlooked risks. Only by engaging can open source projects ensure that Europe’s regulatory framework remains strong whilst supporting innovation, safeguarding users, and strengthening trust across digital ecosystems.

Note: since her talk the European Data Protection Board (EDPB) and the European Data Protection Supervisor (EDPS) have adopted a joint opinion which highlights similar concerns to those raised at FOSDEM:

“The EDPB and the EDPS strongly urge the co-legislators not to adopt the proposed changes to the definition of personal data as they go far beyond a targeted or technical amendment of the GDPR. In addition, they do not accurately reflect and clearly go beyond the CJEU jurisprudence, and they would result in significantly narrowing the concept of personal data. The European Commission should not be entrusted to decide by an implementing act what is no longer personal data after pseudonymisation as it directly affects the scope of application of EU data protection law.”

Element’s multi-tenancy implementation of Synapse Pro has secured a Good rating in a penetration test commissioned by gematik, Germany’s national digital health agency.

The security analysis rating is an important milestone in the widespread adoption of gematik’s TI-M Pro standard, which creates a sovereign, interoperable and secure messenger for healthcare professionals, by embedding healthcare specific requirements on top of the decentralised Matrix open standard.

Gematik commissioned an external service provider to conduct the pentest. It used active exploitation techniques to assess the security status of Element's Synapse Pro multi-tenancy implementation - as used in Element Server Suite Pro for TI-Messenger - against best practice criteria, validate security mechanisms, and identify application-level vulnerabilities.

The resulting report found that: “The security of the tested application is rated as ‘Good’. Key interfaces of the Synapse Pro server, including both interfaces for Matrix clients and the server-to-server API, behaved in the examined solution in a manner consistent with a deployment scenario in which a dedicated Synapse instance is used for each tenant.”

The successful gematik pentest now brings external security validation to ESS Pro for TI-M, making it a proven and mature solution; ESS Pro for TI-M already being the server-side component in T-Systems’ TI-M ePA compliant communications solution for BARMER, which launched in July 2025.

A catalyst for local healthcare practitioners to adopt TI-Messenger

Multi-tenancy ESS Pro for TI-M is the first solution available to enable hosting providers to deliver a cost efficient TI-M Pro compliant service to family doctors, local clinics and high street pharmacies. 

Total cost of ownership efficiencies are driven by optimisations within Synapse Pro to reduce RAM usage and associated costs by around 90%, and server-side fleet management features to simplify the administration of thousands of multiple deployments.

For the first time, hosting providers now have a professional server-side solution to deliver affordable TI-M Pro compliant services profitably - even to small healthcare organisations with just a few employees.

A competitive marketplace is now ready to explode as healthcare technology providers race to provide TI-M Pro compliant communications to local healthcare providers. The ecosystem can now build their own frontend TI-M Pro clients, knowing that self-hosted ESS Pro for TI-M is a proven, cost efficient and secure solution backend.

The benefits of a professional server-side solution for TI-Messenger

Element Server Suite Pro for TI-Messenger (ESS Pro for TI-M) is the only standalone server-side product available for healthcare technology providers, enabling them to build their TI-Messenger solutions on top of a vendor-backed server built for TI-Messenger. It includes Synapse Pro, a TI-M Messenger Proxy, Push Gateway, dedicated Federation List Service for TI-M and stays aligned with evolving specifications.

Synapse Pro, an enhanced version of community Synapse, dynamically scales to save resources during low demand and automatically cover demand spikes to ensure performance. Resource savings for large single tenant deployments (meeting TI-M ePA standard) are typically in excess of 80%, and for multi-tenant (meeting the TIM Pro standard) are usually in excess of 90%. ESS Pro for TI-M also ensures stable operations with minimal downtime as it enables High Availability deployments, along with Element’s SLA, technical support and regular security updates. Perhaps most important for multi-tenancy deployments, ESS Pro for TI-M includes effective administration features to make it easy for a hosting provider to manage thousands of small hosts individually.

Organisations not using ESS Pro for TI-M have to build their own backend, typically by building from scratch on Element’s community FOSS Synapse implementation and then servicing the associated technical debt and maintenance burden. The community version of Synapse is not designed for commercial use. A host with just five end-users has a memory footprint of around 150MB, which is considerable for a service provider wanting to host 50,000 small hosts (for, say 50,000 local pharmacies) and makes providing such a service uneconomic. A subscription to ESS Pro for TI-M removes all of those challenges in an instant.

Multi-tenancy within ESS Pro for TI-M allows the pooling of resources, keeping costs predictable and performance consistent - while preserving the isolation each tenant requires. Each shard can support up to 50 tenants, with every tenant segregated at a database schema level. The solution is delivered with a Kubernetes controller to manage the shards and their tenants dynamically (via a tenant management API that is provided by Synapse Pro), and enables integration with continuous deployment tooling and GitOps processes for automation.

Similarly Element’s TI-Messenger Proxy is designed for performance, efficiency, and compliance. Built in Rust, it benefits from modern memory safety and concurrency models, reducing operational risk by eliminating data races. With an idle memory footprint of just 10 MB - compared to around 800 MB in the TI-M reference implementation - it is exceptionally resource efficient. The proxy fully complies with the latest TI-M Pro and TI-M ePA specifications, integrates with the FHIR Directory via a dedicated Federation List Service, and supports automatic, load-dependent scaling to ensure high availability and resilience.

A deep dive on multi-tenancy within ESS Pro for TI-M, given at Matrix Conference 2025.

Focus on your own frontend client

The successful pentest signals a game change for secure healthcare communications. With ESS Pro for TI-M providing a state-of-the-art server-side component for a TI-Messenger compliant solution, healthcare technology providers can focus their own development efforts on creating an outstanding frontend client for frontline healthcare professionals such as family doctors, local clinics and high street pharmacies.

Understanding and meeting healthcare professionals’ exact requirements will determine healthcare technology providers’ marketplace success, without having to focus on reinventing TI-Messenger server-side performance and features. Just as laptop and smartphone manufacturers work with semiconductor firms, the TI-Messenger ecosystem is now mature enough for healthcare technology providers to use highly specialised components as a part of their own overall solution.