Arathorn

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.

that would be a bit like w3c.org not running a web server on their domain…?

We're taking it for granted that people do not want to be tracked on the internet, and certainly don't want everyone to have to verify themselves on every site they use. I personally spent ages of time campaigning against the legislation (and lost) - e.g. https://matrix.org/blog/2021/05/19/how-the-uk-s-online-safet... and https://element.io/blog/the-online-safety-bill-an-attack-on-... etc.

The difference with Discord is that Matrix is a protocol, not a service. It's made up of thousands of servers run by different people in different countries. Public instances may choose to verify users in affected countries to abide by the law; others may choose to run a private instance instead.

That post is 2023 vintage and is both outdated and questionable in parts.

19. "media downloads are unauthenticated by default" -> fixed in Jun 2024: https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...

20. "ask someone else’s homeserver to replicate media" -> also fixed by authenticated media

21. "media uploads are unverified by default" - for E2EE this is very much a feature; running file transfers through an antivirus scanner would break E2EE. (Some enterprisey clients like Element Pro do offer scanning at download, but you typically wouldn't want to do it at upload given by the time people download the AV defs might be stale). For non-encrypted media, content can and is scanned on upload - e.g. by https://github.com/matrix-org/synapse-spamcheck-badlist

22. "all it takes is for one of your users to request media from an undesirable room for your homeserver to also serve up copies of it" - yes, this is true. similarly, if you host an IMAP server for your friends, and one of them gets spammed with illegal content, it unfortunately becomes your problem.

In terms of "invisible events in rooms can somehow download abusive content onto servers and clients" - I'm not aware of how that would work. Clients obviously download media when users try to view it; if the event is invisible then the client won't try to render it and won't try to download the media.

Nowadays many clients hide media in public rooms, so you have to manually click on the blurhash to download the file to your server anyway.

I wrote the OP, so to try to clarify:

isn't Matrix based out of the UK and primary hosted instances on AWS in the UK?

It doesn't matter what country you run your server in or where your company is based; if you're providing public signup to a chat server then the countries (UK, AU, NZ etc) which require age verification will object if you don't age verify the users from those countries. (This is why Discord is doing it, despite being US HQ'd). In other words, the fact that The Matrix.org Foundation happens to be UK HQ'd doesn't affect the situation particularly.

(Edit: also, as others have pointed out, Matrix is a protocol, not a service or a product. The Matrix Foundation is effectively a standards body which happens to run the matrix.org server instance, but the jurisdiction that the standards body is incorporated in makes little difference - just like IETF being US-based doesn't mean the Internet is actually controlled by the US govt).

Their solution is for everyone to pay for Matrix with a credit card to verify age.

Verifying users in affected countries based on owning a credit card is one solution we're proposing; suspect there will be other ways to do so too. However: this would only apply on the matrix.org server instance. Meanwhile, there are 23,306 other servers currently federating with matrix.org (out of a total of 156,055) - and those other servers, if they provide public signup, can figure out how to solve the problem in their own way.

Also, the current plan on the matrix.org server is to only verify users who are in affected countries (as opposed to try to verify the whole userbase as Discord is).

...and while we have no choice but implement it on the matrix.org instance, other folks running their own servers are responsible for their own choices.

https://gitlab.gnome.org/World/Chatty/-/tree/main/src/matrix... might be able to help you?

The devil is in the details on this. The core concern was that libolm (the obsolete C impl of e2ee in Matrix) used crypto primitives which don’t protect from timing attacks.

However, in practice, this was not exploitable: the only way to exercise these primitives was over the network, where network latency and request rate limiting mitigates such attacks.

Meanwhile, we had already rewritten and replaced libolm with vodozemac, a pure rust implementation using robust primitives, shipped in the major Matrix SDKs and implementations like Element and Element X.

I’m not sure this counts as alarmingly cavalier. I do regret libolm ever going into production with substandard primitives from a hygiene perspective, but we fixed it as soon as we could via vodozemac, and meanwhile included the safety warning.

cool! would be even cooler to hook it up to https://github.com/matrix-org/matrix-rust-sdk/issues/5350 when it should then just work?

matui looks super fun - you should come tell https://matrix.to/#/#twim:matrix.org about it :)

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.