Matrix.org - General

Project Hydra: Improving state resolution in Matrix

2025-08-14T00:00:00+00:00

Hi all,
On July 16th 2025 we issued a pre-disclosure</a> for vulnerabilities in the federation protocol, and announced new releases</a> of Matrix homeservers on Mon August 11. Today we are ending the embargo and disclosing the remaining MSCs. This post will go into more detail about the changes and what led up to them.
This project has the codename “Hydra” and is an ongoing exercise in improving the security of the federation protocol. Given the security-sensitive nature of this work, it was done under embargo by the backend team at Element, the Matrix.org Security Team, the Spec Core Team, alongside Timo Kösters (who privately reported a related vulnerability, helping jumpstart the project) and Florian Jacob (at Karlsruher Institut für Technologie). The work was subsequently shared, reviewed and MSC’d under embargo with maintainers of all known Matrix homeserver implementations which implement State Resolution 2.0 on June 13th, so they could prepare for the coordinated release on August 11. We have then given server admins 3 more days to upgrade before lifting the embargo and disclosing the vulnerability details here.
This entire process has been highly unusual for the ecosystem, and it’s unfortunate that we were unable to make these changes out in the open. Where possible, we moved to release redacted versions of the MSCs as soon as we were comfortable from a security perspective (e.g. releasing MSC4289</a> and MSC4291</a> ahead of time, with redacted sections). Furthermore, we’d like to apologise for the disruption in landing a new stable room version and specification release with immediate effect rather than allowing for a period of public review. Going forwards, normal MSC work will continue in public as it ever has, along with normal on-cycle specification releases. 
🔗</a>Key Information</h2>
The MSCs added under embargo were:

MSC4289</a>: Explicitly privilege room creators</li>
MSC4291</a>: Room IDs as hashes of the create event, which resolves CVE-2025-54315</a></li>
MSC4297</a>: State Resolution v2.1, which resolves CVE-2025-49090</a></li>
MSC4304</a>: Room Version 12</li> </ul>
Supporting these MSCs are:

Server-agnostic Complement tests</a></li>
The specification PR introducing room version 12</a></li>
The implementor’s guide to State Res 2.1</a></li>
Creator power level in room version 12</a></li> </ul>
These changes fixed the following vulnerabilities:

CVE-2025-49090</a>: The Matrix State Resolution algorithm before version 2.1 exhibits undesirable behavior in certain edge conditions, resulting in state resets: the scenario of a room's state resetting to an earlier or incorrect state in the absence of revocation events that would validly result in that state. This allows a malicious participating homeserver to potentially corrupt a room's state by sending a crafted sequence of Matrix events and API responses. Room version 12 resolves the issue by switching to State Resolution v2.1</li>
CVE-2025-54315</a>: Matrix rooms before version 12 do not strongly (i.e. cryptographically) enforce the uniqueness of a room's creation event. While mitigating mechanisms exist which prevent exploitation of the issue in practice, this is a protocol soundness issue. Matrix room version 12 fixes this by making the room ID equal to the hash of the room's creation event.</li> </ul>
🔗</a>Impact</h2>
These issues only affect servers which are federating with untrusted or potentially malicious servers, such as participating in the public Matrix network. Servers which are not federated, or which federate in private trusted networks such as BwMessenger, Tchap or TI-Messenger are not affected.
The impact of these issues is rated as ‘high’ rather than ‘critical’ as they do not result in data compromise or exposure. Instead, the risk here is of a malicious homeserver operator corrupting the chatroom’s state by resetting it to a prior value (e.g. reverting access control or room membership to an earlier configuration). This does not expose conversation history nor any additional data. We are not aware of these issues being exploited, but would recommend server admins to upgrade immediately if they are operating rooms with users participating from untrusted servers, as per Monday’s announcement</a>. Room admins should then upgrade such rooms to version 12 to guard against these attacks in future - see the new room upgrade guide</a>.
🔗</a>Summary of changes</h2>
This project has resulted in four new Matrix Spec Change proposals to the protocol. At high level, these are:
MSC4289</a>: “Explicitly privilege room creators”. This makes explicit the fact that room creators have 'infinite' power level. The reason we've done this is because in practice the creator’s server can already effectively control a room by backdating events: access control requires a hierarchy, and the creator is at the top of this hierarchy. This also adds the concept of multiple creators, to avoid control of rooms being centralised on a single server, and to support rooms where ownership genuinely needs to be shared between multiple users (e.g. DMs). It’s worth noting this does not impact decentralisation – the creators can still sit on multiple servers, and the room itself is replicated equally over participating servers. Instead, it’s just recognising that access control requires someone to be at the top of the hierarchy, and that person is the room creator. Separately, we’re looking at approaches to prevent backdating in general by adding ‘finality’ to Matrix.
This MSC also solves the age-old problem</a> where admins could lose control of their own rooms by promoting other users to admin or demoting themselves: now, the creator can always fix such situations. If creators go rogue or disappear, the solution is to establish a new creator by either upgrading the room or creating a new one. Given whoever upgrades a room becomes its new creator, we've changed the default power level needed to upgrade a room to be 150, referred to as 'owner' power level. This allows the room creator to effectively delegate permission to upgrade the room (and so become the new creator) to specific admins by explicitly giving them power level 150.
MSC4291</a>: “Room IDs as hashes of the create event”. This changes the format of room IDs so that they are literally the same as the event ID of the create event. This is a precautionary measure to prevent a potential theoretical class of attacks where malicious server admins could try to introduce false m.room.create events into a room in order to hijack it.
MSC4297</a>: “State Resolution v2.1”. This is an incremental change over the current State Resolution 2.0 algorithm, which protects against various classes of 'state resets', where delayed federation traffic could cause key-value state associated with a room to revert to an earlier state. This caused symptoms such as users being re-added into a room they have left, or the server no longer recognising users as being present in a room, or access control resetting to a previous state. The new algorithm works by changing the starting state on top of which conflicting events are replayed and it replays more events than previously (replaying not just the conflicted events but all the events in between any two conflicted events—the conflicted state subgraph). This fixes state resets observed in the rooms including: #rust, the Office of the Matrix.org Foundation, the TWIM room, Techlore and Furrytech.
MSC4304</a>: “Room Version 12”. This simply defines the combination of the previous 3 MSCs as room version 12.
For full technical details, please read the actual MSCs: MSC4289</a>, MSC4291</a>, MSC4297</a> and MSC4304</a>.
🔗</a>History</h2>
Matrix optimistically applies changes to room state without waiting for all servers to achieve consensus. This means that sometimes servers will update the room state (e.g. modify the room name) while concurrently, they lose their permission to set said room state (e.g. the user changing the room name is banned). When this happens, the room name change gets rolled back to its previous value. Counterintuitively this can happen even when there is no specific event that causes the user to lose their permission to set room state. This unexpected class of rollbacks is called a “state reset”.
Work on fixing known cases of state resets in the current State Resolution 2.0 algorithm began in 2022 when David Robertson</a> on Element’s backend team investigated known occurrences of the problem that were happening on the public network. He made good progress on identifying the root causes of these occurrences, resulting in the State Resolution v2.1 algorithm. Unfortunately, lack of funding</a> meant work had to be paused. (N.B. if your organisation is operationally dependent on Matrix’s security, please contribute financially by joining the Foundation as a member</a> in order to fund security work like this.)
The project was then resumed at the end of 2024 as part of a general security review by Element’s backend team and the Matrix Foundation security team which ultimately resulted in MSC4297</a>. Broadly speaking, State Resolution v2.1 makes two changes: it changes the starting state on top of which conflicting events are replayed and it replays more events than previously (replaying not just the conflicted events but all the events in between any two conflicted events—the conflicted state subgraph). This fixes state resets observed in public rooms including: #rust, the Office of the Matrix.org Foundation, the TWIM room, Techlore and Furrytech.
This work coincided with Timo Kösters highlighting an issue to security@matrix.org</a> that the room creator always has had complete power over the room and dominates other admins. This works even if the creator had left the room or gave away their admin permissions in the past. This spurred the creation of MSC4289</a> which formally acknowledges the power that creators have over every other member in the room. We’d like to thank Timo for reporting these points to security@matrix.org</a> and we will be adding him to the Security Hall of Fame.
The security review also brought to light another potentially serious vulnerability in the federation protocol. Our on-paper analysis suggested it may be possible to replace the create event in the room. If so, this would have grave consequences as all permissions in the room are derived from the create event.
However, when we tried to reproduce the vulnerability in real implementations we found that they were not vulnerable due to the way those implementations handled rejected events. Nevertheless, the protocol was missing a strong guarantee that there can never be multiple create events for the same room. This was sufficiently worrying as a soundness issue to warrant fixing, and so MSC4291</a> was created to guarantee that each room has exactly one immutable create event.
We took the unusual decision to embargo these MSCs due to risk of exploitation, taking each in turn:

MSC4289</a>: The risk of a room created by a user on a server that is no longer trusted, using their creator powers to disrupt the room</li>
MSC4291</a>: The risk of an unknown vector allowing multiple create events to be accepted into a room, allowing rooms to be taken over.</li>
MSC4297</a>: The risk of manipulation of the federation re-sync mechanism allowing state resets to be intentionally triggered.</li> </ul>
These MSCs were reviewed under embargo by the SCT and server implementors, and passed final comment period for merge. These MSCs are bundled up into room version 12</a>, expected to be released formally in Matrix 1.16 later this month.
This work fixes the most common set of state resets we’ve seen in the wild, although we’re continuing work on Hydra. We’ll be doing as much of this work as possible in the open to minimise any future embargoes. We’d like to thank all the server implementors (Conduit</a>, Continuwuity</a>, ejabberd</a>, Dendrite</a>, Rocket.chat</a>, Synapse</a>, Synapse Pro</a> and Tuwunel</a>) who took the time to make these changes at such short notice.
We’d also like to thank the client/bot/bridge implementors for accommodating the client-side breaking changes introduced in room version 12, particularly around the new power level semantics and room ID format change.
Finally, we’d like to thank the community at large, particularly those who have been disrupted and have had to upgrade rooms in response to this work. Thanks all for your patience, and we look forward to a talk all about this at the Matrix Conference</a> in October!

How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver

2025-07-23T00:00:00+00:00

