This Week in Matrix 2024-11-15

🔗Dept of Status of Matrix 🌡️

🔗Sunsetting the Sliding Sync Proxy: Moving to Native Support

Will L announces

Work on Sliding Sync – which provides a significantly faster and more scalable sync experience in Matrix clients – has moved to focus on native support, and away from the proxy.

The Sliding Sync Proxy on the Matrix.org homeserver will be decommissioned on November 21st, and client support in Element X will be removed on January 17th.

More details for users as well as server and client developers in Matrix.org's latest blog post

🔗First Official Governing Board Meeting

HarHarLinks says

It is Friday TWIMday the 15th of November, and the Governing Board just came out of their first official meeting after the informal one at the Matrix Conference back in September. The focus of this meeting was to define the structure of the Governing Board, so we expect the results will not have an immediate tangible effect outside the Governing Board, but it gives the Governing Board the basic process to enable taking more perceptible decisions.

This includes discussion about how we want to communicate with each other, but we also defined how we vote on actual decisions and some other basic rules for the Governing Board. As a part of that we elected a chair and vice chair for the Governing Board, who are going to help the Governing Board with facilitation tasks. Greg "Gwmngilfen" (chair) and Kim "HarHarLinks" (vice) were elected and are happy to share this post as one of our first actions in this role today. 😁 We also started some subcommittees of the Governing Board, to enable us to work efficiently in smaller groups focussed on specific topics. The rough topics for the initial four committees are Governance, Trust & Safety, Community, and Finances. What their exact scopes are going to be is left as a first task to the respective committees to define along with other bootstrapping, such as electing committee chairs and vice chairs. The set of initial committees is intentionally kept small to remain flexible and open the door for refining them later when we have more experience with how our day to day operations look like. We also discussed defining initial working groups, which would be structured as groups below the committees to fulfil more specific roles and would be the primary way for the Governing Board to include the community. However, we decided to defer that to the committees for now. We got through all the big parts on our agenda but ran out of time before having a formal vote on what communication tools we want to use. We have a great proposal which we are going to vote on asynchronously.

In general we had quite a productive meeting and reached agreements on many topics with clear next steps in other areas. The Governing Board might not have tackled yet the topics you would have prioritised, but it now has an asynchronous voting process and should be able to progress in other areas using the committees.

See you soon with more news from the Governing Board!

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} [back Nov 5] announces

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4227: Audio based quick login
• MSC4226: Reports as rooms

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Update

Once again there has been a flurry of activity on the spec repo itself, with Kévin Commaille continuing to fix up various aspects of the spec and the technical underpinnings of the website itself. They are also writing up spec PRs for recently accepted MSCs, such as MSC2781: Remove the reply fallbacks from the specification and MSC4138: Update allowed HTTP methods in CORS responses.

Many kudos for their continued efforts on advancing the spec!

🔗Homeserver Deployment 📥️

🔗Element Docker Demo

Matthew says

Last week I teased https://github.com/element-hq/element-docker-demo on Matrix Live - a two-liner for standing up a Matrix 2.0 stack for experimentation: ./setup.sh; docker compose up.

This week I published a proper walkthrough showing how you can use it for both a local setup with mkcert as well as a federated server setup with letsencrypt, complete with QR login and federated MatrixRTC calling with Element Call. The point is to show just how simple it can be to play with Matrix 2.0 and let folks experiment with the implementations (and help ensure any issues are flushed out before it gets baked into the spec for good!)

🔗Dept of Clients 📱

🔗Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Mauro Romito reports

• Knocking work is still going on, some other UIs have been implemented.
• Local echoes for media work has made good progress and will be enable in Nightly and development builds
• Share extension work is now also available in Nightly! Be sure to try it out!
• Finnish has been added to the available languages
• The app is now fully supporting XCode 16.1

🔗Dept of VoIP 🤙

🔗Element Call (website)

Native Decentralised End-to-end Encrypted Group Calls in Matrix, as a standalone web app

spaetz announces

Given the installation of an element call is still tricky (although there is a demo docker image now, rectifying this), here are my notes on how I installed element call (or rather its backend) on a Debian box using a mix of local services and a docker image: https://sspaeth.de/2024/11/sfu/

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for developing Clients, Bots, Appservices and Servers

