This Week in Matrix 2026-06-26

🔗Matrix Live - Andy is the new Thib

🔗Dept of Status of Matrix 🌡️

Thib announces

Please join me in welcoming andypiper to the Foundation. Andy will be your next Thib and will take over TWIM, Matrix Live, being the community liaison, organizing the conference, and much more. Welcome Andy!

🔗Dept of Events and Talks 🗣️

Thib says

🔗Last few days to submit a talk for Matrix Conf

The actual real extended deadline (for real) to submit a talk to Matrix Conf is on 30th June, that is next Tuesday as of writing. The competition is fierce, with more than double the amount of submissions than we can accept, but if you want to throw your hat in the ring, now is the best time!

🔗Dept of Working Groups 💪

🔗T&S R&D Working Group

andybalaam reports

The working group with the best name ("T&S R&D WG") is working on a new project, and we need your help! We want to make the lives of people running communities on Matrix easier, by writing a document called "How to Manage a Community Matrix Room".

It will cover basics like creating a room but focus on how to manage moderation: establishing policies, applying them, using moderation bots and policy servers to reduce spam and abuse.

If you've learned a little about how to manage a community Matrix room and you want to share your knowledge with other community organisers, jump into the T&S R&D WG Office room and volunteer! If you wish this document existed and want to read it, consider helping create it...

🔗Dept of Spec 📜

LogN says

🔗Is Presence Fixed Yet?

Nope.

Presence is notoriously one of the more expensive features in Matrix. Most large public deployments disable federated presence, commonly citing performance concerns. Current Matrix presence is fundamentally flawed: users receive presence information for all users they share rooms with, even if they are uninterested.

A group of independent community members, including maintainers of Continuwuity and the Nexus and Sable clients, are actively working on a series of proposals to improve on Matrix presence. This initiative, dubbed "Presence v2," just published its first MSC: MSC4495: Selective Presence.

This proposal aims to reduce federation load by only sharing presence with interested users, alongside giving room administrators an option to suggest whether presence should be shared between members or not. This provides both substantial performance and privacy improvements for Matrix users and homeserver operators.

There's much more to come! We are already working on drafting proposals related to batching, sliding sync, and much more. We could use your help: our current list of tasks is on https://ispresencefixedyet.com/. Review on MSCs and opinions are always welcome in our Matrix room: #presence-v2:zirco.dev.

Andrew Morgan (anoa) {he/him} 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:

• MSC4495: Selective Presence
• MSC4494: Membership-based invite blocking

MSCs in Final Comment Period:

• MSC4186: Simplified Sliding Sync (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Updates

Somebody pinch me! MSC4186: Simplified Sliding Sync has entered final comment period! Sliding Sync is a new method for clients to receive data (such as messages) from the homeserver that replaces the legacy, slower /sync endpoint. Notably, it improves startup times after first logging in from potentially multiple minutes to mere milliseconds.

This MSC has been very long-running, and is actually an evolution of a prior MSC, MSC3575, written all the way back in 2021.

Now that sliding sync will finally be landing in the spec, clients and homeservers are encouraged to implement it! This is also a pillar of the Matrix 2.0 work, so it's especially nice to see it land. Hats off to everyone involved in getting it over the line

🔗Dept of Bridges 🌉

Dark Collective says

🔗Nether Voice Bridge

I've been building Nether Voice Bridge, a bidirectional voice bridge between Discord voice channels and Matrix (MatrixRTC / Element Call) room calls. Talk in Discord and be heard in an Element Call — and vice-versa — with every speaker showing up as their own named participant on the far side. It's a single Rust binary on tokio, and one process can bridge many channel <-> room pairs at once.

The part I'm happiest with is that it's fully attributed in both directions. Matrix speakers appear in Discord as individually-controllable puppet bots named after the Matrix user, and Discord speakers appear in the Element Call as appservice ghosts with the right name and avatar — not one merged "bridge" blob. Mute state carries across both ways, and Discord users show up in the call as ghosts even before any Matrix user joins, so people can see at a glance who's waiting.

Both encryption stories are real rather than bypassed. On Discord the puppets are legitimate DAVE (MLS) participants, so audio actually decrypts; for end-to-end-encrypted Matrix rooms it derives Element Call's HKDF frame keys and delivers a per-ghost media key over Olm, so the homeserver can't read the audio. It also tidies up after clients that disconnect uncleanly: on homeservers without MSC4140 delayed events it reaps "phantom" call members so the roster doesn't fill with people who aren't really there.

Honest status — this is pre-1.0 and under heavy development. It's been built fast with lots of vibe coding and hasn't had an independent human code review yet, so expect rough edges and breaking changes. It runs day to day on my homeserver, and I'd love testers, bug reports, and especially anyone willing to look over the E2EE / key-handling paths. There are Docker images, .deb/.rpm packages, and a standalone Linux binary on the releases page.

Code, issues, and docs: https://nether.codes/dark/nether-voicebridge Come say hi or get help in #nether-voicebridge:nether.im

🔗Dept of Clients 📱

Slavi [etke.cc] says

Komai's v2026.06.21.0 is here and brings Element Call support, multi-room message forwarding and some other goodies 🎉

🔗FluffyChat (website)

The cutest instant messenger in the [matrix].

Krille - Christian K. reports

FluffyChat 2.7.0 has been released 🚀

Packed with a ton of new features, bug fixes and improvements, FluffyChat 2.7.0 has become even easier to use.

🔗A new onboarding

As FluffyChat uses end-to-end encryption while also offering multi-device support the user has always been asked to keep a long and hard to remember recovery key. Of course this has a lot of UX downsides as it is super easy to lose or forget the key, mix up multiple different keys and much more. Also users are often not in the mood to write it down and password managers are unfortunately still not that popular.

This time, we are trying out a slightly improved user interface paired with a new feature. You can now create your own passphrase, which is maybe easier to remember for some users. (I don’t. I still use a password manager.)

You can also now download your recovery key as a file (and import it when you log in on a new device). The restore page also got a major redesign and automatically starts a verification request to other connected devices. The code also got a major refactoring to be more stable.

We really hope that this makes the usage of this feature easier for everyone.

🔗Trust On First Use

End-to-end encryption is only secure if you are aware of possible man-in-the-middle attacks. But again it is hard to educate users to verify their communication partners and often this is not even possible. As a compromise and to increase the security standard, FluffyChat now supports Trust On First Use (TOFU). You will just be notified about the public master key of a user the first time you send an encrypted message to them. And you will be informed again, if this public key changes.

We really tried to find the best compromise of security and user experience here. You will be only informed once for every public key (so in the best case only once per chat). The dialog has the shape of a typical system permission dialog, so that we hope it looks somehow familiar and not scary to non-technical users. If you are not familiar at all with verification, you can even ignore it, but you are at least informed about the state of your encryption session.

🔗Timestamps everywhere

We got the same feedback again and again: Users want to see more directly what message has been sent when. And we have ignored the feedback for a long time in favour of not messing up the ui with dozens of timestamps.

With this new change we tried to find places in the timeline where we have empty space that we can fill anyway.

Messages can still be grouped together and then the timestamp is omitted. This happens only if the messages are from the same user on the same day and are not more than 3 minutes away from each other. You can still long press them to see the full time. We really hope this is a compromise everyone would be happy with.

🔗New way to use spaces

On mobile we have been playing around a lot with how we could improve the user experience for spaces. And with FluffyChat 2.7.0 we would like to try a completely new approach: An optional navigation rail on mobile!

The button to show the navigation rail will only be visible if you are participating in at least one space. So users who do not use spaces are not even bothered at all.

As this approach might be familiar for Discord users, while it is also completely optional, we hope that this attracts all user groups.

🔗Other changes

Besides this many bugs have been fixed. Notification now get cleared more consistently on Android. VOIP calls should now at least start on mobile (while they are still super buggy and barely usable). See more changes on GitHub.

That is all! We hope to see you at the Matrix Conference 2026. <3

🔗Element (website)

News about Element clients across platform boundaries.

Timo K. announces

Element Web is going to take a step towards the goal of "making MatrixRTC (Element Call) the default calling solution in our product". We want to inform you about the expected changes so this step goes as smooth as possible.

Specifically, this means Element Web is going to enable Element Call by default and remove the feature_group_calls config/feature flag.

This means users will get the option to start a "Legacy or Element Call" in DMs, and "Jitsi or Element Call" in group calls.

Transitions are always painful, and in a federated world it's even more complicated. Different deployments might want to move at different speeds.

We provide these three configurations for users and admins to control this transition on their own terms:

• "not so fast": using a new custom flag element_call.disabled = true allows you to still not expose Element Call. (It is a fallback for everyone relying on feature_group_calls=false.)
• "why so slow!": every user has the option to disable non-Element Call calls (old 1:1 and Jitsi calls) in the Voice & Video settings tab.
• "no, please don't clutter users with more options...": admins who know what's best for their users can use the existing element_call.use_exclusively EW config.json option to make this decision (disabling old 1:1 and Jitsi calls) for them. Their users will not see the toggle in the Voice & Video settings tab and will default to Element Call/MatrixRTC.

This is an early announcement of this change to allow everyone to prepare their config files. Expect it to land in the coming weeks.

🔗Dept of VoIP 🤙

🔗Element Call (website)

Native Decentralised End-to-end Encrypted Group Calls in Matrix.

Timo K. reports

This week we are making a small but significant change in Element Call.

With the next EC release, we will be using the multi-SFU approach for our video and voice calls. This is a novel approach introduced at one of Element's "How Hard Can It Be" hackathons.

The big advantage is that it mitigates any negotiation over which SFU users in a call connect to. Instead, everyone connects to the SFU associated with their homeserver. No negotiation required. If you want to subscribe to a stream from someone on a different homeserver, Element Call will connect to that SFU in subscribe-only mode. You still have the option to switch back to legacy mode (negotiate on one SFU) using the developer settings tab.

EC has been compatible with this mode for 6 months already, so the whole ecosystem should be updated by now and this should not lead to any incompatibilities.

Of course, this requires every call participant to have an SFU associated with their homeserver if they want to participate in a session. Since we already have checks in place so only users with an SFU can join a call, this should not make a difference for anyone already on the latest versions.

This is just one step towards adopting MatrixRTC (Matrix 2.0) in the matrix ecosystem:

• ✅️ Implement Matrix 2.0 MatrixRTC in all components (Synapse (sticky events, delayed events), EC (multi-SFU), JWT)
• ✅️ Use MatrixRTC with multi-SFU
• 🕐️ Transition to full Matrix 2.0 sticky events (impl on Synapse and EC are ready; we want to give the ecosystem more time to adapt to sticky events — this will probably happen after merging the Matrix 2.0 spec)

🔗Dept of Services 🧑‍🔧

MTRNord (they/them) reports

🔗Connectivity Tester

Version 0.5.1 has been released and deployed.

🔗New features

• Canonical json validation for the key endpoint
• We got contributions by Ma27:
• The server now loads CAs from the system store
• listen address is now configurable and unix domain sockets can be used
• Validation issues with X-Forwarded-For headers and webhooks have been fixed
• The backend now supports a cli style test system. You can learn more about it at https://github.com/MTRNord/rust-federation-tester/blob/main/README.md#cli-test-harness-matrix-federation-test
• The backend has better library support now
• The frontend now supports checking for the OIDC Authentication endpoints used by the new OIDC auth methods.
• The frontend has now added support for displaying data from the proposals: MSC4265, MSC4266 and MSC4439

As usual you can find the sources at https://github.com/MTRNord/matrix-connection-tester-ui for the frontend and the federation tester and backend code at https://github.com/MTRNord/rust-federation-tester/

You can also find it deployed over at https://connectivity-tester.mtrnord.blog?utm_source=twim&utm_campaign=0.5.1-release

🔗Matrix Federation Stats 📊

Aine [etke.cc] says

TWIM

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

As of today, 19432 Matrix federateable servers have been discovered by matrixrooms.info, 4174 (21.5%) of them are publishing their rooms directory over federation. The published directories contain 19080 rooms.

The most popular server software among the online servers is:

• synapse: 15339 (78.9%)
• continuwuity: 1566 (8.1%)
• conduit: 576 (3.0%)
• dendrite: 323 (1.7%)

Stats timeline is available on 📊 MatrixRooms.info/stats

🧩 Integrations with apps and servers | 💜 Support the project | 👉 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.

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	31a05b.net	235
2	usbpc.xyz	237
3	vibb.me	322.5
4	zirco.dev	372
5	victorewik.es	408
6	blahaj.club	496
7	vrkknn.net	708
8	shadowdrake.org	874
9	bartoostveen.nl	1128
10	cisnt.uk	1179.5

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.