Greetings from Element's backend/SRE team, who run the matrix.org</code> homeserver</a> on behalf of the Matrix.org Foundation.
Recently users of the matrix.org</code> homeserver began seeing problems where rooms would simply stop working</a>. Operations such as sending a new message, or joining the room as a new member, would fail for mysterious reasons. Where an error message was shown at all, it tended to be something cryptic like "No create event in auth events".
After a couple of weeks of hard work by a team of Element staff including backend developers and systems engineers, we were able to repair almost all of the affected rooms. Although we're still investigating exactly what went wrong and checking that everything is now working as it should, we'd like to share some details about what we know and the work we've done to date.
We'll be diving into some quite technical details. Hopefully you'll find it interesting learning a bit about how Synapse works, how Postgres works, and the work we sometimes find ourselves doing to keep the matrix.org</code> homeserver running.
🔗</a>TL;DR</h2> Let's start with a high-level summary. The matrix.org</code> homeserver is backed by a large PostgreSQL database instance. Parts of an index on one of tables in this database had become corrupted. We are unsure exactly what caused this corruption, but believe it happened at least a year ago, and likely significantly longer. The nature of this corruption was such that it had little or no effect at first. However, a background maintenance task which removes old, unreferenced data from this table recently started working on the corrupted region. Due to the corrupt index, the maintenance task incorrectly removed active data from the table, in effect corrupting rooms. Having identified the problem, we rebuilt the corrupted index, and then restored the data that had been incorrectly removed, from database backups. 🔗</a>Initial investigations, or "what exactly is a state group?"</h2> We were first alerted to the problem via a bug report</a> from a user, and similar reports in public Matrix rooms and other social media. As more anecdotal reports came in, we started to investigate what was going on. To understand what we found, you'll need to understand what we mean by a "state group". As most readers probably know, Matrix allows applications to associate "state" with a room. In contrast to "message" events which are normal messages that fit at one particular point in the timeline, state sticks around, visible to all, until it is replaced. One example of state is a user's room membership — whether or not they are currently a member of that room. Another example is m.room.name</code>, which, as the name implies, holds the room's name. Yet another type of state is the "create event": this is the very first event that happened in a room. The create event is somewhat special in that it can never be changed, but we still always expect it to be part of the room state. Obviously, the state of a room changes over time. What may be less obvious is that a homeserver often needs to know what the state of a room was at some point in the past, to answer questions such as "should this user be allowed to see this event" or "should I accept this event that has been sent to me over federation from another homeserver". Whilst in theory we could figure out what the state was at any given point in history by replaying each event that happened in the room before that point, that would be extremely computationally intensive. So in practice, homeservers end up storing what amounts to a snapshot of the room state at each historical event. Of course, regular events don't change the state of the room, so there is no point actually storing the state at each of those events. So, at last we can understand what a "state group" is: Synapse groups together a set of events in a given room, where the state in that room remained unchanged. In other words, a run of m.room.message</code> events (normal room messages) will likely all share the same "state group". Once somebody changes the room state (for example, by joining the room), we'll start a new state group, and subsequent events will be part of that new state group. The diagram below illustrates this. Blue creates a new room, and Yellow joins. The first few events each change the state of the room, meaning that each new event goes into a new state group. But events F</code> and G</code> are regular messages, meaning they don't change the state of the room. The room state after each of events E</code>, F</code> and G</code> is the same, so they can all be in state group 5. Things get a bit more complicated at H</code> and I</code>: both Yellow and Blue try to change the name at the same time, so the state after H</code> includes H</code> and the state after I</code> includes I</code>. The state resolution algorithm determines that I</code> ends up "winning", so the state after J</code> includes I</code> and not H</code>, meaning that J</code> (and K</code>) can share state group 7 with I</code>. Now, when we started investigating the rooms where people had reported problems, we found clear signs of corrupted state groups. For example, the state in some of the state groups in affected rooms was completely empty. As I said earlier, the room's create event is always part of the state of a room, and it can never change, so finding state groups whose state does not at least include a create event was a big red flag. This also gives a clue to the meaning of that error I mentioned earlier: when we decide whether to accept an event into the room, we check the state of the room. One of the things we check for is the presence of a create event: "No create event in auth events" means Synapse rejected the new event because there was no create event in the room state. There's one more wrinkle we'll need to understand about state groups. As you can see in the diagram above, most state groups only differ very slightly (typically by a single piece of state) from the previous state group in the same room. Storing a complete snapshot of the state every time the state in a room changes would be very expensive in terms of storage. So instead, Synapse normally just stores the difference from an earlier state group; then, to stop lookups becoming too expensive, we store a complete snapshot every 100 state groups or so. Again, you can see that "compression" technique at play in the diagram above. Most state groups have a grey arrow representing the link to the previous state group, meaning that each state group only needs to store the delta from the previous state group (shown in bold whilst those states implied by the "previous" link are greyed out). State groups 1 and 8 are stored as complete snapshots. Synapse stores all this data in its database: the event_to_state_groups</code> table tells us which state group each event is in, state_groups_state</code> stores the actual state snapshot or delta for that state group, and state_group_edges</code> gives us the previous state group for delta-stored state groups. 🔗</a>The hunt for suspects</h2> Thanks to the way Matrix works, once Synapse has created a state group, we very rarely ever have to change it. (If more events arrive, they may be assigned to an existing state group, but the state group itself, and the room state for that state group, remain unchanged). The only exceptions are: the state compressor</a>, which rewrites state groups so that they can be stored more efficiently.</li> purge operations, where all or part of a room's history is removed from the database, making the corresponding state groups redundant.</li> a cleanup job which removes state groups which were created but never used.</li> </ul> ... and of course, the creation of the state group in the first place. At least that gave us a place to start looking, but since we hadn't made any changes to those areas of the code recently, we were still at a bit of a loss. The state compressor was easy to rule out, at least, since it runs as a separate process and we were certain it wasn't running on matrix.org</code>. As a precaution, we temporarily disabled the cleanup job that removes redundant state groups. We couldn't figure out how it could cause the problem, but better safe than sorry, and disabling it would just mean we used a bit more disk space for a while. 🔗</a>More evidence comes to light</h2> Our next step was to try and figure out when the problem started. Searching the logs for one Synapse process gave some clear, and worrying, results: 2025-06-24: 0 results for “No create event”</li> 2025-06-25: 0 results for “No create event”</li> 2025-06-26: 0 results for “No create event”</li> 2025-06-27: 48 results for “No create event”</li> 2025-06-28: 1100 results for “No create event”</li> 2025-06-29: 3610 results for “No create event”</li> 2025-06-30: 6902 results for “No create event”</li> </ul> So, we double-checked for changes that had been made around 27th June, and still didn't find anything. We considered rolling back Synapse to an older version, but since we couldn't figure out what had changed, we didn't know how far we would have to roll back. What's more, we found state groups that must have been fine initially (say, on 2025-06-29) were now corrupt: in other words, this confirmed that the problem wasn't that we were creating new, invalid state groups, but there was a process somewhere in the system that was corrupting existing state groups. The diagram below illustrates the problem. The state in state group 4 has been corrupted, meaning that that state group (and state groups 5, 6, and 7 which all reference it) are now missing an important part of the room state, and events will not be authorised. 🔗</a>Some remedial steps</h2> Now that we knew we were dealing with data loss, it seemed likely that we would need to restore data from backup, so started the process of restoring the database backup from 26th June into a new Postgres instance hosted in Amazon EC2. The restore process takes several hours, so we wanted to get it started. On the other hand, it would leave the Matrix Foundation an EC2 bill of hundreds of USD per day for an EC2 instance large enough to host the database! We also set up a guard against further corruption: we added</a> a Postgres "constraint" which would reject any SQL queries which attempted to delete the state from a state group while that state group was still in use. 🔗</a>A culprit emerges</h2> By this point, it was the morning of 3rd July. The cleanup job had been disabled for 24 hours, and we hadn't seen any further corruption. Now that we had the protective constraint in place, we decided to re-enable the cleanup job, and see what happened. Almost immediately, we could see that the cleanup job was hitting the constraint. From the Postgres logs: 2025-07-03 12:30:38.250 UTC [matrix background_worker1] ERROR: Deleting state_groups_state row when it still exists in state_groups_edges: prev_state_group = 963361509 </code></pre> ... meaning it was trying to delete the state for state group 963361509</code> while that state group was still in use. The Synapse logs, meanwhile, suggested it was actually trying to delete completely different state groups. Was it a bug in Synapse? Or the Python Postgres driver</a>? We spent a while narrowing down the problem, even resorting to tcpdump</a> to see what was happening between Synapse and the database. With tcpdump</code>, we could see DELETE</code> queries being made, but none which would affect state group 963361509</code>. Maybe this was actually a bug in PgCat</a>, which we use to pool Postgres connections? Or even in Postgres itself? We tried replaying the query that tcpdump</code> had captured. Here's a screenshot from our ops room: Oh wow indeed. That shouldn't happen. We narrowed the problem down to one particular state group: 483128098</code>. What happens if we just try and read that state group from the database? matrix=> SELECT state_group, room_id FROM state_groups_state WHERE state_group = 483128098; state_group | room_id ------------+---------------------------------------- 483128098 | !XtFbidoIcAVPuQtXcG:matrix.org 963361875 | !IvVovpFpWhKsKMCGCO:irc.snt.utwente.nl 483128098 | !XtFbidoIcAVPuQtXcG:matrix.org (3 rows) </code></pre> Oh dear. Once your database starts returning nonsense results, you're going to be in for a bad time. What it meant here was that, although the cleanup job was (correctly) trying to clean up state group 483128098</code>, Postgres would also delete the data for state group 963361875</code>. Suddenly things started to make sense: rooms were getting corrupted by cleanup jobs for completely unrelated rooms. We've encountered Postgres index corruption before</a>, and this matched the symptoms perfectly. In short: the index entries for state group 483128098</code> point to the wrong place in the main table data (the "heap"). So, if we did a query that Postgres could answer by just looking at the index, we'd get plausible-looking results: matrix=> SELECT state_group, type FROM state_groups_state WHERE state_group = 483128098; state_group | type ------------+-------------- 483128098 | m.room.member 483128098 | m.room.member 483128098 | m.room.member (3 rows) </code></pre> ... but as soon as Postgres had to look at the heap, it would return nonsense, as above. 🔗</a>Give it to me straight, doc</h2> The good news, such as it was, was that we could now be reasonably certain that other homeservers would not be affected: this was data corruption on the matrix.org</code> Postgres instance. On the other hand, we had no idea how extensive the corruption was, when it had happened, or if it was still happening. We did several things to try to assess the damage. The first thing to check was whether both Postgres instances had the same problem. (We replicate all our data to a warm standby server using streaming replication</a> so that we can fail over rapidly in the event of a hardware failure.) As far as we could tell, both servers had identical corruption. Secondly, we wrote a script which sampled the state_groups_state</code> table to look for corruption. It told us that the problem was worryingly large: millions of state groups were affected. But for some reason, it only seemed to affect state groups in the range 147M - 541M. (State group 541M was created in January 2021. As of July 2025, we're now up to 1040M.) We also ran pg_amcheck</a> on the affected index. This is a tool that forms part of the Postgres distribution, and it checks for inconsistencies in all or part of a database. It took a while, but didn't return any problems. This mostly told us that amcheck</code> couldn't detect this sort of corruption, but one thing it checks is that all rows in the table also appear in the index; so now we knew that we weren't missing any index rows — we just had extra ones. Meanwhile, we tried reaching out</a> to the helpful folks on the pgsql-general</code> mailing list. We figured if anyone knew what could have caused this, they would. The final thing we did at this point was to take a look at the actual index data with pageinspect</a>, to see if there were any clues there. It didn't really tell us anything we didn't already know (i.e., that the index rows were pointing at the wrong place in the heap), but it was interesting to check out the structure of the index. 🔗</a>A deeper dive into Postgres indexes</h2> On the morning of 4th July, our backup from 26th June at last finished restoring. That meant two things: first, we could check if it had the same index corruption as our primary and secondary servers (it did), and secondly, we could start to think about how to repair the damage. We noticed something else interesting, though. On the production servers, some index entries pointed to state groups which didn't yet exist on 26th June: -- On the production database matrix=> SELECT state_group, type, ctid FROM state_groups_state WHERE state_group = 353864583; state_group | type | ctid -------------+---------------------------+---------------- 353864583 | m.room.member | (39060361,12) 1034753774 | m.room.member | (264925234,54) 1034753810 | im.vector.modular.widgets | (264925240,54) 1034753803 | m.room.member | (264925252,54) 1034753803 | m.room.member | (264925252,55) (5 rows) </code></pre> (ctid</code>, or "current tuple ID" is Postgres's internal identifier for a row in a table: the format is a page</a> number, followed by an offset within that page. We'll return to ctid</code>s in a minute.) Those state groups (1034753774</code> etc.) were only created on 3rd July, so clearly the backup will look different. Indeed: -- On the restored backup matrix=# SELECT state_group, type, ctid FROM state_groups_state WHERE state_group = 353864583; state_group | type | ctid -------------+---------------+--------------- 353864583 | m.room.member | (39060361,12) (1 row) </code></pre> Did that mean that the corruption was ongoing? Time for another look with pageinspect</code>. As with most Postgres indexes, this one is a B-Tree</a>. To find a specific entry, you start at the "root" of the tree (a single page which covers the whole table, but with very coarse index entries: there might be one sub-page for all the A's, for example, and another for all the B's), and work down the tree until you get to the right "leaf" page. On our restored backup, we manually walked the tree to find the leaf index pages for state group 353864583</code>. Turned out, there were several pages of entries: it seems like, at some point in the past, this state group had lots of state associated with it. Anyway, the interesting page was this: -- On the restored backup matrix=# select ctid, left(data, 77) as data from bt_page_items('state_groups_state_type_idx', 192904826); ctid | data ----------------+------------------------------------------------------------------------------- (264925236,41) | 87 8b 17 15 00 00 00 00 1d 6d 2e 72 6f 6f 6d 2e 6d 65 6d 62 65 72 35 40 66 72 (264925234,54) | 87 8b 17 15 00 00 00 00 1d 6d 2e 72 6f 6f 6d 2e 6d 65 6d 62 65 72 4b 40 66 72 (264925235,54) | 87 8b 17 15 00 00 00 00 1d 6d 2e 72 6f 6f 6d 2e 6d 65 6d 62 65 72 47 40 66 72 (3 rows) </code></pre> Being a leaf index page, the ctid</code> points to the actual row in the heap. This is an index on (state_group, type, state_key)</code>, so the data</code> here is: a little-endian 64-bit representation of 353864583</code></li> a length/flags byte (1d</code> => 13 bytes of uncompressed text)</li> the event type (m.room.member</code>)</li> another length/flags byte</li> the state_key</code>: a user ID, which I've truncated in the above for brevity and privacy.</li> </ul> The point is, even in the backup, we have index rows pointing to heap tuple (264925234,54)</code>. And what is at that heap tuple? matrix=# SELECT * FROM heap_page_items(get_raw_page('state_groups_state', 264925234)); lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 | t_ctid | t_infomask2 | t_infomask | t_hoff | t_bits | t_oid | t_data ----+--------+----------+--------+--------+--------+----------+--------+-------------+------------+--------+--------+-------+-------- 1 | 0 | 0 | 0 | | | | | | | | | | (1 row) </code></pre> Nothing at all. That tuple doesn't exist. It's just empty space in the table data. Finally, we can understand a bit about what's happened here. The corruption is not ongoing. Rather, the index was already corrupt at the time the backup was taken, but the index rows point into empty space -- and apparently Postgres ignores such index rows. Then, on 3rd July, that empty space got used for state group 1034753774</code>, meaning that the index entry for state group 353864583</code> now points to the data for state group 1034753774</code>. This tells us something else interesting: this corruption could have been there for months or years, without anyone noticing. It was only once Postgres started populating that bit of table space that any problem would have been observable. So why was the index entry pointing at empty space? That's a great question, and something we spent a long time discussing. Presumably, at some point in the past, we used to have lots of entries in state_groups_state</code> for state group 353864583</code>. Then, most of these entries were removed (likely by the state compressor</a>), causing a bunch of free space to be created in the table data -- but for some reason, the index entries for those rows didn't get correctly cleaned up, leaving them dangling. 🔗</a>Repairing the damage</h2> We now had enough information to start to get things working again. The first priority was to get Postgres back to a consistent state. That meant rebuilding the index, which in itself wasn't trivial, given the index takes up over 4 TB — but we had just enough spare disk, so we set the reindex going overnight. Next, we needed to repair any state groups which were incorrectly modified by the cleanup job due to the corrupt index. To do this, we considered the range of state groups that the cleanup job had been working on, and wrote a script which queried each of those state groups on our restored backup, noting down the targets of any bogus data: this was the list of potential victims of incorrect cleanup. We then cross-referenced that list of potential victims against the production database, checking for state_groups_state</code> entries which had been removed but where the state group was still in use: this gave us the actual victim list. Each of those victims had to be re-inserted into the production database. We started those scripts running on 5th July, but due to the amount of data involved, it took nearly a week before we were able to announce on 11th July that the majority of rooms were repaired. 🔗</a>Assessing the root cause</h2> So, what went wrong to cause those index pages to get corrupted? The short answer is, we don't know. First, some timeframes. We know for certain that corruption happened after January 2021 (or at least, that corruption was still ongoing at that point), since it affected state groups created at that time. And we know that it happened before July 2025, since corruption was present in the backup from the end of June. It's hard to be any more certain than that. The one thing we can be sure it's not is a bug in Synapse or PgCat: there is no way that an application should be able to cause internal corruption within a Postgres database. One possibility is a Postgres bug, but Postgres is an extremely robust piece of software, and the Postgres team treats corruption bugs extremely seriously. We were using Postgres 10.12 in January 2021, and we've looked through the Postgres release notes for every version since then, and not found any bug fixes that would fit this pattern. It's worth noting that Postgres relies heavily on its underlying filesystem, as well as the device drivers and hardware, to behave correctly: in particular, if the filesystem claims that data has been persisted, it really has been persisted. Problems in this area are far from unknown — back in 2018, the Postgres team discovered that their 20-year-old assumptions about how fsync</code> worked were incorrect (wiki page</a>, FOSDEM presentation</a>). But the fixes to that were backported to Postgres 10.7 so that problem can't explain this corruption. So that really leaves kernel or disk firmware bugs, and hardware failures. Our filesystem is nothing fancy, just ext4</code>, and we're using stock Debian kernels. Some sort of hardware problem seems like the most plausible cause. We're somewhat surprised that hardware failure would cause extensive damage to a single index, whilst apparently leaving all other data intact, but it's at least possible. For the curious: our current generation of database servers run Linux kernel 6.1, and each server uses eight 15TB Intel NVME SSDs in a RAID10 configuration to give us 64TB of storage. The previous generation (retired in November 2023) used 8TB SSDs with LVM and no RAID, on Linux 4.19. Of course, we have checked fsck</code>, smartctl</code> and mdadm</code> for any errors on the current disks: none have shown up. There was a disk failure on the primary database server in October 2021, which caused us to fail over to the secondary, so it's conceivable that the dying disk lost some writes, though it would have to have been doing so for a while for the corruption to have made it onto the secondary. We're not entirely satisfied with this explanation. If you've got any ideas, let us know</a>! 🔗</a>Conclusions</h2> Incidents like this happen from time to time when running software services, particularly relatively large scale ones like the matrix.org</code> homeserver. They are impossible to plan for and often, as in this case, take significant time and effort from people who would otherwise be developing features or fixing bugs. We know that there are plenty of users out there who will have been affected by the problem, and found themselves unable to communicate as a result. We very much share your frustration, and we'd like to apologise for the disruption to service. With that said, we're glad that we were able to get to the bottom of most of the problem, and get the lost data restored within a relatively short time. If nothing else, hopefully this blog post will be of use to future generations faced with Postgres index corruption!
Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations 2025-07-16T00:00:00+00:00 Hi all, Over the last 6 months a major project has been underway by the Element server team and the Matrix.org Foundation security team to investigate “state resets”: scenarios where Matrix’s state resolution algorithm can give unexpected results. As part of this work we’ve identified two high severity protocol vulnerabilities (CVE-2025-49090; the other not yet allocated a CVE). Given the security implications of a federation protocol vulnerability, we’ve shared details under embargo over the last 4 weeks with all known active server implementations, and are now aiming for a coordinated security release across all Matrix server implementations on Tuesday Jul 22nd</del> Monday Aug 11th 2025 at 17:00 UTC. If you run a Matrix server in an untrusted federation (e.g. the public federation), please be prepared to upgrade as soon as the patched versions are available. These vulnerabilities have been addressed via MSCs which have been shared, reviewed and are in the final comment period (disposition merge) with the Spec Core Team and server implementor community, under embargo. This will result in an off-cycle Matrix spec release (1.16) introducing a new room version (12) to address the vulnerabilities in question, requiring a room upgrade of existing rooms. Having given server and room admins time to upgrade, we are then planning to un-embargo the MSCs and complement tests on Friday Jul 25th</del> Thursday Aug 14th 2025 at 17:00 UTC. UPDATE: Jul 18th 16:45 UTC: We've heard a lot of feedback that 6 days isn't enough for clients/bots/bridge/tooling developers to test the changes introduced by room v12, and that it also doesn't give enough time for community admins to prepare for the necessary room upgrades. Underestimating the time needed here for client/community testing is entirely our fault, due to being overfocused on coordinating the significant serverside work needed. As a result, we've pushed back the coordinated server release date to Aug 11th, to give everyone more time to test and prepare. We've also opened up registration on the beta.matrix.org</code> homeserver, which is already running v12 rooms by default, to make it easier for client developers to test their clients. We've also made one clarification below for client developers, explaining the new permissions needed to send m.room.tombstone</code> events. CLARIFICATION: Jul 16 17:30 UTC: Room admins should plan to upgrade rooms at their convenience, similar to previous security-related room version upgrades (e.g. v1 to v2). Much like installing an operating system patch, sooner is better, but as these are not Critical Severity vulnerabilities, there is no requirement for room admins to upgrade rooms immediately on Jul 22nd. For instance, the Matrix.org Foundation will likely upgrade its public rooms at some point after Jul 25th (having given server admins a chance to upgrade, and having given any server implementations running late a chance to release). N.B. Only rooms which include users on potentially malicious servers (e.g. publicly joinable rooms on untrusted federations) are vulnerable. Important information for client developers: Client developers should review MSC4291: “Room IDs as hashes of the create event”</a> to ensure their clients can accept the new proposed format of room IDs, and no longer expects content.predecessor.event_id</code> in m.room.create</code> events. </li> One of the other changes coming in v12 is that room creators will be privileged over other users in the room. Therefore clients which restrict user behaviour based on power level will need to be updated to be aware that room creators effectively have infinite power level. Creators are not listed in the users block of the m.room.power_levels</code> event, and are instead defined as the sender</code> field of the m.room.create</code> event, or entries in a new optional additional_creators</code> array field in the content</code> of the create event. Full details will be released in the MSCs when embargo lifts. </li> Finally, clients which use power_level_content_override</code> when creating rooms MUST NOT assign a power level to the room creator, otherwise the /createRoom</code> request will fail. </li> UPDATE: Jul 18th: We should have mentioned that the default power level in room v12 for sending m.room.tombstone</code> events to upgrade rooms is 150. This stops normal admins from upgrading the room (and so assuming creator privileges) - instead, a creator has to explicitly boost an admin's power level to 150 in order to let them upgrade the room and effectively assume creator rights going forwards. </li> </ul> This has been an exceptionally complicated project to coordinate and its security implications required us to deviate from our usual MSC process and develop the changes under embargo. This and the expedited release of a new stable room version are exceptional choices that are far from ideal, which we’re having to take to keep the ecosystem secure. To be clear, normal MSC development and process will continue in the open, just as it always has. We’d like to sincerely thank the Matrix server implementor community for their impressive support in preparing the coordinated security releases - both in terms of vital MSC review, and then working together to implement the necessary changes. Matrix’s server heterogeneity has never looked healthier. We’d also like to thank Timo Kösters for helping precipitate the project in the first place. We’ll follow up with more details on Aug 11th (assuming the disclosure timeline doesn’t slip further). Thanks all for your time, patience and understanding while we ship this protocol upgrade (the first coordinated upgrade since Matrix 1.0</a> back in 2019!) Matthew Demystifying SBGs 2025-06-26T00:00:00+00:00 We’ve noticed a fair bit of confusion (aka misinformation) around Secure Border Gateways (SBGs) recently, which this blog post aims to clarify. First off, Secure Border Gateways are not defined in the Matrix specification. The term is actually a product name from Element, rather than anything intrinsic to Matrix. However the concept of a border gateway is well established. In a Matrix world, it means any kind of application-layer firewall</a> which intercepts APIs between Matrix components in order to provide defence-in-depth or apply additional policy rules, to bring an extra - but optional - layer of control within a federation. It is, in short, an optional way to provide more control over federated traffic. So conceptually it’s the Matrix equivalent to application layer gateways for email. Without them, email works absolutely fine, and always has. However, it’s still a desirable optional extra for some enterprise deployments. For instance, it can help protect both server misconfigurations or buggy servers: literally providing defence-in-depth in traditional ‘castle and keep’ style. That there is an ecosystem of 3rd party software vendors building additional components such as Secure Border Gateways reflects the strength and maturity of Matrix as an open standard. It’s clear evidence that a genuine open source initiative, based on an open standard, not only ensures digital sovereignty but also drives competitive innovation. Meanwhile it’s excellent to see other chat vendors like Mattermost</a> working on first-party Matrix support again (and so in turn will benefit from capabilities like Secure Border Gateways or Cross Domain Gateways). 🔗</a>Examples of Border Gateways</h2> Let’s take a look at ‘SBGs’ in the wild. Probably the most widespread example right now is in TI-Messenger</a>, Germany’s healthcare messaging system based on Matrix (targeting 150,000 organisations and almost all German citizens, due to go live in mid-July). Here, gematik chose to require SBGs (called “TI-Messenger Proxies” in its parlance) for each deployment in order to integrate Matrix with TI-Messenger’s FHIR-standard and address book system. As a result, a whole ecosystem of SBG implementations has emerged: starting with the entirely open source TI-Messenger Proxy reference implementation</a> from gematik - but also additional implementations from certified TI-Messenger vendors including Akquinet, Awesome Technologies, CompuGroup Medical, Element, Famedly, Gedisa, samedi and Xtension. As an example, Element’s TI-Messenger Proxy implementation is built on Element’s generic SBG</a> implementation, which provides a configurable pipeline for functionality like: Proxying (terminating and re-originating) Matrix traffic</li> Apply rules based on HTTP headers</li> Apply rules based on room membership</li> Enforcing classification labels</li> Enforce closed federation based on a domain allow list.</li> Enforce usage of specific clients.</li> Enforce certain parameters when creating a room.</li> </ul> 🔗</a>TL;DR</h2> Whether you call them Secure Border Gateways, TI-Messenger Proxies or something else: it is possible to add an application layer firewall that brings an additional layer of control to a Matrix federation. But let’s not forget: Matrix servers already let you lock down your federation - e.g. all of Synapse’s federation configuration</a>.</li> SBGs are not part of the Matrix specification, because Matrix works perfectly well without them</li> SBGs are an optional extra for organisations and federations that might require them, based on their use-case, external integration points (e.g. FHIR) and overall security posture</li> SBGs are not required for a private federation</li> SBGs are not required for public federation either</li> SBGs do not make Matrix closed</li> It’s a hugely positive sign of Matrix’s maturity that there’s an ecosystem of 3rd party software vendors building additional optional components like SBGs</li> </ul> Dispelling myths and misinformation 2025-06-20T00:00:00+00:00 We’ve seen several articles published in the last week that are, at best, misinformed, and at worst, attempts to protect a single communication company’s bottom line by attacking Matrix. We thought we should take the time to set the record straight, lest anyone be taken by this naked attempt to sow fear, uncertainty, and doubt (FUD). But before we do, let’s be clear: this is not the first time a single vendor open source project – which may be under an open source license but is unilaterally controlled by a single for-profit company – has resorted to desperate measures to attack their community-driven competitors, and it won’t be the last time. Matrix is not just an open standard for secure communication, it’s an openly governed and collaboratively developed ecosystem of projects powered by a growing community of volunteers and vendors. In this way, Matrix exemplifies the open source ethos, encourages greater innovation, and defies those who would try to build businesses based on extractive behavior and vendor lock-in. 🔗</a>Governance & legal allegations</h2> 🔗</a>Neutral and independent stewardship</h3> The claim has been made that Matrix is effectively controlled by one company. It’s a bold claim, especially when it comes from a for-profit that exerts unilateral control over their eponymous open source project – and it’s patently false. Open source is one of those terms that has become overloaded with meaning. Something can be accurately described as “open source” when it’s placed under a license that’s been approved by the Open Source Initiative. However, colloquial use of “open source” tends to imply that something is open source licensed, has an open collaboration model, is guided through open governance, and housed within a neutral nonprofit entity. Matrix is open source in the fullest sense of the word. The Matrix protocol is open source, and it evolves through the Matrix Spec Change process</a>. Anyone can submit a proposal, and anyone can help vet those proposals. The Spec Core Team</a>, a volunteer body made up of people with a range of expertise and several different employers, facilitates this process, merges in successful proposals, and manages new releases of the specification. And the Spec Core Team is just one of the multi-member volunteer bodies that govern Matrix under the auspices of an explicitly not-for-profit legal entity. The other body is the Governing Board</a>, the most recent evolution in our open governance. The Governing Board is an elected body of representatives from multiple constituencies: those who build projects with Matrix, those who use Matrix, and those who fund Matrix. The Governing Board provides input to the Spec Core Team, has a role in approving budgets, major expenses, and any new revenue sources the Matrix.org Foundation may seek to pursue. It also has leeway to venture into all manner of subject matter, and it does so through its committees and working groups, which span Trust & Safety, Governance, Events, Finance, and more. Speaking of the Matrix.org Foundation, it’s a not-for-profit corporate entity that is legally bound to the community benefit described in its mission statement. It holds community assets, such as software projects that are foundational to the ecosystem and the Matrix trademark, so that participants and downstream users can be confident those will not be withdrawn or leveraged against them for the benefit of a single company. It is also required to submit annual reports</a> with an overview of its financial accounts and activities. Further, the Foundation has a dedicated staff that I, Robin Riley, currently lead as an independent Managing Director</a>, and I have a track record of fighting moneyed interests to protect the open source commons – and, critically, I have no financial stake in any Matrix vendor. I have not only done the work of operationalizing open governance, I have also been hard at work behind the scenes separating out the Foundation’s infrastructure – which was previously completely subsidized by Element – and fundraising so that it is increasingly independent and self-sustaining. Some may point to Element’s relicensing of Synapse as proof positive that the Foundation is not independent, but there’s nothing stopping anyone from doing the same with permissively licensed software from other open source foundations – something that happens frequently – and no one is claiming those foundations are not independent. Some may point to the Foundation’s move to monetize the matrix.org homeserver, which is indeed operated under contract by Element, as evidence that the Foundation is in trouble. But seen in the cool light of the day and in context of the facts, this is simply a move to help close a budget gap that has been openly discussed for several years. It may also contribute to de-centering the homeserver and give rise to more community operated alternatives. We’d rather try to defray the cost of operating the homeserver than let it impact our ability to continue facilitating ever more open governance and collaboration. It is true to say that Matrix has further to go in its open governance journey and on the path to full independence and sustainability. However, if one surveys the landscape of open source foundations, it becomes clear that these are journeys that are measured not just in years, but in decades. And whereas some projects get further enclosed and less democratic over time, there’s a fact pattern here that shows Matrix is getting ever more open, independent, and collaborative. 🔗</a>Legal allegations</h3> It has been suggested that because the Matrix.org Foundation is incorporated in the UK, Matrix is incompatible with EU Data Protection laws, like the GDPR, and subject to the Investigatory Powers Act (IPA) in the UK. Well, the GDPR is a regulation governing the use of personal data which predates Brexit and is fully incorpoorated and implemented in UK law as part of the Data Protection Act 2018. Whilst it recommends things like Privacy by Design and other requirements which influence software development, it does not directly govern it. Any code written in the UK and hosted (or used by people) in the EU will have to be compliant with EU legislation – this is the beauty of an open standard which supports digital sovereignty. Second, jurisdictional exposure related to cases like Schrems II is associated with data transfers to third-countries. The UK is not a third-country, it currently has an adequacy decision which has just been extended. Yes, there is a risk that this adequacy decision might be revoked and we even agree with some of the concerns raised in the linked article about some of the recent decisions in the UK – again, we have been incredibly vocal about most of the concerns raised and continue to work on these topics, including the risk of TCNs. And finally, the Investigatory Powers Act (IPA) is a piece of legislation in the UK focused on governing investigatory powers and law enforcement which has been in place since 1998. The UK government can apply IPA globally to individuals based in the UK, as per the Technical Capability Notice (TCN) it has served Apple</a>, so whether you are using Matrix (governed by a UK-based Foundation) or not is irrelevant. In the end, of all the technologies, Matrix is one of those that are the best positioned to give the users their digital sovereignty and data protection, thanks to its open source and decentralised nature. 🔗</a>Technical allegations</h2> 🔗</a>On the relevance of Matrix’s open federation for private deployments</h3> With the open Matrix network including 180 million addressable users and hosting a wide variety of players, not all with good intentions, we are facing a clear challenge of ensuring this open network is kept safe for our users</a>, and it is a primary focus for the Foundation. On the other hand, Matrix is also widely used by governments and public sector organisations, which have all deployed their own private federations, potentially connecting them to one another via appropriate Secure Border Gateways (SBG) and enforcing strict access control, in order to maintain the security of their deployments and to prevent access from unauthorised users. Several organisations develop SBGs, some being commercial and proprietary (like Element’s) and other freely available open-source (like DINUM’s). Gematik also specifies a TI-proxy (SBG) for TI-Messenger, although it doesn't develop an implementation. SBGs are policy controllers rather than privacy enforcers. All these deployments are integrated to appropriate single-sign one setups and the public Matrix.org homeserver also mandates either email or a social log-in to validate the account. It is also worth noting that the fact the federation is open or closed is orthogonal to whether the deployment is scalable or not. The scalability is determined by the server implementation which is used, and there is no limit to how many servers can federate with one another. Meanwhile the French government’s Tchap Matrix installation is a private federation of around 350K active users. Bundeswehr’s Matrix-based BwMessenger private federation supports 100K+ users. Gematik’s (Matrix-based) TI-Messenger private federation will support literally millions of German citizens. Being a decentralised network, Matrix was designed to be Byzantine Fault Tolerant, resilient to malicious instances by design. In an open federation, malicious actors can spin up rogue homeservers and interact with legitimate ones but they can’t harm the legitimate ones, beyond spam attacks, which (again) is a failure mode with a lot of focus</a> from the Foundation’s Trust and Safety team today. Meanwhile there are also plenty of options around content scanning and anti-virus to protect private federations, whether that’s from various Matrix vendors, FOSS or in-house development. 🔗</a>On end-to-end encryption</h3> Matrix is encryption agnostic and today uses Olm, its own implementation of the Signal protocol, with Megolm for group scalability. Whilst Olm is now mature and well-understood end-to-end encryption (developed and used by Signal, and used by WhatsApp, Facebook Messenger and others) it does have some scalability limitations for very big group chats (tens of thousands of users). Meanwhile, IETF’s MLS standard (RFC9420</a>) provides better scalability in exchange for some tradeoffs around centralisation - work continues apace on how to best integrate MLS with Matrix (e.g. MSC4256</a> and MSC4244</a>, and all our existing work at https://arewemlsyet.com</a>). We’ve seen claims that Matrix lacks forward secrecy today, which is plain false: Olm provides perfect forward secrecy by nature of being an implementation of the Signal Protocol - if an attacker captures the current keys they can’t decrypt previous messages. Similarly, if an attacker captures the current keys they also can’t decrypt future messages - this provides post-compromise security. Olm is used to share the “Megolm” keys used to encrypt messages, and similarly, if you capture a Megolm key you cannot decrypt any previous messages. By default a given Megolm key is used to generate keys for up to 100 consecutive messages, but this is configurable, and is reset whenever the group membership changes or after a week. Nothing stops an admin from rotating on every message if they like: https://spec.matrix.org/v1.14/client-server-api/#mroomencryption</a> Practically speaking almost all Matrix clients keep all the Megolm keys (to read back history), because users of a chat application (especially in a collaboration context) expect history to be accessible. Though there is nothing inherent in Matrix that would prevent throwing the keys away on ratchet. 🔗</a>On metadata availability</h3> Matrix currently exposes the metadata of who’s talking in which rooms to the admins of the servers whose users are in a given conversation. It is transport encrypted and random (non-participating) network observers most certainly cannot access it nor “easily” track users across conversations. We are in the process of minimising metadata by default (e.g. MSC4014</a> exists and was implemented in Dendrite) but it’s worth noting that sometimes metadata is a requirement: in practice a lot of professional Matrix users (i.e. large government installations) often actually want to know who’s talking to who on their servers for compliance and access control reasons. Meanwhile other approaches are in flight right now, e.g. BWI’s MSC4256</a>. It is worth noting that other collaboration apps who claim to be more secure than Matrix are hitting the same problem of having to be compliant when selling to the public sector. For example, Wire's privacy whitepaper</a> directly states their servers have access to the group participant lists and leaks the conversation’s name to the server. Besides the MLS RFC</a> (RFC9420, section 16.4, used by Wire) clearly states MLS itself does not intrinsically provide confidentiality to a large subset of messages and that a party observing these (i.e. the delivery service = Wire's backend servers) can infer group membership. 🔗</a>Why?</h2> All in all, it sounds like the German public sector appearing to be converging on Matrix</a> as an open standard for secure communications has triggered some defensive reaction with other European players in the market. It is a shame that small European players feel the need to fight one another rather than collaborate via open source software against the bigger non-European and proprietary players. Introducing premium accounts to fund the matrix.org homeserver 2025-06-13T14:00:00+00:00 🔗</a>TL;DR</h2> As we need to take more concrete steps to improve the financial situation of the Foundation, we will be rolling out a freemium offer for the matrix.org homeserver users. The alternative is to turn off the server, which we want to avoid doing. The goal is for the most active users to support the cost of the service. Free users will have limits on how they can use the service (mostly around media). The change can be supported by any client with limited to no development. Premium plans will be rolled out over the summer, and we will be iterating on the exact scope in the first few weeks. The Homeserver Terms and Privacy Policy will be updated accordingly and deployed in the coming weeks. 🔗</a>The full story</h2> We have been communicating on the lack of funds in the Foundation for a while now, the latest being here</a>. And whilst we’ve been working hard to gather new members and are happy to see the number of logos increasing</a> (thank you all for seeing the need for Matrix to stay independent and safe, and the value in supporting it!), none of the big players in the ecosystem have actually committed to one of the higher membership tiers, so we need to find other ways towards sustainability. The Foundation’s mission</a> can basically be summarised by 4 main goals: Ensure the specification of the protocol stays canonical and unencumbered, to avoid fragmentation and being overridden by a single player.</li> Ensure that all players in the ecosystem are at a level playing field, helping them succeed by giving them visibility and listening to their needs.</li> Promote the Matrix standard, as the value of Matrix is directly proportional to the size of the public network and how much it is used and commercialised.</li> Ensure the public network is safe by building moderation tools that can be used by the server admins, for the sake of our users and making sure the network is attractive.</li> </ol> In practice, it means that we are currently spending money on: A small team of developers and moderators, to develop Trust & Safety tooling, moderate the matrix.org server, and redirect people who do not understand the decentralised nature of Matrix reporting abuse to us towards the appropriate server admins.</li> The infrastructure of the matrix.org homeserver, including the SRE team, who are on call to keep it running, and the support team.</li> Organise and sponsor events to promote and evangelise the protocol.</li> A tiny team to run the Foundation itself, including the support of external contractors for the administrative side (finance, legal, tax). The staff works on governance (organising the governing board elections, running the meetings, liaising between the different teams), raises money and brings members in, manages social media and liaises with the community, keeps the website up and up to date, publishes TWIMs and blogs, organises the events, etc. This team whose day job is to keep the Foundation running is also supported by a lot of volunteer (and sometimes sponsored by employer) time from the Governing Board and its Working Groups, the Spec Core team, the Guardians, and other external staff.</li> </ul> We haven’t gotten to the point of publishing the public financial report (although it should be almost finalised now), because we are frantically trying to focus on closing the financial gap, but here is an overview of the split of expenditures in the last year: As you can see, 20% of the Foundation’s expenditure goes towards hosting the matrix.org free and public homeserver. If we add in the cost of the moderation work done by the Trust and Safety team, the total share of the costs attributable to the matrix.org homeserver account for almost 50% of all expenditure. Meanwhile, today, only 50% of the spending of the Foundation is covered by its revenues (donations and memberships), and we are working hard towards reducing this gap. We’ve kept the matrix.org homeserver around so far, despite its costs, as we consider it essential to seed the network in support of the nurturing part of the Foundation’s mission: despite Matrix being decentralised by design, users need a trusted place to create a free Matrix account to try it out in the first place. However, we can’t continue to bear the cost of the server as is, and before we get to the extreme position of being forced to turn it off leaving its 370k monthly active users in the awkward position of finding a new home for their account, we’ve decided to try to alleviate some of these costs by setting-up a freemium offering and proposing premium plans in addition to the free ones. The goal is to get the server to an at least financially break-even position. If, by any chance, it was ending up profitable, the profit would directly be invested in Trust and Safety</a>, or other new programmes which can support the ecosystem. As a reminder, the Foundation is a Community Interest Company, i.e. a limited company which operates to provide a benefit to the community it serves rather than private profit. 🔗</a>What will the freemium offer look like?</h3> The idea is to set some limits for users on the free plans, which would be lifted for users on the premium plans in exchange for an affordable membership. We are still iterating (and will do for a while) on how it looks, but users can expect limits around media sizes and/or volumes. The goal is to ensure that the most active users participate in covering the costs of the service, in return for the access to a fully encrypted and decentralised open network. We are limited in scope and design by the fact we need to ship a minimum viable product as soon as possible (we need to reduce costs now) and by not wanting to impose too much development (if any) to Matrix client developers. Obviously we would have preferred to keep everything free of charge. We will never sell our users’ data or cripple our services with ads, so we need to find ethical sources of revenue. 🔗</a>When will the new plans take effect?</h3> The roll-out will happen progressively, starting in the coming weeks and hopefully completing in the summer of 2025. We will start by opening up premium plans to new users only, before progressively migrating all existing accounts to a free plan which will give them the option to upgrade to a premium plan. Users will of course be notified ahead of their account being migrated. 🔗</a>Will this work with whatever Matrix client I use?</h3> Yes. The plan management will be handled via the My Account</a> screens provided by the Matrix Authentication Service (MAS), and notifications to users will be sent in a dedicated room using the Server Notices</a> feature built into the Matrix protocol – already used by the homeserver to send automatic messages to the user – so should be seamless for every client. 🔗</a>I am a Matrix client developer, do I need to do anything?</h3> There are two considerations from a Matrix client point of view: support for the Server Notices</a> feature</li> if the client is distributed via the Apple App Store, then support for MSC4286</a></li> </ul> If the client doesn't show server notices at all then, whilst the client will remain usable with the matrix.org homeserver, your users will have a degraded UX as they won't receive notifications when encountering usage limits. Apple places restrictions</a> on how payments are implemented by iOS (et al) apps that are distributed via the App Store. We expect that most, if not all, apps that fall within scope would be classified as what Apple calls “Free Stand-alone Apps</a>”. Such apps do not need to use in-app purchases so long as “there is no purchasing inside the app, or calls to action for purchase outside of the app”. In order to meet these requirements we have proposed MSC4286</a> which provides a way for a homeserver (such as the matrix.org homeserver) to flag parts of messages as containing a call to action and for affected clients to be able to hide that content. Example implementations are linked in the MSC. 🔗</a>I am already supporting the Foundation by paying an individual membership, will I have to pay for a premium plan too?</h3> No, individual members</a> of the Foundation will get access to the premium features at no extra cost. This benefit will be implemented as part of the process of migrating existing accounts to the free plan. 🔗</a>What else will be changing?</h3> In order to support these changes we will be releasing updates to the Homeserver Terms and the Privacy Policy in the coming weeks. Users of the matrix.org homeserver will be notified and will need to accept the new terms. The scope of change will be clearly highlighted in the release note, but essentially you can expect new terms around payment and additional information on the types of information we will collect about your account, as well as the processors we will use to enable payments. We realise this is quite a big change, but our position is that a slightly limited service is better than no service at all, so we chose to ask for financial contribution rather than turn off the server. Paying a subscription for the matrix.org homeserver is basically a way to support Matrix, ensuring the Foundation can continue to play its role of neutral custodian, enabler and safeguardian of the protocol and the network. We will be publishing more details and a proper FAQ as the roll-out happens, so watch this space for more details. Introducing Policy Servers 2025-04-17T17:00:00+00:00 Last week, we shared details about ongoing attacks on Matrix</a>. Over the past week or so, we’ve tested some new tooling to help combat abuse on matrix.org. If you run your own Synapse server and your users are present in the Foundation’s community rooms, you can benefit from this tooling by installing an experimental Synapse module. You can find the code and installation instructions here</a>. We’re deliberately taking the bold step of announcing a tool and also announcing its deprecation in the same post. This is experimental work, and we are iterating quickly. We expect to have an implementation in Synapse shortly, so the module will be discontinued around May 21. 🔗</a>What are policy servers?</h2> Policy servers are an overlapping layer of protection with existing community moderation tools such as Draupnir</a>, Mjolnir</a> and Meowlnir</a>. Rooms can opt-in to this new layer of protection, recommending that servers participating in the room check events with a given policy server before they are sent to their clients. The policy server will pass an opinion on each event, recommending servers in the room to accept the event, or to reject it. For people in the room, this should be effectively invisible. Events which pass the check will be shown as normal, while ones which don’t will never make it through to their clients. The Foundation intends to offer a policy server to room admins, but we hope that in time other providers will offer alternative policy servers. The Foundation is already running an experimental implementation for some of its public rooms, which we will release once we have confidence in the approach. We also expect that for many rooms, a policy server isn’t necessary, or spends most of the time in a low-power or disabled state. Element and the Foundation are exploring these ideas over the coming weeks. 🔗</a>Get involved</h2> MSC4284</a> is now open to support this work. Please get involved in the MSC, and help us to improve this addition to safety tooling for the network. We’d especially like to see implementations for non-Synapse servers. Folks who run communities on Matrix who would like to test our policy server, reach out to us at abuse@matrix.org</a>, using the subject policy-server-alpha</code>. We're at a crossroads 2025-02-20T14:30:00+00:00 After a successful 2024 with a lot to be proud of</a>, and a Matrix Conference that brought our community together to celebrate 10 years of Matrix, we step into 2025 with a light budget and a mighty team poised to make the most of it! Our priorities remain to make Matrix a safer network, keep growing the ecosystem, make the most of our Governing Board, and drive a fruitful and friendly collaboration across all actors. However, whether we will manage to get there is not fully a given. 🔗</a>The Foundation is key to the success of Matrix</h2> The Matrix.org Foundation has gone from depending entirely on Element, the company set up by the creators of Matrix, to having half of its budget covered by its 11 funding members</a>, which is a great success on the road to financial independence! However half of the budget being covered means half of it isn’t. Or in other words: the Foundation is not yet sustainable, despite running on the strictest possible budget, and is burning through its (relatively small) reserves. And we are at the point where the end of the road is in sight. Why does it matter? The Foundation has a clear mission</a>: The Matrix.org Foundation exists to act as a neutral custodian for Matrix and to nurture it as efficiently as possible as a single unfragmented standard, for the greater benefit of the whole ecosystem, not benefiting or privileging any single player or subset of players. </blockquote> Without the Foundation and its programs, the Matrix protocol itself faces existential threats: Without Trust & Safety efforts, bad actors and communities would proliferate on the network and make it unlivable for the rest.</li> Without a canonical specification, the shared infrastructure and a Spec Core Team to maintain it, the protocol would become fragmented, losing its effective interoperability – increasing the costs on all downstream users.</li> Without a neutral entity as the custodian of the specification, the ecosystem would first shatter and then consolidate around the biggest (likely for-profit) actor.</li> Without advocacy, conferences, documentation and tutorials, Matrix would become a niche protocol used by a few enthusiasts for side projects, whilst big proprietary and siloed networks continue to hold the world’s communications.</li> </ul> 🔗</a>Implementing the vision</h2> But there is light at the end of the tunnel! Concretely, the Foundation delivers most of its value by fostering a healthy, fair and fertile ecosystem around Matrix. It needs to strike the right balance between: Making Matrix accessible & visible. For the general public it means maintaining an easy default onboarding server (Matrix.org).</li> For server administrators it means providing the right tooling to keep their users (and themselves!) safe.</li> For developers it means making it easy to develop products using Matrix, via documentation, tutorials, and in-person events.</li> </ul> </li> Making Matrix compelling to build on. This means maintaining the Matrix Specification as a canonical, unencumbered, patent free and royalty free specification.</li> Being responsive and vendor-neutral when an organisation or individual contributes.</li> Promoting the good players within the ecosystem.</li> Ensuring the network grows and attracts more users.</li> </ul> </li> Making Matrix a product that benefits the greater good. This means ensuring that the general public can easily build safe & easy to use communities on Matrix.</li> Ensuring that bad actors are proactively chased and discouraged to use Matrix.</li> </ul> </li> </ul> 🔗</a>Doing less to do better</h3> Matrix has been here for 10 years, and will hopefully be here for many more! But to continue to grow and thrive, it needs the Foundation to be around and healthy, which means carefully allocating its budget in order to continue to exist and fulfill its mission. This is why it needs to focus on critical programs and shut down some of its activities. We view the following programs as critical to the Foundation’s mission: Maintaining the canonical, backwards compatible, stable Matrix Spec</a></li> Developing protocol enhancements and Trust and Safety tooling, making the tools available to the ecosystem and moderating the servers under its control (typically Matrix.org) - see our recent blog post</a></li> Running the Matrix.org homeserver as an initial home for newcomers</li> Promoting the Matrix protocol via online content, conferences and meet-ups and other marketing strategies</li> </ul> We might fine tune our approach, but we can't cease any of those programs without severe consequences for the ecosystem. Meanwhile, bridges have been at the heart of Matrix for a long time. Public bridges hosted by the Matrix.org Foundation have been a very good resource to show the power of interoperability, connect communities together, and onboard many people into their Matrix journey. However, these bridges require regular maintenance as the bridged platforms evolve their APIs, and significant engineering and moderation support to run. Luckily, the Matrix ecosystem is now more mature than it was at the time we spun up those public Slack, XMPP and IRC bridge instances. There are now commercial players like Beeper</a> providing a user-friendly offering for people who want to get all their conversations in a single app, or IndieHosters</a> and Fairkom</a> offering hosting for Matrix server and bridge instances (and much more). So unless the Foundation manages to raise $100,000 of funding by the end of March 2025, we will have to focus our resources on the critical lines of work, and consequently we will have to shut down all the remaining bridges hosted by the Matrix.org Foundation. This includes bridges to Slack, XMPP, OFTC (IRC), and Snoonet (IRC). We will also mark the software behind those bridges as archived, as we don't have the resources to accept new contributions. In practice, the Foundation needs an additional $610K in revenue to break-even, but this $100K would extend our runway 1 month while we work on landing grants and new members. To put this in context, we nearly doubled our revenue in 2024, reaching $561K, but it was also the first year in which we carried the full cost of our operations: $1.2M. To make ends meet, we liquidated $283K worth of cryptocurrency donations and ended the year with a $356K deficit. We are currently on target for $587K revenue in 2025, with a modest increase in expenses. 🔗</a>Growing the ecosystem and the network</h2> Choosing to shut the bridges down is a difficult decision to make, but will allow us to focus on the critical projects which will keep the ecosystem growing. The success of Matrix depends on how widely it is used by the general public and by organisations – preferably natively rather than via bridges. The more people and organisations rely on Matrix, the more attractive it becomes for organisations to build products and services on top of it, the more funding the Foundation gets, and the more the Foundation can in turn reinvest into the ecosystem and run initiatives that benefit all stakeholders for the growth of the network. Once the Foundation is cashflow positive, it will be able to accelerate and eventually get on with the multiple projects the team and Governing Board have in mind to make Matrix fun, exciting, reliable, safe, easy to use, and above all useful. And we hope to get there by the end of the year. Most importantly, despite the Trust and Safety team being the Foundation’s biggest expense, as explained in our blog post</a>, the team is still underresourced: they are understaffed and under a lot of pressure to deliver protocol improvements, better tooling for server admins, and ensure Matrix.org is a good citizen of the open federation. T&S will be the first area to see increased funding. Separately, the Foundation wants to continue executing on its mission! Among others, better connect the doers in the ecosystem with the people and organisations who need their energy, share the successes and learnings from the community: the Matrix Conference was an incredible success and we want to see more of that. We’ve also seen a clear change in how many users and organisations were adopting Matrix in the last few months: the world needs a decentralised end-to-end encrypted network to communicate more than ever, and it shows! We want to uplift the good players which are driving this growth. The Foundation would also love to support more public policy efforts, which give an opportunity to shape the world by educating regulators, like for the Digital Markets Act</a>; or stronger involvement in standardisation: we had no choice but reduce the effort spent on participating in MIMI, the IETF working group for instant messaging interoperability</a> due to lack of resources. There is so much more that we could do to make Matrix better and realise its full potential. 🔗</a>So what now?</h2> Right now, the Foundation urgently needs your financial help</a>. For the sake of a safe network, our primary focus today, but also to be able to deliver on the reason we all want Matrix to succeed. Because we believe that: People should have full control over their own communication.</li> People should not be locked into centralised communication silos, but instead be free to pick who hosts their communication without limiting who they can reach.</li> The ability to converse securely and privately is a basic human right.</li> Communication should be available to everyone as a free and open, unencumbered, standard and global network.</li> </ul> In short: If you are an organisation building on top of Matrix, you can help by becoming a member</a>, which also gives you the opportunity to be eligible to participate in the Governing Board, and other perks. If you are an organisation buying Matrix services or products, you can help by ensuring that your vendor is financially contributing back to the project or becoming a member yourself. If you are an individual using Matrix, you can help by making a donation</a> or becoming a member</a>. If you are a philanthropist or other funder, you can help by getting in touch with us at funding@matrix.org</a> to discuss funding options. It isn’t the first</a> time</a> we’ve rung the alarm bell, and it is no fun to beg for help. We are at a crossroads, where the vibrancy of the ecosystem and enthusiasm around Matrix is not reflected in the support the Foundation gets, and we are at risk of losing this common resource and all it offers. But all in all, we are optimists – we wouldn’t have begun this journey if we weren’t – and we believe that there are people out there who realise that sovereign and secure communication is as high on the list of today’s essential technology – if not higher – as ensuring AI is safe, so let’s spread the word and let’s continue working on a safer and more sovereign world! Switching to Curated Room Directories 2025-02-20T09:30:00+00:00 As of yesterday, Matrix.org is using a curated room directory. We’re paring down the rooms that are visible to a collection of moderated spaces and rooms. This is an intervention against abuse on the network, and a continuation of work that we started in May 2024. In early 2024 we noticed an uptick in users creating rooms to share harmful content. After a few iterations to identify these rooms and shut them down, we realised we needed to change tack. We landed on first reducing the discoverability and reach of these rooms - after all, no other encrypted messaging platform provides a room directory service, and unfortunately it can clearly serve as a mechanism to amplify abuse. So, in May 2024 we froze the room directory. Matrix.org users were no longer permitted to publish their rooms to the room directory. We also did some manual intervention to reduce the size of the directory as a whole, and remove harmful rooms ahead of blocking them. This intervention aimed at three targets: Lowering the risk of users discovering harmful rooms</li> Stopping the amplification of abuse via an under-moderated room directory</li> Reducing the risk for Matrix client developers for app store reviews</li> </ul> In truth, the way room discovery works needs some care and attention. Room directories pre-date Spaces, and some of the assumptions don't hold up to real world use. From the freeze, and the months since, we've learned a few things. First, the criteria for appearing in a server's room directory in the first place is way too broad. Also, abuse doesn't happen in a vacuum. Some rooms that were fine at the time of the freeze, are not now. There are a few different causes for that, including room moderators losing interest. We looked for criteria to give us the confidence in removing the freeze, and we hit all the edge cases that make safety work so challenging. Those lessons led to a realization. One of the values of the Foundation is pragmatism, rather than perfection. We weren't living up to that value, so we decided to change. The plan became simpler: move to a curated list of rooms, with a rough first pass of criteria for inclusion. In parallel, we asked the Governing Board to come up with a process for adding rooms in the future, and to refine the criteria. We've completed the first part of the plan today. 🔗</a>What comes next</h2> There's plenty of scope for refinement here, and we've identified a few places where we can get started: The Governing Board will publish criteria for inclusion in the Matrix.org room directory. They'll also tell you how you can suggest rooms and spaces for the directory.</li> We're going to recommend safer defaults. Servers should not let users publish rooms unless there are appropriate filtering and moderation tools in place, and people to wield them. For instance, Element have made this change to Synapse in PR18175</a></li> We're exploring discovery as a topic, including removing the room directory API. One promising idea is to use Spaces: servers could publish a default space, with rooms curated by the server admin. Our recent post includes some other projects we have in this area: https://matrix.org/blog/2025/02/building-a-safer-matrix/</a></li> </ul> 🔗</a>FAQs</h2> What criteria did you use for this first pass? We used a rough rubric: Is the room already in the room directory, and does the Foundation already protect the room with the Matrix.org Mjolnir? From there, we extended to well-moderated rooms and spaces that fit one of the following: Matrix client and server implementations (e.g. FluffyChat, Dendrite)</li> Matrix community projects (e.g. t2bot.io)</li> Matrix homeserver spaces with a solid safety record (e.g. tchncs.de, envs.net)</li> </ul> Why isn't the Office of the Foundation in the directory? It didn't exist before May 2024, so the Office has never been in the directory. We're going to add it in the next few days, with a couple of other examples that fit our rough rubric. How do I add my room/space to the list? At the moment, you can't. The Governing Board will publish the criteria and the flow for getting on the list. What do I do if I find a harmful room in the current directory? You shouldn't, but if a room does have harmful content, check out How you can help</a> Building a Safer Matrix 2025-02-14T14:30:00+00:00 N.B. this post is also available in German</a> below. 🔗</a>Introduction</h2> Right now, the world needs secure communication more than ever. Waves of security breaches such as the “Salt Typhoon” compromise of the telephone network’s wiretap system have led the FBI to advise US citizens to switch to end-to-end-encrypted communication</a>. Geopolitical shifts painfully highlight the importance of privacy-preserving communication for vulnerable minorities, in fear of being profiled or targeted. Meanwhile the International Rules-Based Order is at risk</a> like never before. We built Matrix to provide secure communication for everyone</a> - to be the missing communication layer of the Open Web. This is not hyperbole: Matrix is literally layered on top of the Web - letting organisations run their own servers while communicating in a wider network. As a result, Matrix is “decentralised”: the people who built Matrix do not control those servers; they are controlled by the admins who run them - and just as the Web will outlive Tim Berners-Lee, Matrix will outlive us. Matrix itself is a protocol (like email), defined as an open standard</a> maintained by The Matrix.org Foundation C.I.C - a UK non-profit incorporated in 2018 to act as the steward of the protocol; to coordinate the protocol’s evolution and to work on keeping the public Matrix network safe. The Foundation is funded by donations from its members</a> (both individuals and organisations), and also organises the Matrix.org homeserver instance used by many as their initial home on the network. Much like the Web, Matrix is a powerful technology available to the general public, which can be used both for good and evil. The vast majority of Matrix’s use is constructive: enabling collaboration for open source software communities such as Mozilla</a>, KDE</a>, GNOME</a>, Fedora</a>, Ubuntu</a>, Debian</a>, and thousands of smaller projects; providing a secure space for vulnerable user groups; secure collaboration throughout academia (particularly in DACH</a>); protecting healthcare communication</a> in Germany; protecting national communication in France</a>, Germany</a>, Sweden</a> and Switzerland</a>; and providing secure communication for NATO</a>, the US DoD</a> and Ukraine. You can see the scope and caliber of the Matrix ecosystem from the talks at The Matrix Conference</a> in September. However, precisely the same capabilities which benefit privacy-sensitive organisations mean that a small proportion of members of the public will try to abuse the system. We have been painfully aware of the risk of abuse since the outset of the project, and rather than abdicating responsibility in the way that many encrypted messengers do, we’ve worked steadily at addressing it. In the early days, even before we saw significant abuse, this meant speculating on approaches to combat it (e.g. our FOSDEM 2017</a> talk and subsequent 2020 blog post</a> proposing decentralised reputation; now recognisable in Bluesky’s</a> successful Ozone</a> anti-abuse system and composable moderation). However, these posts were future-facing at the time - and these days we have different, concrete anti-abuse efforts in place. In this post, we’d like to explain where things are at, and how they will continue to improve in future. 🔗</a>What we do today</h2> The largest use of our funding as a Foundation is spent on our full-time Safety team, and we expanded that commitment at the end of 2024. On a daily basis, the team triage, investigate, identify and remove harmful content from the Matrix.org server, and remove users who share that material. They also build tooling to prevent, detect and remove harmful content, and to protect the people who work on user reports and investigations. The humans who make up the Foundation Trust & Safety team are dedicated professionals who put their own mental health and happiness in jeopardy every day, reviewing harmful content added by people abusing the service we provide. Their work exposes them to harms including child sexual exploitation and abuse (CSEA), terrorist content, non-consensual intimate imagery (NCII), harassment, hate, deepfakes, fraud, misinformation, illegal pornography, drugs, firearms, spam, suicide, human trafficking and more. It’s a laundry list of the worst that humanity has to offer. The grim reality is that all online services have to deal with these problems, and to balance the work to detect and remove that content with the rights of their users. We’re committed to that work, and to supporting the Trust & Safety team to the best of our ability — we are very grateful for their sacrifice. 🔗</a>Safety Tooling on Matrix</h3> The Safety team tackles safety from two perspectives: keeping the users on the Matrix.org server safe, and helping to make the wider Matrix network as a whole safe, secure and private. For the latter, we contribute to the development of the Matrix specification, engage with the Matrix ecosystem, and consult with governments, law enforcement, civil society groups, academia and industry groups. We also invest in open source tooling to help the ecosystem with this problem. For the former, we employ a mix of proactive and reactive approaches to online harms. The Matrix Specification includes a system for reporting rooms, messages and users to your homeserver, API endpoints for server admins to lock, suspend and deactivate users, mechanisms for quarantining harmful media and redacting unwanted messages. We use all of these, receiving hundreds of reports per week from users of the Matrix.org server and emails to our reporting address. Additionally, we scan room names and titles on the Matrix.org server using a variety of keyword lists, and highlight matches for human review. We also maintain a moderation bot called Mjolnir</a>, which we use to moderate our community rooms, and offer as open source for other communities to use. Behind the scenes, we have tools to help the frontline safety team to investigate rooms, users and messages, and to take action where there is abuse. When we identified abuse of the Matrix.org server room directory, we froze the directory and removed abusive rooms. In the near future, we’ll be moving to a curated directory, to stop it being used as an advertising system for abuse. It’s worth noting that historically Matrix has unintentionally given a platform to abuse with the concept of these “room directories”, which (unlike other encrypted messengers like Signal or Threema or WhatsApp) allow any user to advertise public chatrooms without needing admin approval - this is a mistake we deeply regret, and will address by switching to curated room directories in general. 🔗</a>Approaches to tackling CSEA</h4> One of our main focuses is tackling child sexual exploitation and abuse. We abhor CSEA, and have always explicitly called it out in our Terms and Conditions as something we work with law enforcement to combat. We deploy tooling and specific techniques to arrest the spread of CSEA on the Matrix.org server: We work with the Internet Watch Foundation (IWF), National Center for Missing and Exploited Children (NCMEC), cybertip.ca</a>, the Australian eSafety Commissioner and other parties. (Element, who runs the Matrix.org server on behalf of the Foundation, has been an active member of IWF</a> since 2020).</li> We work with law enforcement in the UK and the US.</li> We’ve consulted with groups like the Lucy Faithfull Foundation and Columbia SIPA to learn from their expertise.</li> We use Cloudflare’s CSAM detection APIs</a> on unencrypted content on Matrix.org.</li> We use the IWF Hash, URL and Keyword lists from the IWF on unencrypted content on Matrix.org.</li> We block rooms, remove media and suspend users who participate in rooms dedicated to sharing CSEA.</li> We engage productively with and welcome robust critique from civil society groups, and invite them to join us in tackling CSEA. Check out the How you can help</a> section below for details.</li> </ul> 🔗</a>Recent Updates</h3> Over the past six months, we’ve invested in improved tooling for the frontline team who review user reports. We’ve sponsored the addition of account suspension</a> to the Matrix Specification, and added a mass redaction API</a> endpoint for the most popular Matrix server implementation, Synapse, so that both the Matrix.org server and other server instances in the ecosystem can benefit. Suspension gives us reversible account enforcement, which means we can develop more automated systems for faster takedown ahead of investigation. This should reduce the time that illegal material is accessible, while enhancing the rights and protections of our users. We’ve also recently added authenticated media</a>, stopping abuse of Matrix as a content distribution network. We worked with the IWF on this project, following reports of abuse of Matrix servers as a content delivery mechanism for ICAP sites</a>. 🔗</a>The Matrix Community</h3> The wider Matrix community has strong anti-abuse initiatives, which we are deeply encouraged by. In particular, the work on the Draupnir</a> moderation bot project and the Community Moderation Effort (CME</a>) are excellent additions to the safety ecosystem on Matrix. At the server tooling level, Awesome Technologies’ synapse-admin tool</a> and the fork by etke.cc</a> are great examples of how open source ecosystems can contribute to safety tooling. We celebrate their work, and hope to see more grass-roots developments in the coming months and years. 🔗</a>What we are working on</h2> Reporting While we have a functional reporting system, we can make it better. In particular, users will receive updates on their reports and outcomes of those investigations. We’ll improve how users are notified about moderation action taken on their account, and how they can appeal those decisions. The entire ecosystem will benefit from these improvements, as we will contribute them to the Matrix Spec. Discovery & Project Intercept We’re in the early stages of a project to tackle the search and discovery of CSEA. We’ve had productive conversations with the Lucy Faithfull Foundation and Project Intercept about effective steps to redirect harmful search queries on Matrix.org for that kind of content. Transparency Reporting Accountability is important, so we’re aiming to start releasing transparency reports for Matrix.org this year. The project is nascent, but we’ll share details and invite contributions as we get closer to making it a reality. We’ll be working closely with the Governing Board</a> on this project. We are hopeful that adding transparency reports will support our applications to join industry groups like GIFCT</a>, Tech Against Terrorism</a> and Tech Coalition</a>. Terms of Service updates We’re overhauling our terms of service to make it clearer what content is forbidden, and how to report it to us. Where we use proactive scanning techniques, we’ll make that clear in the terms, including how to appeal decisions made by automated systems. Open source our tooling As we improve the tooling we use to manage safety on Matrix.org, we want to share our work. We’ll talk more about our goals here in future updates. We’re also engaging with the work of open source safety tooling that ROOST</a> are doing, as one of their partners. Meeting and beating our obligations under the Online Safety Act We’re based in the UK, and we’ve engaged productively with the Online Safety Act since its conception. That includes our continued robust opposition to threats to end-to-end encryption. We already employ perceptual hash matching for CSEA content in unencrypted rooms, and we will continue to invest in this area, to work towards faster and more accurate takedowns, while respecting the privacy of our users. Talking about our work, sharing what we learn A fair criticism of the Foundation is that we haven’t shared publicly about what we do to keep Matrix.org users safe enough, nor what we do to ensure that Matrix as a platform has safe foundations. Let’s change that in 2025, starting with this post. 🔗</a>How you can help</h2> 🔗</a>As a user of Matrix</h3> If you encounter harmful content on Matrix, you can report it in a few ways: If you are a Matrix.org homeserver user, you can report the content</a> from your client, and it will head to our Trust & Safety team. Matrix clients like Element iOS now allow users to report rooms</a>, and we understand it will be available in Element X, Element Android and Element Web soon.</li> If you use another Matrix server, you can report to your server administrator from your client too.</li> If you are not a Matrix user, or if you are a user on another homeserver who wants to let us know about harmful content on Matrix.org, you can email us at abuse@matrix.org</a> with the information you have. Room IDs and user IDs are very helpful. Please don't send us screenshots of harmful content — we'll let you know if we need more information.</li> </ul> 🔗</a>If you run a Matrix server</h3> Open registration is disabled by default</a> in Synapse, and we support that default. If your server offers open registration, you must invest in a safety team to provide appropriate moderation coverage, and mitigate the risks of allowing unknown users to use your server.</li> Review who is signing up for your server, and the rooms that your server joins.</li> Review reports from your users, and take action to remove harmful content they report. You should check your legal obligations in the country you host your server.</li> Work with other server operators to share information about harmful rooms and users. You can reach out to our Safety team at abuse@matrix.org</a> to start that conversation.</li> </ul> 🔗</a>Civil Society Groups, Academia and Industry Groups</h3> We welcome the help of civil society groups and academics working in this area. Please reach out to abuse@matrix.org</a> with your contact details and area of interest, and we'll talk. We're very interested in bringing on trusted flaggers, so if you want to send us reports, please let us know. Challenging the spread of online harm needs all parts of the puzzle to work together, and we’re looking to be a good example of how tech can work for society. For industry groups, we’d love to work with you, to share experiences and to learn from each other. The barriers to entry for these groups are a challenge, and we’d welcome your help in participating. 🔗</a>Law Enforcement</h3> Please check out our guidelines here: https://matrix.org/legal/law-enforcement-guidelines/</a> 🔗</a>Funding</h3> The tech industry under-invests in Safety. We’re trying to do things better, and Safety is the largest line item in the Matrix.org Foundation budget. This investment is despite the challenges we face in our ongoing</a> attempts to raise funds</a> to support the development of Matrix and</a> open software generally</a>. We rely on donations to operate. Big public and private organizations use the work we do, often without contributing back to support that work financially. It would be easy to sacrifice Trust & Safety spending given that set of economic constraints, but we’re trying to find a better path through. If you would like to fund our work on safety, please reach out to the Foundation at funding@matrix.org</a>. 🔗</a>Für mehr Schutz in Matrix</h1> 🔗</a>Einleitung</h2> Gerade jetzt braucht die Welt mehr denn je sichere Kommunikation. Wellen von Sicherheitsverletzungen wie der „Salt Typhoon“, der das Abhörsystem des Telefonnetzes kompromittierte, haben das FBI veranlasst, den US-Bürgern zu raten, auf eine Ende-zu-Ende-verschlüsselte Kommunikation umzusteigen</a>. Geopolitische Veränderungen machen schmerzlich deutlich, wie wichtig der Schutz der Privatsphäre bei der Kommunikation für gefährdete Minderheiten ist, die befürchten, profiliert oder ins Visier genommen zu werden. Gleichzeitig ist die regelbasierte internationale Ordnung so gefährdet</a> wie nie zuvor. Wir haben Matrix entwickelt, um sichere Kommunikation für alle</a> zu ermöglichen - um die fehlende Kommunikationsschicht des Open Web zu sein. Das ist keine Übertreibung: Matrix ist buchstäblich eine Schicht über dem Web, die es Organisationen ermöglicht, ihre eigenen Server zu betreiben und gleichzeitig in einem größeren Netzwerk zu kommunizieren. Folglich ist Matrix „dezentralisiert“: Die Leute, die Matrix entwickelt haben, kontrollieren diese Server nicht; sie werden von den Administratoren kontrolliert, die sie betreiben - und so wie das Web Tim Berners-Lee überleben wird, wird Matrix uns überleben. Matrix selbst ist ein Protokoll (wie E-Mail), das als offener Standard</a> definiert ist und von der Matrix.org Foundation C.I.C. gepflegt wird - einer gemeinnützigen britischen Stiftung, die 2018 gegründet wurde, um als Verwalterin des Protokolls zu fungieren, die Weiterentwicklung des Protokolls zu koordinieren und das öffentliche Matrix-Netzwerk sicher zu halten. Die Stiftung wird durch Spenden ihrer Mitglieder</a> (sowohl Einzelpersonen als auch Organisationen) finanziert und organisiert auch die Matrix.org-Homeserver-Instanz, die von vielen als erste Heimat im Netzwerk genutzt wird. Ähnlich wie das Internet ist auch Matrix eine mächtige Technologie, die der Allgemeinheit zur Verfügung steht und sowohl zum Guten als auch zum Bösen eingesetzt werden kann. Die überwiegende Mehrheit der Matrix-Nutzung ist konstruktiv: Sie ermöglicht Zusammenarbeit in Open-Source-Software-Communities wie Mozilla</a>, KDE</a>, GNOME</a>, Fedora</a>, Ubuntu</a>, Debian</a> und tausende kleinerer Projekte; sie bietet einen sicheren Raum für gefährdete Benutzergruppen; sichere Zusammenarbeit in der gesamten akademischen Welt (insbesondere in der DACH-Region</a>); Schutz der Kommunikation im Gesundheitswesen</a> in Deutschland; Schutz der nationalen Kommunikation in Frankreich</a>, Deutschland</a>, Schweden</a> und der Schweiz</a>; und sichere Kommunikation für die NATO</a>, das US-DoD</a> und die Ukraine. Aus den Vorträgen auf der Matrix-Konferenz</a> im September ist der Umfang und das Kaliber des Matrix-Ökosystems klar ersichtlich. Genau die gleichen Fähigkeiten, die datenschutzsensiblen Organisationen zugute kommen, bedeuten jedoch, dass ein kleiner Teil der Öffentlichkeit versuchen wird, das System zu missbrauchen. Wir waren uns dieses Missbrauchsrisikos von Anfang an bewusst, und anstatt uns der Verantwortung zu entziehen, wie es viele verschlüsselte Messenger tun, haben wir kontinuierlich daran gearbeitet, dieses Problem zu addressieren. In den frühen Tagen, noch bevor wir signifikanten Missbrauch sahen, bedeutete dies, dass wir über Ansätze zur Bekämpfung des Missbrauchs spekulierten (z. B. unser Vortrag auf der FOSDEM 2017</a> und der darauffolgende Blogbeitrag 2020</a>, in dem wir eine dezentrale Reputation vorschlugen; heute erkennbar in Blueskys</a> erfolgreichem Ozone-System zur Missbrauchsbekämpfung</a> und der modularen Moderation). Damals waren diese Beiträge jedoch zukunftsorientiert - und heute wenden wir andere konkrete Methoden zur Missbrauchsbekämpfung an. In diesem Beitrag möchten wir erklären, wo die Dinge heute stehen und wie sie sich in Zukunft weiter verbessern werden. 🔗</a>Unsere aktuelle Arbeit</h2> Der größte Teil unserer Mittel als Stiftung wird für unser Vollzeit-Trust-&-Safety-Team verwendet, und wir haben dieses Engagement Ende 2024 erweitert. Das Team kümmert sich täglich um die Sichtung, Untersuchung, Identifizierung und Entfernung schädlicher Inhalte vom Matrix.org-Server und entfernt Nutzer, die dieses Material teilen. Darüber hinaus entwickelt es Werkzeuge zur Verhinderung, Erkennung und Entfernung schädlicher Inhalte und zum Schutz der Mitarbeiter, die an den Berichten und Untersuchungen der Nutzer arbeiten. Die Menschen, die das Trust & Safety Team der Stiftung bilden, sind engagierte Fachleute, die jeden Tag ihre eigene geistige Gesundheit und ihr Wohlbefinden aufs Spiel setzen, indem sie schädliche Inhalte überprüfen, die von Menschen hinzugefügt wurden, die den von uns angebotenen Dienst missbrauchen. Bei ihrer Arbeit sind sie Gefahren ausgesetzt, darunter sexuelle Ausbeutung und Missbrauch von Kindern (CSEA), terroristische Inhalte, nicht einvernehmliche intime Bilder (NCII), Belästigung, Hass, Deepfakes, Betrug, Fehlinformationen, illegale Pornografie, Drogen, Schusswaffen, Spam, Selbstmord, Menschenhandel und mehr. Es ist eine Wäscheliste mit dem Schlimmsten, was die Menschheit zu bieten hat. Die düstere Realität ist, dass sich alle Online-Dienste mit diesen Problemen auseinandersetzen und die Arbeit zur Erkennung und Entfernung dieser Inhalte mit den Rechten ihrer Nutzer in Einklang bringen müssen. Wir haben uns dieser Arbeit verschrieben und unterstützen das Trust & Safety Team nach besten Kräften - wir sind sehr dankbar für ihre Aufopferung. 🔗</a>Schutzwerkzeuge für Matrix</h3> Das Trust & Safety Team befasst sich mit dem Thema Schutz aus zwei Blickwinkeln: Schutz für die Nutzer des Matrix.org-Servers und Schutz für das gesamte Matrix-Netzwerk als Ganzes. Für letzteres tragen wir zur Entwicklung der Matrix-Spezifikation bei, stehen im engen Austausch mit anderen im Matrix-Ökosystem und beraten uns mit Regierungen, Strafverfolgungsbehörden, zivilgesellschaftlichen Gruppen, Hochschulen und Industriegruppen. Wir investieren auch in Open-Source-Werkzeuge, um das Ökosystem bei diesem Problem zu unterstützen. Für ersteres setzen wir eine Mischung aus proaktivem und reaktivem Vorgehen gegen Online-Missbrauch ein. Die Matrix-Spezifikation umfasst ein System zur Meldung von Räumen, Nachrichten und Nutzern an Ihren Homeserver, API-Endpunkte für Serveradministratoren zum Sperren, Suspendieren und Deaktivieren von Nutzern, Mechanismen zur Quarantäne von schädlichen Medien und zum Entfernen unerwünschter Nachrichten. Wir nutzen all diese Möglichkeiten und erhalten wöchentlich Hunderte von Meldungen von Benutzern des Matrix.org-Servers und E-Mails an unsere Meldeadresse. Darüber hinaus scannen wir Raumnamen und -titel auf dem Matrix.org-Server anhand einer Reihe von Schlüsselwortlisten und unterziehen Übereinstimmungen einer menschlichen Überprüfung. Wir pflegen auch einen Moderations-Bot namens Mjolnir</a>, den wir zur Moderation unserer Community-Räume verwenden und als Open Source für andere Communities zur Verfügung stellen. Hinter den Kulissen verfügen wir über Werkzeuge, die dem Trust & Safety Team an vorderster Front helfen, Räume, Benutzer und Nachrichten zu untersuchen und Maßnahmen zu ergreifen, wenn Missbrauch vorliegt. Als wir den Missbrauch des Serverraumverzeichnisses von Matrix.org feststellten, haben wir das Verzeichnis eingefroren und missbräuchliche Räume entfernt. In naher Zukunft werden wir zu einem kuratierten Verzeichnis wechseln, um zu verhindern, dass es als Werbesystem für Missbrauch genutzt wird. Es ist erwähnenswert, dass Matrix in der Vergangenheit mit dem Konzept dieser „Raumverzeichnisse“ unbeabsichtigt eine Plattform für Missbrauch geschaffen hat, da diese (im Gegensatz zu anderen verschlüsselten Messengern wie Signal oder Threema oder WhatsApp) jedem Nutzer erlauben, öffentliche Chaträume aufzulisten, ohne dass eine Genehmigung des Administrators erforderlich ist - dies ist ein Fehler, den wir zutiefst bedauern und den wir durch den Wechsel zu kuratierten Raumverzeichnissen im Allgemeinen beheben werden. 🔗</a>Strategien gegen sexuellen Kindesmissbrauch und Ausbeutung (CSEA)</h4> Einer unserer Schwerpunkte ist der Kampf gegen die sexuelle Ausbeutung und den Missbrauch von Kindern. Wir verabscheuen sexuelle Ausbeutung von Kindern (CSEA) und haben in unseren Nutzungsbedingungen immer ausdrücklich darauf hingewiesen, dass wir mit den Strafverfolgungsbehörden zusammenarbeiten, um sie zu bekämpfen. Wir setzen Werkzeuge und spezielle Techniken ein, um die Verbreitung von CSEA auf dem Matrix.org-Server zu unterbinden: Wir arbeiten mit der Internet Watch Foundation (IWF), dem National Center for Missing and Exploited Children (NCMEC), cybertip.ca</a>, dem Australian eSafety Commissioner und anderen Parteien zusammen. (Element, das den Matrix.org-Server im Auftrag der Stiftung betreibt, ist seit 2020 aktives Mitglied der IWF</a>).</li> Wir arbeiten mit Strafverfolgungsbehörden im Vereinigten Königreich und in den USA zusammen.</li> Wir haben uns mit Gruppen wie der Lucy Faithfull Foundation und Columbia SIPA beraten, um von deren Fachwissen zu lernen.</li> Wir verwenden die CSAM-Erkennungs-APIs</a> von Cloudflare für unverschlüsselte Inhalte auf Matrix.org.</li> Wir verwenden die IWF-Hash-, URL- und Schlüsselwortlisten der IWF für unverschlüsselte Inhalte auf Matrix.org.</li> Wir sperren Räume, entfernen Medien und suspendieren Benutzer, die an Räumen teilnehmen, die dem Austausch von CSEA gewidmet sind.</li> Wir stehen in produktivem Austausch mit zivilgesellschaftlichen Gruppen und begrüßen deren fundierte Kritik und laden sie ein, gemeinsam mit uns gegen CSEA vorzugehen. Weitere Informationen finden Sie weiter unten im Abschnitt Wie Sie helfen können</a>.</li> </ul> 🔗</a>Aktuelle Maßnahmen</h3> In den letzten sechs Monaten haben wir in verbesserte Werkzeuge für das Frontline-Team investiert, das Nutzerberichte überprüft. Wir haben die Aufnahme der Kontosperrung</a> in die Matrix-Spezifikation unterstützt und einen API-Endpunkt für Massenlöschung</a> für die am weitesten verbreitete Matrix-Server-Implementierung, Synapse, hinzugefügt, damit sowohl der Matrix.org-Server als auch andere Serverinstanzen im Ökosystem davon profitieren können. Bei der Kontosperrung können wir die Moderation von Konten umkehren, was bedeutet, dass wir mehr automatisierte Systeme für eine schnellere Löschung vor der Untersuchung entwickeln können. Dadurch sollen die Zeit, in der illegales Material zugänglich ist, verkürzt und gleichzeitig die Rechte und der Schutz unserer Nutzer gestärkt werden. Außerdem haben wir kürzlich Authentifizierung für Medien</a> hinzugefügt, um den Missbrauch von Matrix als Netzwerk zur Verbreitung von Inhalten zu unterbinden. Wir haben bei diesem Projekt mit der IWF zusammengearbeitet, nachdem Berichte über den Missbrauch von Matrix-Servern als Content-Delivery-Mechanismus für ICAP-Seiten</a> eingegangen waren. 🔗</a>Die Matrix Community</h3> Die breitere Matrix-Community hat starke Initiativen zur Missbrauchsbekämpfung, die uns sehr ermutigen. Insbesondere die Arbeit am Draupnir-Moderationsbot-Projekt</a> und der Community Moderation Effort (CME</a>) sind hervorragende Ergänzungen zum Schutzökosystem von Matrix. Auf der Ebene der Server-Werkzeuge sind Synapse-Admin</a> von Awesome Technologies und der Fork von etke.cc</a> großartige Beispiele dafür, wie Open-Source-Ökosysteme zu Schutzwerkzeugen beitragen können. Wir freuen uns über ihre Arbeit und hoffen, dass wir in den kommenden Monaten und Jahren weitere auf eigenen Füßen stehende Entwicklungen sehen werden. 🔗</a>Woran wir gerade arbeiten</h2> Reporting Wir haben zwar ein funktionierendes Meldesystem, aber wir können es noch besser machen. Insbesondere werden künftig die Nutzer Updates zu ihren Berichten und den Ergebnissen dieser Untersuchungen erhalten. Wir werden die Art und Weise verbessern, wie Nutzer über Moderationsmaßnahmen in ihrem Konto benachrichtigt werden und wie sie diese Entscheidungen anfechten können. Das gesamte Ökosystem wird von diesen Verbesserungen profitieren, da wir sie in die Matrix Spezifikation einbringen werden. Identifizierung & Project Intercept Wir befinden uns in der Anfangsphase eines Projekts, das sich mit der Suche und Identifizierung von CSEA befasst. Wir hatten produktive Gespräche mit der Lucy Faithfull Foundation und Project Intercept über wirksame Schritte zur Umleitung schädlicher Suchanfragen auf Matrix.org für diese Art von Inhalten. Transparenz Reporting Rechenschaftspflicht ist wichtig, deshalb wollen wir dieses Jahr mit der Veröffentlichung von Transparenzberichten für Matrix.org beginnen. Das Projekt befindet sich noch im Anfangsstadium, aber wir werden Einzelheiten bekannt geben und um Unterstützung und Mitwirkung bitten, sobald wir der Verwirklichung näher kommen. Wir werden bei diesem Projekt eng mit dem Matrix.org-Verwaltungsrat (Governing Board) zusammenarbeiten</a>. Wir hoffen, dass das Hinzufügen von Transparenzberichten unsere Anträge auf Mitgliedschaft in Branchengruppen wie GIFCT</a>, Tech Against Terrorism</a> und Tech Coalition</a> unterstützen wird. Aktualisierungen der Nutzungsbedingungen Wir überarbeiten unsere Nutzungsbedingungen, um deutlicher zu machen, welche Inhalte verboten sind und wie man sie uns melden kann. In den Fällen, in denen wir proaktive Scanning-Techniken einsetzen, werden wir dies in den Bedingungen klarstellen, einschließlich der Frage, wie man gegen Entscheidungen automatischer Systeme Einspruch erheben kann. Unsere Werkzeuge als Open Source freigeben Während wir die Werkzeuge für das Schutzmanagement auf Matrix.org verbessern, wollen wir unsere Arbeit mit anderen teilen. Wir werden in zukünftigen Beiträgen mehr über unsere Ziele sprechen. Als einer der Partner von ROOST</a> beteiligen wir uns auch an der Arbeit an Open-Source-Schutzwerkzeugen. Erfüllung und Übertreffen unserer Verpflichtungen gemäß dem Online Safety Act Wir sind im Vereinigten Königreich ansässig und haben uns von Anfang an produktiv mit dem Online Safety Act auseinandergesetzt. Dazu gehört auch, dass wir uns weiterhin entschieden gegen die Bedrohung der Ende-zu-Ende-Verschlüsselung wehren. Wir setzen bereits den Perceptual Hash Matching für CSEA-Inhalte in unverschlüsselten Räumen ein und werden weiterhin in diesen Bereich investieren, um schnellere und genauere Abschaltungen zu erreichen und gleichzeitig die Privatsphäre unserer Nutzer zu respektieren. Über unsere Arbeit sprechen und unsere Erkenntnisse teilen Eine berechtigte Kritik an der Stiftung lautet, dass wir nicht viel darüber gesprochen haben, was wir tun, um den Schutz der Matrix.org-Nutzer zu gewährleisten, und auch nicht darüber, was wir tun, um sicherzustellen, dass Matrix als Plattform ein sicheres Fundament hat. Das wollen wir im Jahr 2025 ändern, angefangen mit diesem Artikel. 🔗</a>Wie Sie helfen können</h2> 🔗</a>Als Nutzer von Matrix</h3> Wenn Sie auf Matrix auf schädliche Inhalte stoßen, können Sie diese auf verschiedene Weise melden: Wenn Sie den Matrix.org-Homeserver nutzen, können Sie die Inhalte</a> von Ihrem Client aus melden, und sie werden an unser Trust & Safety Team weitergeleitet. Matrix-Clients wie Element iOS ermöglichen es Nutzern, Räume zu melden</a>, und wir wissen, dass dies bald auch in Element X, Element Android und Element Web verfügbar sein wird.</li> Wenn Sie einen anderen Matrix-Server verwenden, können Sie die Meldung ebenfalls von Ihrem Client aus an Ihren Server-Administrator senden.</li> Wenn Sie kein Matrix-Nutzer sind oder wenn Sie ein Nutzer auf einem anderen Homeserver sind und uns über schädliche Inhalte auf Matrix.org informieren möchten, können Sie uns eine E-Mail mit den Informationen, die Sie haben, an abuse@matrix.org</a> schicken. Raum- und Benutzerkennungen sind sehr hilfreich. Bitte schicken Sie uns keine Bildschirmfotos von schädlichen Inhalten - wir werden Ihnen Bescheid geben, wenn wir weitere Informationen benötigen.</li> </ul> 🔗</a>Als Matrix-Server-Betreiber</h3> Die offene Registrierung ist in Synapse standardmäßig deaktiviert</a>, und wir befürworten diese Voreinstellung. Wenn Ihr Server eine offene Registrierung anbietet, müssen Sie in ein Trust & Safety Team investieren, um eine angemessene Moderation zu gewährleisten und die Risiken zu minimieren, die entstehen, wenn Sie unbekannten Benutzern die Nutzung Ihres Servers erlauben.</li> Überprüfen Sie, wer sich auf Ihrem Server anmeldet und in welchen Räumen Ihr Server Mitglied ist.</li> Überprüfen Sie die Meldungen Ihrer Nutzer und ergreifen Sie Maßnahmen, um gemeldete schädliche Inhalte zu entfernen. Überprüfen Sie Ihre rechtlichen Verpflichtungen in dem Land, in dem Sie Ihren Server betreiben.</li> Arbeiten Sie mit anderen Serverbetreibern zusammen, um Informationen über schädliche Räume und Nutzer auszutauschen. Sie können sich an unser Trust & Safety Team unter abuse@matrix.org</a> wenden, um dieses Gespräch zu beginnen.</li> </ul> 🔗</a>Zivilgesellschaftliche Gruppen, Wissenschaft und Industrieverbände</h3> Wir begrüßen die Unterstützung aus zivilgesellschaftlichen Gruppen und der Wissenschaft, die in diesem Bereich arbeiten. Bitte wenden Sie sich an abuse@matrix.org</a> und teilen Sie uns Ihre Kontaktdaten und Ihr Interessengebiet mit, damit wir uns austauschen können. Wir sind sehr daran interessiert, vertrauenswürdige Berichterstatter hinzuzuziehen; wenn Sie uns also Berichte schicken möchten, melden Sie sich bitte bei uns. Um die Ausbreitung von Online-Missbrauch zu bekämpfen, müssen alle Teile des Puzzles zusammenarbeiten, und wir wollen ein gutes Beispiel dafür sein, wie Technik eine positive Auswirkung auf die Gesellschaft haben kann. Wir würden gerne mit Branchengruppen zusammenarbeiten, Erfahrungen austauschen und voneinander lernen. Die Eintrittsbarrieren für diese Gruppen sind eine Herausforderung, und wir würden uns freuen, wenn Sie uns helfen würden, sie abzubauen. 🔗</a>Strafverfolgungsbehörden</h3> Bitte lesen Sie unsere Leitlinien hier: https://matrix.org/legal/law-enforcement-guidelines/</a> 🔗</a>Finanzierung</h3> Die Tech-Industrie investiert zu wenig in Schutz. Wir versuchen, es besser zu machen, und Schutz ist der größte Posten im Haushalt der Matrix.org Stiftung. Diese Investition erfolgt trotz der Herausforderungen, denen wir uns bei unseren ständigen</a> Versuchen gegenübersehen</a>, Mittel zur Unterstützung</a> der Entwicklung von Matrix und</a> Open Source Software im Allgemeinen</a> aufzubringen. Wir sind für unseren Betrieb auf Spenden angewiesen. Große öffentliche und private Organisationen nutzen die von uns geleistete Arbeit, oft ohne einen finanziellen Beitrag zu leisten. Es wäre einfach, die Ausgaben für Trust & Safety angesichts dieser wirtschaftlichen Zwänge zu opfern, aber wir versuchen, einen besseren Weg zu finden. Wenn Sie unsere Arbeit im Bereich Schutz finanziell unterstützen möchten, wenden Sie sich bitte an die Stiftung unter funding@matrix.org</a>. The Matrix Holiday Special 2024 2024-12-25T00:00:00+00:00 Hi all, Once again we celebrate the end of another year with the traditional Matrix Holiday Special! (see also 2023</a>, 2022</a>, 2021</a>, 2020</a>, 2019</a>, 2018</a>, 2017</a>, 2016</a> and 2015</a> just in case you missed them). This year, it is an incredible relief to be able to sit down and write an update which is overwhelmingly positive - in stark contrast to the rather mixed bags of 2022 and 2023. This is not to say that things are perfect: most notably, The Matrix.org Foundation has not yet hit its funding goals, and urgently needs more organisations who depend on Matrix to join as members</a> in order to be financially sustainable. However, in terms of progress of Matrix towards outperforming the centralised alternatives; growth of the ecosystem; the success of the first ever Matrix Conference; we couldn’t be happier - and hopefully the more Matrix matures, the more folks will want to join the Foundation to help fund it. So, precisely why are we feeling so happy right now? 🔗</a>Matrix 2.0</h3> Matrix 2.0 is the project to ensure that Matrix can be used to build apps which outcompete the incumbent legacy mainstream communication apps. Since announcing the project at FOSDEM 2023, we’ve been hard at work iterating on: Sliding Sync, providing instant sync, instant login and instant launch.</li> Next Generation Auth via OIDC, to support instant login by QR code and consistent secure auth no matter the client.</li> Native Multiparty VoIP via MatrixRTC, to provide consistent end-to-end-encrypted calling conferencing within Matrix using Matrix’s encryption and security model.</li> Invisible Cryptography, to ensure that encryption in Matrix is seamless and no longer confuses users with unable-to-decrypt errors, scary shields and warnings, or other avoidable UX fails.</li> </ul> All of these projects are big, and we’ve been taking the time to iterate and get things right rather than cut corners – the whole name of the game has been to take Matrix from 1.0 (it works) to 2.0 (it works fast and delightfully, and outperforms the others). However, in September at the Matrix Conference we got to the point of shipping working implementations of all of the Matrix 2.0 MSCs, with the expectation of using these implementations to prove the viability of the MSCs and so propose them for merging into the spec proper. Sliding Sync ended up evolving into MSC4186</a>: Simplified Sliding Sync, and is now natively integrated into Synapse (no more need to run a sliding sync proxy!) and deployed on matrix.org, and implemented in matrix-rust-sdk and matrix-js-sdk. MatrixRTC is MSC4143</a> and dependents and is also deployed on matrix.org and call.element.io. Invisible Cryptography is a mix of MSCs: MSC4161</a> (Crypto terminology for non-technical users), MSC4153</a> (Exclude non-cross-signed devices), MSC3834</a> (Opportunistic user key pinning (TOFU)), and is mostly now implemented in matrix-rust-sdk - and Unable To Decrypt problems have been radically reduced (see Kegan’s excellent Matrix Conference talk</a> for details). Finally, Next Gen Auth is MSC3861</a> and is planned to be deployed on matrix.org via matrix-authentication-service</a> in Feb 2025. It’s been controversial to ship Matrix 2.0 implementations prior to the MSCs being fully finalised and merged, but given the MSCs are backwards compatible with Matrix 1.0, and there’s unquestionable benefit to the ecosystem in getting these step-changes in the hands of users ASAP, we believe the aggressive roll-out is justified. Meanwhile, now the implementations are out and post-launch teething issues have largely been resolved, the MSCs will progress forwards. One of the things we somehow failed to provide when announcing the implementations at the Matrix Conference was a playground for folks to experiment with Matrix 2.0 themselves. There’s now one based on Element’s stack of Synapse + matrix-authentication-service + Element Web + Element Call available at element-docker-demo</a> in case you want to do a quick docker compose up</code> to see what all the fuss is about! Meanwhile, matrix.org should support all the new MSCs in February – which might even coincide with the MSCs being finalised, you never know! Rather than going through Matrix 2.0 in detail again, best bet is to check out the launch talk from The Matrix Conference…

🔗</a>Law Enforcement</h3>
Please check out our guidelines here: https://matrix.org/legal/law-enforcement-guidelines/</a></p>

🔗</a>Strafverfolgungsbehörden</h3>
Bitte lesen Sie unsere Leitlinien hier: https://matrix.org/legal/law-enforcement-guidelines/</a></p>

Matrix.org - General

Solidarity Social operates a Bluesky PDS and uses Matrix for private DMs

Welcoming Discord users amidst the challenge of Age Verification

Matrix on Cloudflare Workers

The 2025 Matrix Holiday Special

Project Hydra: Improving state resolution in Matrix

How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver

Pre-disclosure: Upcoming coordinated security fix for all Matrix server implementations

Demystifying SBGs

Dispelling myths and misinformation

Introducing premium accounts to fund the matrix.org homeserver

Introducing Policy Servers

We're at a crossroads

Switching to Curated Room Directories

Building a Safer Matrix

The Matrix Holiday Special 2024