Arathorn

this is me working with my users and trying to understand their firsthand experience for myself :)

Hmmm. The main difference between the Matrix Fdn publishing a spec (https://spec.matrix.org) made out of Matrix Spec Changes (https://spec.matrix.org/proposals) versus IETF only publishing RFCs is simply that the Matrix Fdn also maintains a consolidated version of the spec. I'm not sure that makes the protocol governance fundamentally more vulnerable to govt influence?

> Do Matrix clients still keep the oldest version of the Megolm ratchet they have ever received? When I last looked (around 2024), the libraries maintained by the Matrix.org core team did.

It entirely depends on the client. There is nothing in the protocol which means that clients have to store old keys, but many do - mainly so they have a copy that can be backed up on the server to support migrating between devices, and for history sharing, as you say. However you absolutely could configure a locked-down Matrix client which discards megolm keys after receipt.

> My understanding is that, while a _sender_ will rotate Megolm sessions every 100 or so messages, recipients tend not to: clients will accept ciphertexts sent from those old sessions for an indefinite period of time. Again, I haven't been following developments in the Matrix world for a little while, so please correct me if I'm wrong.

Yup, this is fair - and agreed that implementations could and should discard unexpected messages in those sessions. There's nothing in the protocol that stops that (but also it's not explicitly covered in the spec).

We can fix this though; thanks for flagging it (and sorry if we missed it in the RHUL research...)

thanks. we are doing our best, despite various a few misadventures along the way :)

Matrix should categorically not have any sync issues; this is not normal. Something bad must be happening on the server; what server are you using and how are you running it?

Unencrypted room search should Just Work for unencrypted rooms (it uses postgres FTS under the hood).

Encrypted room search should also Just Work... but only on Element Desktop (which uses tantivy to do clientside search). We are in the process of porting this to Element X (and Element Web), but after an initial spike over the summer we're waiting for either funding or manpower to finish it.

We explicitly built Element X to be competitive with Telegram's UX - I'm guessing that the feedback here is on the crusty old Element Classic app, which hasn't been touched for 3 years now, and definitely did feel like a laggy MSN by comparison.

Meanwhile Element X feels really really good - especially on iOS, but also Android has improved loads in the last few months (after tweaking the rustc ARM compilation flags properly, doh)

When we first announced Matrix 2.0 implementations in Sept 2024 we made a major error by not providing an easy distro, so I feel your pain.

We fast-followed with https://github.com/element-hq/ess-helm as a really easy distribution (albeit using helm charts) based on the paid offering we provide for folks for NATO and the UN and folks. It really is trivial to install now - e.g. here's a live-install from FOSDEM last weekend: https://youtu.be/EngsGD30Ow0?t=929

Meanwhile if you're allergic to k8s I went and published a trivial docker-compose at https://github.com/element-hq/element-docker-demo/ too.

> Olm/Megolm does not offer forward secrecy for group messaging

Megolm does provide forward secrecy - just in blocks of messages. If a message key gets stolen, an attacker could decrypt subsequent messages from that sending device until the next session begins: by default this happens either after 100 msgs have been sent, a week has elapsed, or if the room membership changes. Most folks consider this to be adequate perfect secrecy.

In terms of the Matrix Fdn being incorporated in the UK… I guess that means one shouldn’t use the Internet, given IETF is US incorporated? :)

Element X finally has this on Android (in Labs) now. Web & iOS will follow.

it sounds like the hackspace server has been banned from inviting due to spam or something. can you share the name of the server so we can check? or mail abuse@matrix.org with the details.

this sounds like something super weird about the setup - it really should just work. what client and server was it?

Element has put tens of millions of dollars into Matrix over the years and today provides hundreds of thousands of dollars worth of resources per year to support it.

Amandine (acting managing dir on the fdn) is preparing the public financial report of the Foundation which will have more details on this; it should be out in a few weeks.

It wasn't France (and, ironically, it wasn't funded - it was mainly us showing off)

France donates to the Matrix Foundation (which helps the protocol retain its neutrality and independence, and is very much appreciated), but doesn't currently financially support Element's dev as their upstream. We're trying to fix that though!

Manually importing/exporting keybackups is on the todo list (albeit towards the bottom). Supporting legacy calls is not (unless someone contributes it); the intention is to converge asap on native Matrix group calls.

yes, Element is venture-funded, which is where much of the money came to build all this in the first place - see the bottom of https://element.io/en/about.

Probably, but much like the sitar player's sitar in Moulin Rouge, I aim to only speak the truth :)

Element Desktop/Web (and Element X) use Element Call for proper encrypted group VoIP/Video these days rather than Jitsi - since Sept 2024. Meanwhile we're busy upgrading Element Web to use the same rust-sdk engine as Element X (although this will take a year or so).

In terms of non-Element clients... I can't really speak for them, but I hear really good things about Cinny for folks who want a more Discord-like experience on desktop, and we livecoded an Element Call integration for it at the Matrix Conference in October (hopefully it merged). I think FluffyChat also may support the new MatrixRTC calling too.

> It's far from perfect, but using a simple application with no built-in ads, AI, bloat, crap, etc is wonderful.

I think there are three main reasons it's not perfect yet:

1. Building both a decentralised open standard (Matrix) at the same time as a flagship implementation (Element) is playing on hard mode: everything has to be specified under an open governance process (https://spec.matrix.org/proposals) so that the broader ecosystem can benefit from it - while in the early years we could move fast and JFDI, the ecosystem grew much faster than we anticipated and very enthusiastically demanded a better spec process. While Matrix is built extensibly with protocol agility to let you experiment at basically every level of the stack (e.g. right now we're changing the format of user IDs in MSC4243, and the shape of room DAGs in MSC4242) in practice changes take at least ~10x longer to land than in a typical proprietary/centralised product. On the plus side, hopefully the end result ends up being more durable than some proprietary thing, but it's certainly a fun challenge.

2. As Matrix project lead, I took the "Element" use case pretty much for granted from 2019-2022: it felt like Matrix had critical mass and usage was exploding; COVID was highlighting the need for secure comms; it almost felt like we'd done most of the hard bits and finishing building out the app was a given. As a result, I started looking at the N-year horizon instead - spending Element's time working on P2P Matrix (arewep2pyet.com) as a long-term solution to Matrix's metadata footprint and to futureproof Matrix against Chat Control style dystopias... or projects like Third Room (https://thirdroom.io) to try to ensure that spatial collaboration apps didn't get centralised and vendorlocked to Meta, or bluesky on Matrix (https://matrix.org/blog/2020/12/18/introducing-cerulean/, before Jay & Paul got the gig and did atproto).

I maintain that if things had continued on the 2019-2022 trajectory then we would have been able to ship a polished Element and do the various "scifi" long-term projects too. But in practice that didn't happen, and I kinda wish that we'd spent the time focusing on polishing the core Element use case instead. Still, better late than never, in 2023 we did the necessary handbrake turn focusing exclusively on the core Element apps (Element X, Web, Call) and Element Server Suite as an excellent helm-based distro. Hopefully the results speak for themselves now (although Element Web is still being upgraded to use the same engine as Element X).

3. Finally, the thing which went wrong in 2022/2023 was not just the impact of the end of ZIPR, but the horrible realisation that the more successful Matrix got... the more incentive there would be for 3rd parties to commercialise the Apache-licensed code that Element had built (e.g. Synapse) without routing any funds to us as the upstream project. We obviously knew this would happen to some extent - we'd deliberately picked Apache to try to get as much uptake as possible. However, I hadn't realised that the % of projects willing to fund the upstream would reduce as the project got more successful - and the larger the available funds (e.g. governments offering million-dollar deals to deploy Matrix for healthcare, education etc) then you were pretty much guaranteed the % of upstream funding would go to zero.

So, we addressed this in 2023 by having to switch Element's work to AGPL, massively shrinking the company, and then doing an open-core distribution in the form of ESS Pro (https://element.io/server-suite/pro) which puts scalability (but not performance), HA, and enterprise features like antivirus, onboarding/offboarding, audit, border gateways etc behind the paywall. The rule of thumb is that if a feature empowers the end-user it goes FOSS; if it empowers the enterprise over the end-user it goes Pro. Thankfully the model seems to be working - e.g. EC is using ESS for this deployment. There's a lot more gory detail in last year's FOSDEM main-stage talk on this: https://www.youtube.com/watch?v=lkCKhP1jxdk

Eitherway, the good news is that we think we've figured out how to make this work, things are going cautiously well, and these days all of Element is laser-focused on making the Element apps & servers as good as we possibly can - while also continuing to also improve Matrix, both because we believe the world needs Matrix more than ever, and because without Matrix Element is just another boring silo'd chat app.

The bad news is that it took us a while to figure it all out (and there are still some things still to solve - e.g. abuse on the public Matrix network, finishing Hydra (see https://www.youtube.com/watch?v=-Keu8aE8t08), finishing the Element Web rework, and cough custom emoji). I'm hopeful we'll get here in the end :)

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).

If you work with lots of other entities who want full control over their own comms (e.g. other governments, other departments, other EU entities like European Parliament and Council, the UN, NATO, etc) then decentralisation or federation is a big deal.

In the public sector it's basically a requirement: it's bananas if your country's critical infrastructure ends up dependent on some a product effectively controlled by another country (e.g. Teams) - and you obviously want to be able to communicate with other govt entities rather than being stuck in an island.

Then it's a natural extension to the private sector - although for now, it feels more folks are on the "nobody got sacked for using Teams" train.

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...

talking about Teams, right? O:-)

When did you try it? Both Matrix the protocol and implementations like Element X have improved immeasurably over the last year or so.

https://github.com/element-hq/ess-helm (aka ESS Community) is Element’s FOSS distro fwiw.

Element’s topco may be UK based for now, but the vast majority of our business and footprint is in the EU - https://element.io/en/about. All but one of our mobile app team is in the EU for instance (and when we started, the UK was too :|)

it’s also not decentralised (unless you bridge it to Matrix), nor end-to-end-encrypted. or standards based.

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.

We’re not trying to obscure anything: we very well know that Tchap’s adoption of Matrix and their current support (Foundation membership, code contributions to Element Web, evangelisation to other countries, etc.) are key to our success, and we are very grateful for it.

We’re just stating facts: DINUM stopped funding upstream development at Element in 2022/2023 when their post-COVID funding evaporated, and this then directly contributed to the licensing changes at Element at the end of 2023 (https://element.io/blog/element-to-adopt-agplv3/) as we tried to figure out a way to survive (which, thankfully, worked).

But we also know that the Tchap team is very budget constrained internally themselves to keep it running, despite the growing criticality and huge visibility of the service, and are trying to find ways to fix the situation at every level.

This is not a challenge limited to France: the question of how to support the upstream when heavily using open source was one of the top topics of last week’s Open Source Week in Brussels, involving folks at every level in European government.