Arathorn

no, there shouldn't be; MatrixRTC calling has finally (after only 5 years of iteration :) stabilised. The biggest change is renaming the APIs from unstable to stable URL prefixes, but this should be invisible.

Now should be quite a good time to set up a Matrix server fwiw; we are finally at the tail-end of the journey to Matrix 2.0 (instant sync; auth via OAuth; native multiparty e2ee calling; encryption which operates invisibly). https://matrix.org/blog/2026/10/30/this-week-in-matrix-2026-... gives an overview of where things are at. I'm biased, but by far the easiest and most robust way to run a Matrix stack should be https://github.com/element-hq/ess-helm#ess-community.

it sounds like you had an awful experience with a specific client and/or server combo (or perhaps multiple ones). can you share which ones? as you say, there's a lot of effort going into it, so it's important to know if impression is based on outdated knowledge or whether you or others have had a bad time with the current generation.

If the European Commission actually thought Element was absolute shit, I don't think their management would have come along to The Matrix Conference last week and presented the project as a success: https://cfp.2026.matrix.org/matrix-conference-2026/talk/YHV8.... As someone else said, the quote is pure propaganda.

Roughly speaking, the concrete disadvantages of Olm and Megolm are:

* In the current Matrix implementation, server tells the clients what the group membership is, so a server could spoof an invite to add a malicious user to a room and you'd have to rely on social mechanisms to spot it.

* There's no way to force everyone to rotate the sender key at the same time.

* On the plus side, it decentralises relatively well.

The concrete disadvantages of MLS are:

* Vanilla MLS needs a centralised sequencing function for changing group membership.

* The key bundles are much larger.

* On the plus side, only clients within the group can add new users/devices, and everyone in a given epoch shares the same group secret, so when someone rotates everyone has to rotate to participate in the new epoch.

Now, the server-controlled membership problem can be solved with Olm/Megolm if you instead have the client control the membership, using Matrix itself to define which users are authorised to be in the room, by running the Matrix DAG merge resolution on the client as well as the server. I did this a few weeks ago (in prep for The Matrix Conference next week) to show viability; it works, and has the advantage that you don't have to blow up the whole crypto implementation.

On the other hand, MLS can also be made to decentralise. DiMLS (draft-xue-mls-decentralized) isn't the only option here; DeMLS is the one we've been working with (using the Phoenix DeMLS OpenMLS fork) on the Matrix side - and works by letting MLS epochs fork and then merge again later, using puncturable functions to avoid undermining forward secrecy. This is a much bigger change; we experimented with it a few months back; details here: https://www.youtube.com/watch?v=jc7yfec3iIQ. It's promising, it works, but is much more complex and experimental.

So, TL;DR: it's possible to use olm/megolm securely (even if it's had a mixed record); I doubt strafe is doing fancy client-controlled group membership though. Separately, MLS can be used too, but it is way more complex and has its own complications. On the Matrix side we're still pursuing both (and finally making some progress, although it's a very slow burn).

right, makes sense - thanks for answering. one other question if i may: for the folks suffering malaise, was that using Element X or Elment Classic (or Element Web/Desktop)?

out of interest, is that family/friends who don't like it? or broader tech community? which bit irritates the most atm?

