This Week in Matrix 2024-05-24

Matrix Live

Dept of elections 🗳️

Josh Simmons (away, back May 9th) says

Voting continues in the Governing Board elections, and we're close to having 100% turnout in every constituency except Individual Members! Check your email inbox for an email from noreply@opavote.com and please cast matrix-orgyour ballot today.

Separately, we're very pleased to welcome NeoChat and Cinny as our latest Ecosystem Members!

Do you have a community that's centered around Matrix? Or an organization that is aligned with our mission? Perhaps you're part of a company that profits from the use of Matrix. Whichever describes you, become a member today. Your involvement helps us ensure we get representative feedback and the financial support we need to continue stewarding the specification.

Dept of Spec 📜

TravisR says

We on the Spec Core Team (SCT) are trying a new format for this week's spec update - let us know if there's something you think is missing or could be improved in #sct-office:matrix.org!

This last week's focus was primarily spent on ensuring MSCs are moving towards Final Comment Period (FCP; the step before an MSC is accepted) at a healthy pace. Below are the MSCs which were on Tuesday's pings, and their current status:

• MSC3916: Authenticated media
  • Needs checkmarks from 6 more SCT members to enter FCP (started the week needing 6).
  • An outstanding thread regarding the federation download endpoint needs resolution.
• MatrixRTC needs help determining state key overwrite behaviour - this thread and this proposal need review.
  • The SCT was asked to weigh in, and left some comments in the area.
• MSC4115: Membership info on events
  • Needs checkmarks from 3 more SCT members to enter FCP (started the week needing 6).
  • Note: this MSC may be particularly interesting to client developers.
• MSC4138: More methods in CORS
  • Needs 1 more checkmark from the SCT to enter FCP (started the week needing 1).
  • Currently blocked on clarified text regarding its scope.
• MSC2781: Removing reply/edit fallbacks
  • Needs just 2 more checkmarks from the SCT to enter FCP (started the week needing 3).
  • Currently blocked on some clarified behaviour and process ordering.
• MSC2867: Marking rooms as unread
  • Needs checkmarks from 4 more SCT members to enter FCP (started the week needing 4).

Client and server developers are encouraged to review these MSCs in particular because they're on a path to being included in the next spec version. This doesn't have to mean implementing them, but if there's something which doesn't sound quite right in the proposal text then leave a comment on the diff to raise a concern. The SCT will take these comments into consideration as the MSC enters FCP - the 5 day countdown to ensure any last comments are considered before the proposal is accepted into the spec as stable.

Next week's focus will largely be the same as usual: we'll focus on unblocking Matrix 2.0 MSCs/features as a priority, and MSCs which require more checkboxes to enter FCP will be raised for prompt review. We're always on the lookout for MSCs ready for FCP, but can sometimes miss something - let us know in #sct-office:matrix.org if it looks like something is ready to go but hasn't caught our eye yet.

Dept of Clients 📱

Nheko (website)

Desktop client for Matrix using Qt and C++17.

Nico reports

For something completely different for once: Encrypted media files and unencrypted media files follow a bit of a different format (one contains encryption keys and an media id for an encrypted file, while the other one only has the id for the unencrypted file). The latter can be shown by most clients if they support encryption or if they don't. Encrypted media files are usually just supported by clients, which support End-to-End-Encryption (E2EE).

Now forwarding a message, which some clients support, can either copy the event content as is and send it into a different room or do some post processing on it (and maybe even add metadata). The problem is when that is combined with E2EE. A client which supports E2EE might decrypt the content, but would leave the media encrypted. If that is forwarded to an unencrypted room, the media might not be visible to some clients (without E2EE support), while when you just send the media file normally, it would be visible to those clients.

Because of that we explicitly blocked showing such media in Nheko to make it obvious, that something isn't right. Otoh, we don't even show an error message to the user, so we kinda messed up there, but that is besides the point. When you forward an encrypted image with Nheko into an unencrypted room, Nheko instead decrypts the image and reuploads it.

So now, why am I writing all of this? To be honest, I would just like to hear your opinions on it. Reuploading the media obviously takes longer and needs more bandwidth. On the other hand it is more compatible with clients, that don't implement E2EE and possibly don't intend to. A third option could also be to completely prevent forwarding encrypted media to public rooms to make accidentally sharing media in a decryptable manner harder. I would like to hear your thoughts on this, feel free to poke your head into #nheko-offtopic:nheko.im and share your thoughts!