Benedict announces

I released a new version of Trixnity. It now supports Ktor 3 including an up to 90% performance boost for IO operations.

🔗Dept of Services 🚀

🔗etke.cc (website)

Your matrix server on your conditions

Aine [don't DM] reports

🔗Synapse Admin Updates

A while back, we at etke.cc announced our Synapse-Admin fork, and this week we're excited to share more new features and QoL changes!

Prevent accidental user overwrites

The Synapse Admin API endpoint for creating new users and updating existing ones is actually a single Create or modify endpoint, that means you could accidentally overwrite an existing user when you don't mean to. This change adds a username availability check to the user create/edit form that will warn you if you're trying to "create" a user with a username that's already taken. If you accidentally ignore this inline warning message, you will see a modal window upon saving which will ask if you really intend to overwrite the existing user or not.

Why not just disable overwriting completely and only allow editing via the proper "edit user" UI? Because overwriting an existing user is the only user-friendly way to reclaim an erased user / MXID, so completely removing this feature is not a good idea!

Allow providing login form details via GET params

This is a small QoL change - now you could bookmark Synapse Admin URL with prefilled username and homeserver, e.g. https://admin.etke.cc/?username=matrixadmin&homeserver=matrix.example.com. Not a big deal, but nice to have.

Automatically check for updates

The Synapse Admin will do the same thing as Element Web by asking for static files in the background (every hour). If the index page is changed, it will show a notification with a button to reload the page - yep, another small quality-of-life improvement

Source code, admin.etke.cc (CDN version), say hi in the #synapse-admin:etke.cc

🔗Dept of Events and Talks 🗣️

🔗Fedora launch with Matrix Automation

Adrian says

This week, (basically right now) Fedora is running a Virtual event to commemorate the release of Fedora 41.

This year we're continuing to use Matrix as the chat platform for the event and my Pretix invite bot (https://github.com/fedora-infra/maubot-pretix-invite) has been slowly gaining improvements and has been fairly useful in bulk inviting people from this registration form to the Matrix rooms.

If you're able to sign up before noon Eastern, U.S. time, here is the link: https://rsvp.fedoraproject.org/releases/f41-latam-na/

If not, you can join the live stream on Fedora's YouTube channel or wait for the recordings to come out after the event.

Happy F41!

🔗Matrix in a Podcast

@mcnesium:matrix.org says

Last week a friend and I were invited to join this podcast show to talk about Matrix and what makes it different from XMPP. The show is a rather casual chat and in German, but HarHarLinks suggested to announce it here anyway.

🔗FOSDEM Fringe

HarHarLinks announces

Last TWIM we announced the Matrix Devroom at FOSDEM 2025. Two years ago, the Matrix community started a FOSDEM fringe event: The Matrix Foundation and Community Meetup and BarCamp (what a mouthful!). We are happy to announce to be continuing this series!

Like the last times, the fringe event will take place at the local hackerspace HSBXL hackerspace - but if you were there last time, ⚠️ be aware that they moved to a new location! ⚠️ You can find everything about it at https://hsbxl.be/enter/.

The event will start around noon and run until the evening. The last two times we were incredibly happy to find amazing sponsors that enabled us to provide free drinks and pizza for attendees, and we would like to stick to that tradition! If you are interested in sponsoring the fringe event, be it for pizza, drinks or another idea you have, please approach us on Matrix through the Community Events room, the Foundation Office room or by email at mailto:[email protected].

Beyond that, watch this space for more FOSDEM news to be announced!

🔗Dept of Interesting Projects 🛰️

🔗TARDIS - Time Agnostic Room DAG Inspection Service

Kegan reports

tl;dr - there's a new room DAG visualiser called TARDIS that can do real state resolution.

I've always struggled to properly understand how the state resolution algorithm works. I find it hard to understand the specification, and various blog posts didn't really make things click for me.

With that in mind, I recently spent some time working on a visualisation tool based on a project Matthew first wrote back in 2020 called TARDIS - Time Agnostic Room DAG Inspection Service. The backronym is surprisingly accurate. With this tool, you can step through "debugger-style" events in a room, seeing the shape of the DAG change. Originally this was all it could do, but I knew it could be so much more, so I set about prototyping the improvements I would make to it.

The main thing I wanted to add was the ability to actually perform state resolution on the DAG as it appeared at that point in time. Being able to do this would unlock a number of possibilities:

• Teaching: example DAGs could be loaded to explain how state resolution really works.
• Debugging: developers can load existing rooms into TARDIS to debug incorrect room state calculations.
• Testing: drop the UI and DAGs could be automatically loaded, resolved and asserted that the state at each event is correct, effectively making a server agnostic state resolution test suite.
• Performance: complex graphs can be repeatedly resolved, and the architecture would allow us to calculate and visualise how the algorithm is walking the DAG to see how efficient it is.
• Experimentation: any state resolution or DAG changes to the protocol could be visualised.

I wasn't given a lot of time to work on this, but I did manage to achieve the teaching/debugging aims. I didn't manage to add all of the teaching scenarios, so for now there's only ones explaining the various sort orders used in the state res algorithm.

What's more, this is all hosted so you can try it out without needing to install anything.

🔗How it works

TARDIS gets its data from JSON5 files. These files are intended to be hand-crafted, which is why they aren't pure JSON files. It includes a set of preloaded files to explain parts of state resolution. Each file contains a single "Scenario" which includes:

• The events in the room, already sorted in processing order.
• Annotations for when TARDIS steps into a given event, if any.
• Precalculated state at a given event, if any.

The scenario is then processed and rendered using d3-dag, just like Matthew's original prototype. To perform state resolution at the current event, TARDIS extracts the state sets for the event and makes a WebSockets connection to a "shim server". It is the shim server's job to perform state resolution. TARDIS comes with a Synapse shim, which imports the internal packages required to do state resolution, so it is using the same code paths as a real Synapse server. You can independently run a shim server locally, either in a virtualenv or as a docker container.

The magic happens when you press the "Resolve State" button which:

• Makes a WS connection to the shim server,
• Sends the state sets for the currently selected event,
• The shim server asks TARDIS for the event JSON for certain event IDs (this is why it uses WebSockets and not HTTP),
• The resolved state is returned to TARDIS,
• The resolved state is shown as green nodes on the graph.

State resolution relies heavily on event IDs, and event IDs are calculated fields. The JSON5 file format allows placeholder fake event IDs e.g $JOIN which are preprocessed into real event IDs. Rather than reimplementing canonical JSON, redaction algorithms, and room version handling in TARDIS, it uses gomatrixserverlib as a WASM package to handle this.

🔗What's next?

Unlocking the ability to automatically test state resolution would be a huge milestone, and complement (pun intended) other server-agnostic test suites I have developed in the past (Complement and Complement-Crypto). The test suite would read a JSON5 file to pull out the test DAG, which would have an additional key which has the assertions for that DAG, automatically talk the WS protocol to the shim server to get the resolved state for each event, and check it matches the assertions in the file. This would make it significantly easier for people to reimplement the state resolution algorithm correctly in non-Synapse homeservers.

Performance wise, the shim server is asking TARDIS for event JSON mid-algorithm. This provides a unique insight into the workings of the algorithm. Whilst the original drawings had the idea of "flashing" the nodes as they are requested, a more useful goal would be to just tally up how many times the shim server asks TARDIS for an event. This would allow TARDIS to visualise algorithmic complexity. We could then have a representative set of "realistic" DAGs and test changes to the algorithm for speed e.g given a DAG of n events, Algorithm 1 requests n and Algorithm 2 requests 2n therefore Algorithm 1 is faster.

🔗Matrix Federation Stats

Aine [don't DM] reports

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10361 Matrix federateable servers have been discovered by matrixrooms.info, 3181 (30.7%) of them are publishing their rooms directory over federation. The published directories contain 21664 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

🔗Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	girlboss.ceo	210
2	puppygock.gay	234
3	bark.arf.wf	251
4	awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay	254
5	transgender.ing	261
6	ncat.cafe	324
7	nexy7574.uk	345.5
8	constellatory.net	383
9	pissing.dev	563
10	nexy7574.co.uk	633