Black Harvest (https://www.imdb.com/title/tt0103817/) is an incredible documentary; everyone should see it.

This will be referring to enforcing MSC4311 (https://github.com/matrix-org/matrix-spec-proposals/pull/431...) stripped state validation. Synapse announced a 1 year compatibility window to avoid ecosystem fragemtnation: https://github.com/element-hq/synapse/issues/19943. However, due to MSC4311 not better outlining how to handle compatibility, another server implementation chose to enforce the MSC more rapidly, breaking compatibility with everyone who hadn't yet implemented the MSC - including Synapse, which hadn't actually implemented it yet. Speaking as the lead of the Matrix Spec Core Team, we should have handled this better. https://github.com/element-hq/synapse/pull/19723 is the Synapse implementation which is now in the process of landing.

On the point of

> speaking of weird: how is it that these models, in a sandbox, with supposedly no way to communicate with other agents, manage to find the same public wikis as a scratch pad for agent communication?

It feels somewhat plausible that they're defaulting to the same search and picking the same top result?

One trick we've been playing with on the Matrix side is figuring out how to tunnel encrypted Matrix over other transports - so you could absolutely use it, layered on top of ATproto spaces, as a way to get E2EE DMLS metadata-protected realtime voice/video/chat but tied to ATproto DIDs and permissions. We're in the final stages of (at last) finalising MatrixRTC, the E2EE group voip stuff in Matrix, which would pair nicely with this.

The "portable Matrix" idea is currently nicknamed Tachyon, and is earlier stage at this point, although I did a Matrix Live about it a few months back: https://www.youtube.com/watch?v=jc7yfec3iIQ

> you don't see the CTO coming to chat about it.

Speaking as the CTO at Element (and proj lead for Matrix), i feel like i've spent a bit too much time coming to chat about Matrix on HN over the years ;)

That said, I agree that Bluesky is doing well in terms of breaking through into mainstream awareness - much more so than Matrix (although obviously big-world-social-media is something of a different beast to distributed-instant-messaging).

The reason Matrix hasn't done better here is primarily economic: we spent too much time and money building out Matrix for everyone in the early days... and not enough time focusing on building either consumer (as Bluesky has) or enterprise or government specialised products. We then got traction at Element on the government side of things (https://element.io/en/matrix-in-europe etc) as it turns out governments love their digital sovereign communications - which in turn meant that in order to get sustainable and survive we had to focus hard on building stuff for that market. Now, ideally the stuff which works for Govt would work for mainstream too (after all, we're generally competing with Signal and WhatsApp, which are of course mainstream apps) - but in practice it has been hard to get that balance right. You can see my <del>TED Talk</del> FOSDEM 2025 talk about the road to mainstream matrix here: https://www.youtube.com/watch?v=lkCKhP1jxdk

Meanwhile, the plan on Matrix is to get to profitability via Govtech and then invest the money back into improving Element (and Matrix) so it also works well for mainstream usage - so hopefully we'll get back on the radar then. It's a long haul though. Meanwhile, kudos to Bluesky for getting to focus on the mainstream use case; I'm jealous, and I hope they find a good sustainability model!

I've been keeping a record of the increasingly opinionated vocab it fixates on:

* Projection (it seems to love to describe one data structure as a projection of another)

* Strand (if some data gets isolated/stuck, it's "on a strand" or simply "a strand")

* Load-bearing (obviously)

* Frontier (the leaf on a tree)

* Quiescence (waiting for an algorithm to settle - I guess this one is legit)

* Honest (obviously)

* Residuals (any kind of data which hasn't been consumed by an algorithm)

* Rescission (something which has been rescinded; rather than saying "a rescinded offer" it enthusiastically calls it A Rescission!)

* Supersession (it's not a session which is a superset of another session... it's the word supercession; something that supercedes; similar to preferring the participle form of rescind).

I wonder how much of this is due to it mirroring proximate things to my code's own weird vocab though.

My favourite so far has been that I accused it at one point of playing whackamole by patching issues rather than getting to the bottom of a problem, and a few hours later it started to say things like "and i found mole 2 in CI" etc. For one minute I thought it was talking about the avogadro constant or backdoors or something until I realised it had committed to start calling newly discovered bugs 'moles' in its ongoing game of whackamole...

P2P Matrix (and Matrix over DMLS) is back as of a few days ago: see https://arewep2pyet.com and in particular https://arewep2pyet.com/assets/pdf/2026-07-09%20DWebCamp%20P... :)

This is just the ~8 year old ICAP antivirus scanning system which Element has always had, built for government customer deployments who need antivirus, but implemented for Element X

https://github.com/matrix-org/matrix-content-scanner

https://github.com/element-hq/matrix-content-scanner-python

etc.

This is nothing to do with ChatControl or Online Safety Act where you can see our position here:

https://element.io/blog/the-online-safety-bill-an-attack-on-...

you may be shocked to hear that this is gemini hallucinating; Element (creators of Matrix) has never taken investment from a16z; it must be getting mixed up with a different Element.

there is a definite irony in switching from being vendorlocked to Signal (open source but closed and locked to a US non-profit) to being vendorlocked to Wire (open source but closed and locked to a German/Swiss for-profit) - talk about jumping from the frying pan into the fire :)

Meanwhile the rest of Europe (and much of the rest of Germany) seems to have converged on Matrix as a genuine open standard with various different commercial vendors (Element, Rocket Chat, Famedly, connect2x etc), avoiding vendor lock and so giving actual digital sovereignty: https://element.io/matrix-in-europe

If you're talking about https://matrix.org/blog/2026/02/analysis-of-reported-issues-..., I'm not entirely sure that characterisation is accurate :)

It's more that they haven't gone public with it yet, and it's not for us to out them :)

There's a big gap between lots of orgs using it, and lots of orgs paying for development of it. That said, BWI in Germany is currently funding custom status so it should be coming soon :)

This is true. We just published a map of it: https://element.io/en/matrix-in-europe

On the Matrix side, "unexpected" decryption errors got fixed in ~Sept 2024.

(There are still a few scenarios where e.g. if you delete your identity keys by logging out of all your clients, you may get "expected" decryption errors. We're still working on those.)

potentially wrapping their own package or distro rather than using something like ESS Community? Or perhaps they left registration open and had abuse problems?

ooh, that's cool - come tell us about it in matrix.to/#/#twim:matrix.org when it's ready :)

the main bit of auth which was left unimplemented on matrix-workers was the critical logic which authorizes traffic over federation: https://spec.matrix.org/latest/server-server-api/#authorizat...

Auth for clients is also specified in the spec - there is some scope for homeservers to freestyle, but nowadays they have to implement OIDC: https://spec.matrix.org/latest/client-server-api/#client-aut...

Yes, that's the difference. Loads of Matrix servers have nothing exposed to index, and steer clear of public rooms, and so wouldn't show up on MRS's stats.

Whereas I literally select count(*)'d from the destinations table on matrix.org, filtered on servers which had been federating in the last week(?) in order to get the specific stats above. (And then count(*) of all time for the 150K figure).

On the Matrix accessibility side, Element X has improved loads over the years - https://element.io/blog/helping-to-get-everyone-in-their-ele... and https://element.io/blog/element-is-accessible-by-design/ etc.

The idea of crowdfunding Discordish features for Matrix from disaffected Discorders (e.g. using the premium acct system we've built for matrix.org) has come up a bunch.

The problem is more that Element team is seriously stretched (particularly after the various misadventures outlined here: https://youtu.be/lkCKhP1jxdk?t=740) - so even if there was a pot of money to (say) merge custom emoji PRs... the team is more than overloaded already with commitments to folks like NATO and the UN. Meanwhile, onboarding new folks and figuring out how to do the Discordy features and launch a separately Discordy app under a Discordy server would also be a major distraction from ensuring Element gets sustainable by selling govtech messaging solutions.

So, we're caught in a catch-22 for now. One solution would be for other projects to build Discordy solutions on top of Matrix (like Cinny or Commet), or fork Element to be more Discordy (and run their own crowdfunders, perhaps in conjunction with The Matrix Foundation). Otherwise, we have to wait for Element to get sustainable via govtech work so it can eventually think about diversifying back into consumer apps.