matrix.org/content/blog/2024/08/2024-08-16-twim.md

+++
date = "2024-08-16T18:00:00Z"
title = "This Week in Matrix 2024-08-16"
path = "/blog/2024/08/16/this-week-in-matrix-2024-08-16"

[taxonomies]
author = ["MTRNord"]
category = ["This Week in Matrix"]
+++

## Matrix Live

{{youtube_player(video_id="w3yq2Wz7XS0")}}

## Dept of *Status of Matrix* 🌡️

[Josh Simmons (he/they)](https://matrix.to/#/@josh:josh.tel) reports

> I’m pleased to report I've been busily onboarding the elected Governing Board members, and we've already started having important conversations about how we continue to move the Foundation forward to support the Matrix ecosystem.
>
> This week Matthew and I published a [blog post](https://matrix.org/blog/2024/08/heart-of-matrix/), significantly informed by community conversations and work with the Governing Board, on a process to define a governance framework for the projects we steward. Of note, in this post we are also drawing a line in the sand and making it clear: some projects, like the spec, test suites, SDKs, and shared cryptographic libraries, are so important that they require ongoing stewardship, under a permissive open source licence, by an organisation that is accountable to the ecosystem. To put a point on it: the Foundation will seek to fund and coordinate maintenance and development of core projects even if faced with a competing fork.
>
> Learn more in our blog post. We’d love to hear from you as we work together to update our project governance, and encourage you to reach out to [your representatives on the Governing Board](https://matrix.org/foundation/governing-board-elections/#elected-representatives) along the way.

<!-- more -->

## Dept of Spec 📜

[TravisR](https://matrix.to/#/@travis:t2l.io) 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:**
>
> - [MSC4178: Add proposal for unsupported 3pid error code](https://github.com/matrix-org/matrix-spec-proposals/pull/4178)
> - [MSC4177: Add upload location hints proposal](https://github.com/matrix-org/matrix-spec-proposals/pull/4177)
> - [MSC4176: Translatable Errors](https://github.com/matrix-org/matrix-spec-proposals/pull/4176)
>
> **MSCs in Final Comment Period:**
>
> - [MSC4156: Migrate server_name to via](https://github.com/matrix-org/matrix-spec-proposals/pull/4156) (merge)
>
> **Accepted MSCs:**
>
> - *No MSCs were accepted this week.*
>
> **Closed MSCs:**
>
> - [MSC4085: Improved CS-API Errors](https://github.com/matrix-org/matrix-spec-proposals/pull/4085)
> - [Proposal for improving authorization for the matrix profile API](https://github.com/matrix-org/matrix-spec-proposals/issues/3805)
>
> ### Spec Updates
>
> There's been a lot of progress on implementation for Matrix 2.0 objectives, allowing for spec maintenance to happen from the Spec Core Team (SCT). As those implementations progress, we expect more MSC reviews to happen in those areas. In the meantime we've been seeing a lot of clarification PRs (and MSCs!) to help make the spec better - thank you to those who have taken the time to improve the spec for everyone!

### Update on unauthenticated media sunset

[TravisR](https://matrix.to/#/@travis:t2l.io) says

> About 2 months ago we [announced](https://matrix.org/blog/2024/06/26/sunsetting-unauthenticated-media/) that we are sunsetting unauthenticated media on matrix.org, and we've been thoroughly impressed by how quickly everyone has been making the required changes! On matrix.org we've seen about 60% of requests update to the new, authenticated, endpoints and are on track to hit nearly 100% before August 28th, 2024. (with limited user-facing impact too! Media was a bit slow on matrix.org for a little while, but otherwise images and files have been travelling between users unimpeded)
>
> August 28th is coming up pretty quick though, and we're tracking some bug fixes and bridge releases which are due to land a bit too close to that date. To give a bit of room for follow-on bug fixes, and for those releases to happen safely, we're pushing the date by 1 week to September 4th, 2024. Other server operators are encouraged to evaluate if moving their own date is also a thing they should do.
>
> This means that on **September 4th, 2024**, any newly uploaded or cached media will *only* be accessible through the authenticated endpoints. Media uploaded before September 4th, 2024 will remain accessible on both the unauthenticated and authenticated endpoints.
>
> Thank you to everyone for working hard on getting the feature support in front of users, and for reporting bugs as they're found! If you're a developer and running into issues with authenticated media, let us know in [#matrix-client-developers:matrix.org](https://matrix.to/#/#matrix-client-developers:matrix.org) or [#matrix-homeserver-developers:matrix.org](https://matrix.to/#/#matrix-homeserver-developers:matrix.org) - we're there to help out.

## Department of OIDC 🔑

[Quentin Gliech](https://matrix.to/#/@quenting:element.io) announces

> I'll try to not add more confusion, but I think it helps to see MAS as a full rewrite of Synapse's auth system. We had numerous reasons to do that, one of which is to make it possible for other homeservers to benefit from all the work which happened there. The fact that it lives as a separate project (and for now, a separate process/docker image) is an implementation detail.
>
> I've quickly scrolled through the conversations which happened overnight for me and will try to answer a few concerns people have.
> Ultimately, I will try in the following weeks to clarify the MSCs, and update [areweoidcyet.com](https://areweoidcyet.com) accordingly, but those things take time, and I can't clarify everything at once right now.
>
> If you have any questions on the project, I'll redirect you to [#matrix-auth:matrix.org](https://matrix.to/#/#matrix-auth:matrix.org) to not spam the TWIM room too much. I'm also in the offtopic room if we feel like moving the conversation there instead.
>
> ### Authentication through the browser
>
> The main change with OIDC is that the primary way of authenticating isn't a login/password combo rendered within the client, but a round trip through a browser.
> This isn't a hard requirement, as OIDC is extensible, and alternative grants can be implemented, so we're not locking down ourselves to a single method.
> In fact, in MAS it is already possible to craft arbitrary tokens for automation purposes; it's not specced because we want to get this right and don't want to lock down the implementation.
>
> OIDC or not, we think that authenticating through the browser as the primary method is a good idea, for multiple reasons:
>
> - many credentials are domain-bound:
>   - we can't support WebAuthn/Passkeys without opening the OS browser on a webpage managed by the homeserver
>   - The same goes for CAPTCHA challenges, which are domain bound. They might work in iframes, but that won't fly with native clients
>   - to get a good experience with password managers, we need to have the credentials saved at the right origin. With the current approach, I suspect that many people have their `matrix.org` credentials saved on the `app.element.io` domain. This isn't great for trying out other clients
>   - smartcards/client certificates are domain bound too
> - going through the browser means the client never has the full credentials for a user. Right now, if I enter my `matrix.org` credentials in a malicious client, it will be able to:
>   - change my password
>   - deactivate my account
>   - logout other sessions
>   - remove email addresses from my account; add new ones
> - this also means we can't imagine any kind of restricted access to the homeserver. I would love to be able to give a client read-only access to a specific room for example, but because right now I can only login by giving my full credentials, there is no way to protect me from the client requesting more access that I want to give it
>  
> ### Why not extend UIA
>
> UIA already has a way to authenticate through the browser, the m.login.sso flow.
> This flow has been great to make MAS just work with any existing client which supports it.
> You can get a feeling of what it looks like by trying to login into the OIDC playground; use this homeserver: `synapse-oidc.element.dev`
>
> This flow looks very much like the standard OAuth flow:
>
> - the client opens the browser to some homeserver URL, with a redirect URI
> - the homeserver is responsible for doing whatever it needs to authenticate the user
> - once the user is authenticated, the homeserver redirects the client to the redirect URI, with a login token in the parameters
> - the client then exchanges the login token to get an access token
>
> So we basically redesigned the standard OAuth flow, but without any of the security mechanisms:
>
> - the login token is passed in the URL through query parameters, which means that the server hosting the client will see it
> - there is no protection to ensure that the client initiating the flow is the same client at the end of it
> - there is no way to go back to the client with an error
> - we know nothing about the client, other than its redirect URI
>  
> We honestly could have tried to fix the existing flow, but at this point we would basically have redesigned more of the OAuth specs.
> This is why we wanted to benefit from all the experience from the industry and follow all [current best security practices](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics), making sure the next generation of auth is as secure as we can make it.
>
> ### Client registration, or why we won't have the same problem as OAuth in SMTP/IMAP
>
> One common criticism of OAuth/OIDC, is that a client needs to be registered with the service.
> For example, if on GitHub you want to publish an app that interacts with the API, you need to register it manually through the interface, giving it a name, description, privacy policy URI, logo, etc.
> In the context of emails, this is notably a problem, because each email client developer has to go through all the common email providers, and get a client ID for each one of them.
> This is because Google, Microsoft, etc. are very keen to keep control over who can access their APIs, so they make developers go through a manual approval process to use their APIs.
>
> We can't do that with Matrix. We have an open ecosystem, where any client is supposed to be able to interact with any homeserver.
> This is why we leverage open dynamic client registration, which lets the client send its metadata (name, logo, various URIs) and get back a client ID.
>
> What we haven't yet figured out, is what is mandatory in terms of client metadata. We would like for users to have some trust over the client they are using, and make sure they are not getting phished.
> There are good opportunities here, like having the client sign their metadata, so that we can inform the user whether it's the same client they have been using, or a brand new one.
> It is hard to get the balance right between implementation complexity and security, as we're exploring uncharted territory: we're one of the first protocols to explore *open* client registration, and the IETF specs don't cover the semantics yet.
>
> ### API complexity
>
> The standard OAuth flow is not substantially different from `m.login.sso`, this is why we kept saying 'OIDC is straightforward, there are existing libraries'.
> Part of the complexity also comes from the fact that all the MSCs are not fully flushed out yet.
> But mainly, people then get confused on why we then haven't just implemented it within Synapse.
>
> The main reason is that we want to get account management right this time.
> If we move every user to use a browser redirect-based login, this means the homeserver now has to provide the UI to create your account, enter your credentials, change your password, verify your email address, etc.
> Synapse was never designed to provide those kinds of UIs: we have no localization management, no frontend toolchain, no cookie session management, etc.
>
> We also could not use an off-the-shelf OIDC IDP:
>
> - we need to keep compatibility with existing clients (through `m.login.sso`)
> - we need to be able to import existing users and sessions from homeservers
> - we need to tell the homeserver when there is a new account, new session, account deactivated etc. ; this is one notable area that OIDC/OAuth doesn't cover
> - we want it to be lightweight in terms of resource usage, so existing Java/Python IDPs are not a good fit
> - we need the user-facing parts to make sense in the Matrix world
> - we need the dynamic client registration to implement the right semantics
>
> This is why MAS exists, and why the code base is this big: we want to implement things the right way, and support all the use cases we had with Synapse.
>
> ### Just try it out
>
> Very sorry for this long post, this probably shouldn't be in the TWIM room, but because there was this big discussion yesterday, I wanted to clarify as much as I can now.
> I know I've been bad at communicating stuff around OIDC, I know how confusing this topic is.
> Looking back, I think we should have named this change 'Next-gen Matrix Auth', because so many people got confused with 'but we already have OIDC in Synapse'.
>
> I want to encourage people to try it out in the playground: we have an Element Web with native OIDC login enabled here: <https://element-oidc.element.dev>
> Just see how it feels: the way you register, the way you login, you manage your account, sessions, change your password, recover your password, etc.
> Also try with another client, which isn't OIDC-native; try on mobile, and experience your password manager just working.
> I think UX-wise, we've got a lot of things right.
>
> As mentioned earlier, I will try to clarify the MSCs. I will meet some of you at the Matrix Conference end of September, at which point I hope to be able to present a production-ready version of MAS, and a good plan for the future. Until then, please bear with me, all of this takes time and effort.
>
> If you're a client dev, please reach out in [#matrix-auth:matrix.org](https://matrix.to/#/#matrix-auth:matrix.org). Some behaviors are not yet well documented, so unfortunately the best way to move forward now if you want to implement native OIDC is to ask for help there.

## Dept of Bridges 🌉

### Mautrix Megabridges

[tulir](https://matrix.to/#/@tulir:maunium.net) reports

> mautrix-signal and mautrix-slack got their first megabridge releases! While the megabridge rewrites should mostly be invisible to users, there are some new features too, such as multi-account support. Read the full release post at <https://mau.fi/blog/2024-08-mautrix-release/>

## Dept of Clients 📱

### kazv ([website](https://kazv.chat/))

kazv is a convergent matrix client and instant messaging app.

[tusooa🏔️](https://matrix.to/#/@tusooa:uwu.lily-is.land) reports

> Aug 19 marks the fourth anniversary of the Kazv Project. Started as a [very small library](https://lily-is.land/kazv/libkazv/-/commit/15e5283d91a9de6d6dcb99d9aba7de54ec802205), once having been used as a [bridge bot](https://lily-is.land/kazv/matrix-tencent-forward-bot), it finally turned into a usable messaging app this year, and we got three developers in total including me. Thanks to those who have contributed code to the project, and those who have been supporting the Kazv Project.

## Dept of VoIP 🤙

### Element Call ([website](https://call.element.io))

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

[Robin](https://matrix.to/#/@robin:robin.town) says

> Last week we released [Element Call v0.6.0](https://github.com/element-hq/element-call/releases/tag/v0.6.0), shipping a big round of changes to how tiles in the call interface are laid out. The theme here is to get the basics right and improve the baseline usability, and we hope it shows! Notably:
>
> - Tiles are now always sorted based on their importance; presenters and speakers will naturally rise to the top. This replaces the ability to rearrange tiles via drag-and-drop. We're aware that this currently rearranges tiles unnecessarily in some situations, but we've got a plan to improve this.
> - In the spirit of getting the basics right, we've also removed the ability to expand tiles (for now?). We hope that the spotlight mode is able to fill this gap, now that it has fewer visual glitches and distracting animations.
> - We've heard loud and clear that the call interface could do with less negative space. Between the new layout algorithms and reduced margins, you should see some improvements here.
> - Lastly, the layouts on mobile devices have been redesigned from first principles to make better use of the limited screen space, for both small and large calls.
>
> As always, we welcome feedback, and look forward to the incremental improvements we can now make more easily with this stronger foundation. In the meantime we've also been working on picture-in-picture support for iOS—coming soon!

## Dept of Encryption 🔐

[Matthew](https://matrix.to/#/@matthew:matrix.org) announces

> Some potential security weaknesses in the libolm implementation of Olm were highlighted by Soatok this week: <https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/>.  As a reminder, libolm was [formally deprecated](https://matrix.org/blog/2024/08/02/this-week-in-matrix-2024-08-02/#vodozemac-website) a few weeks ago, although we’ve been recommending vodozemac since 2022.  We’re not aware of any way to actually exploit these weaknesses over the network, but we continue to strongly recommend developers to migrate to [vodozemac](https://github.com/matrix-org/vodozemac) (or fork libolm to add better primitives). We should have done a better job of explicitly deprecating libolm sooner (and/or improving its primitives) - but all of our focus has been on ensuring that vodozemac is excellent, to the detriment of libolm. Apologies to those who are now finding themselves expediting libolm replacement.
>
> It’s worth highlighting that all versions of Element, Element X, Fractal, iamb and other matrix-rust-sdk-based clients and their forks already use vodozemac, and platforms using matrix-js-sdk can also use vodozemac instead of libolm via `MatrixClient.initRustCrypto()`.

## Dept of SDKs and Frameworks 🧰

### Rory&::LibMatrix ([website](https://cgit.rory.gay/matrix/LibMatrix.git/))

.NET 8 matrix bot/client library/SDK

[Emma [it/its]](https://matrix.to/#/@emma:rory.gay) says

> No changes in main branch since last time, but there's been work in separate branches :)
>
> #### Changes (Non-main branches)
>
> - Some unfinished work regarding to authenticated media has happened on the dev/authenticated-media branch. This is very unfinished, but deprecates non-auth'd media routes, instead using them as fallbacks in auth-media-targeted functions.
> - Example bots have been removed from the LibMatrix repo, there's no point in keeping them as submodules, as they're still available on cgit.
> - Some work regarding E2EE has been done on respective branches, but for now is just limited to json canonicalisation.
> - I've been working on a new project under the umbrella, called ModerationClient for now, and it's respective LibMatrix branch contains some nice features, such as being able to store & replay sync requests (no more initial sync on startup!), better HTTP logging, better usage of async when initialising client instances, and some other fixes... TL;DR: More features, and now leaner and meaner!
> - This one deserves a point on its own, the moderationclient branch contains far more Synapse Admin APIs, and I hope to have them complete in the next few weeks!
> - I probably missed a few things...
> - Cloning the repositories should no longer fail :)
>
> #### RE: Funding
>
> I'm hoping to get liberapay working again somewhere this week or next week. Thanks stripe for getting me KYC-locked, needing do get a bunch of documents fixed to continue... /s
>
> ***And, as always:***
>
> - The code is available at [cgit.rory.gay](https://cgit.rory.gay/matrix/LibMatrix.git)!
>   - All contributions are more than welcome, be it documentation, code, anything! Perhaps, example usecases, bots, ...?
> - Discussion, suggestions and ideas are welcome in [#libmatrix:rory.gay](https://matrix.to/#/#libmatrix:rory.gay) (Space: [#mru-space:rory.gay](https://matrix.to/#/#mru-space:rory.gay))
> - Got a cool project that you're working on and want to share, using LibMatrix? Be sure to let us know, we'd love to hear all about it!

### Matrix Dart SDK ([website](https://github.com/famedly/matrix-dart-sdk))

Matrix SDK written in pure Dart.

[td](https://matrix.to/#/@td:technodisaster.com) says

> meep quick update, `matrix` 0.32.1 released since the last post, here's a summary:
>
> - authenticated media support. There might also be a newer release later to better handle servers where new endpoints are not registered.
> - `event.receipts` should now report both main and global thread receipts. No more can't see all receipts issues.
> - user profiles are now cached in db.
> - delete database file from disk on logout (previously we just cleared the db), with this you can now rotate the db encryption key per session.
> - And other bug fixes.
>
> That's it for now, until next time! bye byee 👋

## Dept of Bots 🤖

### Draupnir

[Gnuxie 💜🐝](https://matrix.to/#/@gnu_ponut:matrix.org) says

> [Draupnir](https://github.com/the-draupnir-project/Draupnir) is
> being supported with a grant from NLnet, with extreme gratitude to
> the [NGI Zero Core programme](https://nlnet.nl/core/).
>
> The details have been described in a blog post
> <https://marewolf.me/posts/draupnir/24-nlnet-goals.html>.
>
> This includes the goals of the grant and some context for the plan.
>
> We expect to make entries into TWIM more frequently from this point
> onwards. We'll also continue to provide updates in the development
> blog series that started back in January
> <https://marewolf.me/posts/draupnir/2401.html>.
>
> And as always, you can find us in
> [#draupnir:matrix.org](https://matrix.to/#/#draupnir:matrix.org).

### maubot-communitybot (simple community management bot plugin) [on github](https://github.com/williamkray/maubot-communitybot)

[wreck](https://matrix.to/#/@william:mssj.me) reports

> I've made some updates to my community management bot plugin and rolled in functionality from a couple other plugins i had, so i figure it's a decent opportunity to re-share it with the matrix ecosystem one more time...
>
> Do you run an online community in a Matrix Space? Wish there was some simple tooling you could use to prune inactive users or kick someone who is misbehaving, but are intimidated by setting up mjolnir/draupnir or feel like it's overkill for your needs? Check out the [communitybot](https://github.com/williamkray/maubot-communitybot) plugin for maubot!
>
> This plugin leverages the awesome [Maubot](https://github.com/maubot/maubot) framework to make management simple and accessible. It can be stacked with other plugins like [join](https://github.com/williamkray/maubot-join) and [gifme](https://github.com/williamkray/maubot-gifme) to give you a relatively full-featured community management interface through simple bot commands. Maubot's framework also means that it works in encrypted rooms, no decryption middleware required!
>
> The communitybot plugin can be used to track user activity in a non-invasive way (only storing timestamps of most recent activity, no other data is stored) in order to generate a report of inactive users based on timeframes of your choosing. The plugin can then be used to purge users who have been inactive for your specific timeline, or can kick or ban an individual user regardless of activity level (perhaps a malicious user spamming your rooms!). It is also capable of sending customized welcome messages when users join specific rooms, notifying an admin channel when someone joins, and even create rooms with sane naming, automatically inviting and setting administrator power levels appropriately!
>
> PRs are very welcomed, I have only my own use cases and limited testing for this plugin so I'm interested to hear what features people would like to see added!

## Dept of Events and Talks 🗣️

### Matrix Conference

[Josh Simmons (he/they)](https://matrix.to/#/@josh:josh.tel) announces

> **The first annual Matrix Conference is just around the corner!** We’ll be gathering in Berlin from **September 19 to 22**, featuring a BarCamp, two days of conferencing (check out the speaker lineup!), and a day of sprints and community meetings. Move quickly to get your tickets and travel arranged and we’ll see you there! Good news for folks beginning to experience FOMO: we’ll be livestreaming the event.
>
> - [Get your ticket](https://2024.matrix.org/register/#tickets)
> - [Volunteer to help](https://2024.matrix.org/volunteer/)
> - [Sponsor to help make the event happen](https://2024.matrix.org/sponsor/) and get your company in front of talent and decision makers
> - And don’t forget to [join the Matrix space](https://matrix.to/#/#matrix-conference-2024:matrix.org)!
>
> We can’t wait to see you there 🥳

### FrOSCon

[Nico](https://matrix.to/#/@deepbluev7:neko.dev) says

> **This weekend** is [FrOSCon](https://froscon.org/)! If you are in and around **Bonn** or if you want to go on a trip, come and check it out!
>
> Apart from all the other cool open-source stuff, there will be both a Matrix Stand and a dev room! Come talk to us!
>
> And if you just noticed you do something interesting with Matrix and want to share it, don't hesitate to apply for a short talk in the dev room. We still have room for some presentations and hearing about what others are doing always leads to fun ideas on what you can possibly build or use things for yourself!
>
> You can find the currently scheduled **program** for the dev room here: [Saturday](https://programm.froscon.org/2024/schedule/1.html#1), [Sunday](https://programm.froscon.org/2024/schedule/2.html#1)
>
> Short term changes may or may not be communicated in this Matrix room.
>
> The dev room is located in **C120**, so just stumble in and check it out!
>
> The stand should have T-Shirts and if we are very lucky, the stickers might arrive in time as well!
>
> You may even be able to ask some of the people elected for the Matrix governing board, what the board even is! And take a good look at those people if they look evil or trustworthy! Maybe you can even catch a shiny client or homeserver developer!

### ETHBerlin

[Matthew](https://matrix.to/#/@matthew:matrix.org) announces

> I was invited to do a keynote at ETHBerlin a few months ago on "The Challenges of Decentralised Communication", and the video just got published at <https://youtu.be/ZWlIHHYIafo>. It gives a slightly different higher-level take on the journey and mission of Matrix for those interested.
>
> {{youtube_player(video_id="ZWlIHHYIafo")}}

## Matrix in the News 📰

### Blender is moving to Matrix 🚀

[Matthew](https://matrix.to/#/@matthew:matrix.org) says

> Blender is moving to Matrix :) <https://devtalk.blender.org/t/blender-chat-migration/36155>

## Matrix Federation Stats

[Aine](https://matrix.to/#/@aine:etke.cc) reports

> collected by [MatrixRooms.info](https://matrixrooms.info/?utm_source=twim&utm_medium=matrix&utm_campaign=federation-stats) - an [MRS](https://gitlab.com/etke.cc/mrs/api) instance by [etke.cc](https://etke.cc?utm_source=twim&utm_medium=matrix&utm_campaign=federation-stats)
>
> As of today, `9758` Matrix federateable servers have been discovered by matrixrooms.info, `2981` (`30.5%`) of them are publishing their rooms directory over federation.
> The published directories contain `21904` rooms.
>
> Stats timeline is available on [MatrixRooms.info/stats](https://matrixrooms.info/stats/?utm_source=twim&utm_medium=matrix&utm_campaign=federation-stats)
>
> [How to add your server](https://matrixrooms.info/indexing/?utm_source=twim&utm_medium=matrix&utm_campaign=federation-stats) | [How to remove your server](https://matrixrooms.info/deindexing/?utm_source=twim&utm_medium=matrix&utm_campaign=federation-stats)

## Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by [pingbot](https://github.com/maubot/echo), a [maubot](https://github.com/maubot/maubot) that you can host on your own server.

### [#ping:maunium.net](https://matrix.to/#/#ping:maunium.net)

Join [#ping:maunium.net](https://matrix.to/#/#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|conduwu.it|191|
|2|doctoruwu.uk|205|
|3|awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay|293|
|4|girlboss.ceo|311|
|5|puppygock.gay|339|
|6|codestorm.net|356|
|7|littlevortex.net|440|
|8|constellatory.net|496|
|9|matrix.lukeog.com|650|
|10|amber.tel|722|

### [#ping-no-synapse:maunium.net](https://matrix.to/#/#ping-no-synapse:maunium.net)

Join [#ping-no-synapse:maunium.net](https://matrix.to/#/#ping-no-synapse:maunium.net) to experience the fun live, and to find out how to add YOUR server to the game.

|Rank|Hostname|Median MS|
|:---:|:---:|:---:|
|1|awawawawawawawawawawawawawawawawawawawawawawawawawawawawawawaw.gay|91|
|2|conduwu.it|99|
|3|girlboss.ceo|102|
|4|puppygock.gay|115|
|5|doctoruwu.uk|135|
|6|nexy7574.co.uk|175|
|7|transgender.ing|190|
|8|inu.is|243|
|9|reallyaweso.me|334.5|
|10|cwt.grin.hu|349|

## That's all I know

See you next week, and be sure to stop by [#twim:matrix.org](https://matrix.to/#/#twim:matrix.org) with your updates!