Matrix is a decentralised encrypted chat protocol on which you could build something like Zulip, except decentralised and end-to-end encrypted.
Element is the actual app being trialled here, which feels more like Slack and/or Signal than Zulip. The point is that you get something you can selfhost while also interoperating with other deployments… while also encrypting the data end-to-end with Signal protocol.
I'm sure you could do some of Zulip's features on top of Matrix.
But for what it's worth, as Zulip's lead developer, every time I'm looked at whether we could have built Zulip on top of Matrix, it just feels impossible to me. And a big part of it is the architectural decisions Matrix made to support a decentralized E2EE social network, which are not required for a self-contained chat system like Zulip or Slack (which can still be bridged with other chat systems). Permissions enforcement, performance, and lots of other details really benefit from the more focused goal, where we've explicitly decided we're not building a generic distributed network architecture and are not competing with WhatsApp.
That said, I think it's great that we have multiple OSS chat systems with different strategies that are targeting different collections of niches!
I will never understand why so many organizations entrusted the communications fabric of their organization to Microsoft and SalesForce Cloud services over the last decade. If an organization can succeed in escaping Teams or Slack to Element/Matrix, that's great, even if it's a use case where Zulip would be a better end-user experience for their requirements.
Speaking as the CEO/CTO of Element... the classic Element apps on mobile were buggy, thanks to being a ~10 year old codebase with no shared code between platforms and effectively the 1st generation Matrix client. Which is why we replaced them over the last few years with Element X, with all the heavy lifting shared between iOS & Android via matrix-rust-sdk (effectively a 3rd gen Matrix SDK).
That said, 70% of our users haven't got the memo yet - we'll do a hard-upgrade when the remaining missing features in Element X (Spaces & Threads) are fully out of Labs.
Meanwhile, Element Web is lagging behind Element X - but we're now in the middle of an incremental in-place upgrade (not a big-bang rewrite, thank goodness) to use matrix-rust-sdk - see our talk from FOSDEM last Sunday for the details: https://fosdem.org/2026/schedule/event/DZJVTS-an-element-web...
> That said, 70% of our users haven't got the memo yet - we'll do a hard-upgrade when the remaining missing features in Element X (Spaces & Threads) are fully out of Labs.
This isn't users not getting the memo yet, this is users being faced with an unfortunate choice between a buggy, slow client and a new client that doesn't implement important functionality like Spaces and Threads.
Can i ask why is Element Classic even available on the Google Play Store? If you want people to move away from this?
I've only started my Matrix journey, in the form of writing bots using the matrix Python library. I'm keeping my fingers crossed, as the Matrix protocol could be really impactful.
When Element X first launched, the goal was for it to cover the personal messenger use case. This worked just fine for some people, but for many, feature parity with the old apps and parity with the web experience was a hard blocker.
Both Spaces and Threads are about to land, and there are other lower-profile features that also need rounding out. We would expect full parity by April this year. At which point migration should be an obvious choice.
I’m excited to watch the talk. I’m generally critical of Matrix, but that’s because I want it to succeed. Lately I find you’ve been doing a lot of things right, so I hope you keep going!
I assumed it was because people here are constantly telling Arathorn that Element (not ElementX) is slow and buggy, and that when they last tried the default server (circa 2019 or so) is was buggy and full of rough edges
He's (in my mind) always positive, open, and willing to admit the shortcomings of the platform he shephards... but damn does he deal with a lot of undeserved criticism (and deserved criticism, where applicable)
Federation can feel like "just a feature" but the E2E encryption (also in group chats) is a reason for Matrix to exist and a big reason why it's so slow.
"Slow" in what sense? Development? Because I self host a Conduit server and I don't ever notice messages being slow. It would be hard to notice anyway, as in a group chat people usually take some time to type in their responses.
The sync between large groups used to be slow because of amount of data, but Element X and "sliding windows" were rolled out to help with it.
AFAIK, the public Matrix server used to be slow because of a heavy load (I think), but on my self-hosted instance that's not a problem at all.
The experience of using Matrix involves a lot of sluggishness at various points in the client - waiting to decrypt messages or properly sync keys, waiting to join a room or for room search to load - these are the things that have been salient to me using multiple matrix clients with a freshly-spun-up server within the past month.
I more mindfully played a bit with my Element (web UI), and Element X (Android), and while there might something to it, and I suspect the e2e encrypted data model will always lead to some extra work required. Element seems a bit sluggish. However Element X on my Android seems butter smooth.
And event the slower Element seems far better than Discord that I'm forced to use, where I can't even scroll history without the whole thing stuttering.
I hope that at some point a focus of the Matrix project will become why this isn’t being done. A better developer experience would supercharge the ecosystem, IMO.
Matrix should be the default for anyone building a chat app, but for some reason it’s not.
They are different, and the biggest reason is (I suspect) that a Zulip workspace is self-contained while a Matrix server is able to federate with other Matrix servers.
Other European institutions are also adopting Matrix, so federation may turn out to be an important feature.
Matrix has threads. So does discord, but discords UI around them basically renders them functionally useless.
Anyway, the first goal listed in this project was to move to European sovereign solutions so Zulip failed at the first hurdle.
Given the (lack of) speed of European bureaucracy, this is likely more a reaction to the US sanctioning the ICC than the more recent Greenland saber rattling, but you'll probably see more of this in the future.
I wouldn't say Discord threads are useless - I do wish the UI made them more obvious, but I'm in many discord chats that use threads all the time.
Matrix has threads in a sense, but in this very thread the project lead is talking about how the new, ostensibly less buggy and more performant flagship client does not yet fully support them.
Element Software SARL and Element Software GmbH however are not. In practice I believe it's Element Software GmbH providing the European Commission deployment of ESS. (Both are owned by the UK topco, but at the current rate we might flip one of them to be the topco instead).
The Declaration for European Digital Sovereignty defined digital sovereignty as the EU and its Member States' ability to act autonomously and to freely choose their own solutions, while reaping the benefits of collaboration with global partners, when possible. The UK is not the EU or a member state.
Part of Russia is in Europe. Do you believe Russian products were considered?
The EU's definition of digital sovereignty included collaboration with global partners. It is obvious why UK companies could be considered more reliable global partners than US or Russian companies. A muddled concept of European was not needed to explain it. If where an open source solution was developed mattered even.
Is it functionally comparable, discussion threads and all? Or is it much closer to something like Discord?