Element X iOS (website)

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

Ștefan reports

It's been a pretty quiet week in iFruit company fanboys meet matrix devs land, just business as usual:

• we're putting the finishing touches on login with QR code
• added support for showing the native incoming call screen for ElementCalls started in DMs, and for showing notifications for the rest (2862)
• we started working on storing draft messages in between room switches and app restarts
• plus various other tweaks and fixes

Element X Android (website)

Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

ganfra says

• Release 0.4.13: Now available for open testing! Experience the newest features and improvements firsthand.
• Plain Text Editor: We've implemented a plain text editor based on markdown input for a seamless editing experience.
• QR Code Login: We're in the final stages of completing QR code login functionality, making sign-ins easier than ever.
• ElementCall Notifications: Work has begun on integrating notifications for ElementCall.
• Several Fixes: Various bug fixes have been applied to enhance overall performance and stability.

Dept of VoIP 🤙

Timo K. reports

We have not written updates here in a while. There are exciting things happening so its more then due to collect the news here.

Is there finally a MatrixRTC spec?

The VoIP team at Element has started the process of writing the MatrixRTC spec. There are some fundamental problems that need to be addressed before it makes sense to actually propose the MatrixRTC protocol. Those changes are somewhat entangled and boil down to:

• Track members with one state event per device. MatrixRTC allows each user to join with as many devices as they desire.
• Make memberships reliable. MatrixRTC membership is tracked by room state. Since room state cannot expire, clients need to manually update their membership state when they leave. So as soon as the client crashes, loses network, or the user ctrl+w's the call instead of hanging up, the call remains.
  • Currently there is a workaround to store a expire time inside the event, periodically update the event, and check if it's valid before using the membership.
• Spec call focus information, and expose it via the client .well-known.

There is already an implemented solution for exposing the SFU (Focus) with the Matrix server .well-known. For reliable memberships, we have a generalized solution with MSC4140 which proposes events that are sent after a timeout (that can be refreshed so there is a cheap keep alive/heartbeat mechanism) or on demand by pinging a new endpoint which allows to delegate the leave responsibility to the SFU. This further reduces traffic, really slow hearbeats are possible since the SFU can be trusted to detect a disconnect. This could solve scheduled messages, self destructing messages, and our reliable call memberships. (More details can be found in the MSC)

Finally, a draft for the MatrixRTC MSC was started. It is kept short to separate concerns, as calls are not the only possible MatrixRTC application. This means there will be a separate MSC just for Livekit and one for full mesh, a separate MSC for calls, and maybe other future MSCs for other MatrixRTC applications.

Element Call becomes easier to deploy

After the very successful BigBlueButton and ElementCall interoperability sprint at the BigBlueButton Summit (see the demo video), the community has picked up the work and is providing automatic docker build. So getting a running BigBlueButton, MatrixRTC (Element Call) setup will become easier!

Similarly a NIX package for Element Call and the required jwt-token-service is in the making!

New Tile Layout / Frontend refactor

Last but not least there is also a refactor of the element-call codebase. The frontend will use the MVVM pattern to make it much easier to write efficient and better tests. This project will at the same time tackle many long-awaited UX problems people have reported (such as the jumpiness in deciding who the active speaker is). A new Spotlight mode is introduced supporting pinning and a static "spotlight tile" where the content changes instead of shuffling the tiles around. This is the beginning of a bigger plan to present staged and listening participants. Stay tuned.

Dept of Bots 🤖

MatrixJoinLink

Dominik ⚡️ says

MatrixJoinLink is bot that allows the creation of invite links to non-public rooms in matrix. Some months have passed since I initially introduced the bot in TWIM. The bot addresses the challenge of being unable to invite individuals via a link to a non-public room or space.

In the latest release, I ensure that the users that interact with the bot always have the right permissions. Thus, if you use the bot, you should update to this version :)

How to use JoinLink

MatrixJoinLink simplifies the process of inviting users to non-public spaces. The easy way to use the bot:

1. Invite the bot into your room.
2. After the bot joined, use the command !join help to explore its features. Please note that the bot responds exclusively to users or servers configured by the bot owner.
3. To create a Join Link, kindly type !join link Demonstration_Link, and the bot generates a join link for you. Ensure that you and the bot have the permission to invite users.

Creation of Join Links (with Developer Mode Details)

Entering a Join Link Room

Feel free to test the bot and raise any issue using GitHub :)

matrix-word-counter

jjj333_p (any pronouns) says

Heya, just shouting out a little bot ive made recently to count the frequency that words are used in a given room. Check it out here!

Dept of Events and Talks 🗣️

FrOSCon 19

HarHarLinks announces

It can't be a surprise after Oleg's many years of effort that there will be a Matrix Community Event at the 19th FrOSCon in Sankt Augustin (near Bonn) 🇩🇪 on 2024-08-17 and 18 again! We are once more planning on a Devroom and Stand, and need your help! If you want to give a talk, hold a workshop, or just generally lend a hand and be involved, then follow the Call for Participation here to get in touch!

22. Gulaschprogrammiernacht (Website)

HarHarLinks says

If you are planning on attending GPN22 #gpn:entropia.de, the 22nd Goulash Programming Night, in Karlsruhe 🇩🇪 next week (2024-05-30 to 06-02), you're in luck! Matrix Community Events will be there and offering 2 Matrix workshops and looking forward to meet you!

Dept of Interesting Projects 🛰️

matrix-web-components

unonde announces

This week in mwc was added a docker-compose setup, and the APIs refactor, to finally be able to develop and use the web components with data from a local matrix homeserver (synapse, sqlite — see docs), and any homeserver.

This was tested with the user interactive authentication flow, while registering and login users (username/password/captcha/terms&conditions) as well as for managing user devices. Follow up on this will be to integrate the tests and CI/CD with a local homeserver (looking for help here if some have interest).

Also some breaking changes in the services/api.js files, to allow the baseUrl (homeserver's API address discovered by the .well-known file) to be setup in the constructor, and the API calls that could require it (registerUserKind).

The state of the project is still in early development, and subject to changes. For context, mwc is a learning experiment in vanilla web technologies, without any dependency, to try and layout the "components and methods" required to build a generalist matrix client. The objectives in the long run is to implement the building blocks (HTML custom elements, web-components), that any site or web-app could use for displaying and editing data in the matrix ecosystem. In this way the components are trying to be implemented following the specification as closely as possible (WIP), starting with "public unencrypted data" (a dependency will most probably be added for supporting encryption, as peer dependency, as for the HTML sanitizing features).

Notes

A few design decisions have been made, such as not using HTML/CSS classes or id, or adding default styles. The components can be imported in a site/app, and used similarely as native HTML5 elements such <img/> (here <matrix-image/>, or for example matrix-room etc.). The HTML attributes of the components should reflect their state (such as with <details open="true" />) and therefore allow styling and theming, with an API that should not change (as the version number grows, and as the project gets closer to match the spec's wording and features).

This feature is also pretty exiting for me because it could allow to start using mwc with data coming "from other sources"; such as "static JSON files", and use the matrix-spec to organize content (and maybe even allow syndication).

Feel free to join the discussion with feedback, ideas or comments #mwc.sctlib:matrix.org, see the /docs folder, the example page and client (with router) implementation (a router component will be added to mwc, using the URL Pattern API, and a temporary pollyfill dependency).

Matrix Federation Stats

Aine reports

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

As of today, 9430 Matrix federateable servers have been discovered by matrixrooms.info, 2857 (30.3%) of them are publishing their rooms directory over federation. The published directories contain 159532 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	doctoruwu.uk	197
2	girlboss.ceo	224
3	uwu.zemos.net	237.5
4	maunium.net	251.5
5	uwu.sulian.eu	319
6	conduwuit.aguiarvieira.pt	361.5
7	pavli.cc	403
8	shortestpath.dev	430
9	remi.im	438.5
10	littlevortex.net	442.5

#ping-no-synapse:maunium.net

Join #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	conduwuit.aguiarvieira.pt	75
2	doctoruwu.uk	87
3	girlboss.ceo	89
4	uwu.zemos.net	134
5	uwu.sulian.eu	145
6	aguiarvieira.pt	165
7	m00nlit.dev	184
8	dendrite.s3cr3t.me	197.5
9	neilalexander.dev	246
10	puppygock.gay	295

That's all I know

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