matrix.org/content/blog/2023/11/2023-11-10-twim.md

315 lines
23 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

+++
date = "2023-11-10T19:30:00Z"
title = "This Week in Matrix 2023-11-10"
path = "/blog/2023/11/10/this-week-in-matrix-2023-11-10"
[taxonomies]
author = ["Thib"]
category = ["This Week in Matrix"]
[extra]
image = "https://matrix.org/blog/img/ietf118-mascot.jpg"
+++
## Matrix Live
{{ youtube_player(video_id="9ZUC5pdwbio") }}
<!-- more -->
## Dept of Spec 📜
[Andrew Morgan (anoa)](https://matrix.to/#/@andrewm:element.io) says
> 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:**
>
> * [MSC4075: MatrixRTC Call Ringing](https://github.com/matrix-org/matrix-spec-proposals/pull/4075)
> * [MSC4074: Server side annotation aggregation](https://github.com/matrix-org/matrix-spec-proposals/pull/4074)
> * [MSC4073: Shepherd teams](https://github.com/matrix-org/matrix-spec-proposals/pull/4073)
>
> **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 Updates
>
> The Spec Core Team (SCT) has been at IETF 118 for the More Instant Messaging Interoperability (MIMI) working group sessions, and things are looking good! We've spent the last 2 months working with several members on an informal Design Team to discuss, create, and experiment with a messaging protocol applicable for use in MLS-encrypted group chats. Originally this effort was sparked from Linearized Matrix, a condensed version of Matrix's Federation API, and has rapidly turned into a single document which describes the whole system.
>
> Over the next few weeks, the wider MIMI working group will be reviewing these documents to ensure they are up to the required standards for adoption. Adoption in the context of IETF is to simply say that any other drafts related to the subject are effectively rejected, as the working group will only work on the adopted document. It is not similar to FCP, where the draft is accepted - it can still be rewritten several times over.
>
> The documents up for review are:
>
> * Terminology (to be merged into architecture doc): <https://datatracker.ietf.org/doc/html/draft-ralston-mimi-terminology-03>
> * Architecture: <https://datatracker.ietf.org/doc/html/draft-barnes-mimi-arch-02>
> * Protocol (room-level operations): <https://datatracker.ietf.org/doc/html/draft-ralston-mimi-protocol-01>
> * MLS Delivery Service (group-level operations): <https://datatracker.ietf.org/doc/html/draft-robert-mimi-delivery-service-06>
>
> We, alongside some other members of the MIMI working group, are drafting up an informational document for how to use Double Ratchet crypto with the protocol document above. This is critical, because without this explicit migration path, existing gatekeeper messaging providers will not be interested in using this protocol. However, the MIMI working group is only capable of specifying Messaging Layer Security (MLS) as the encryption mechanism in its drafts.
>
> There's still quite a few other battles to be had, like content format, identifiers, etc, but we're fully engaged on those fronts still. Watch this space for updates, and for news on the protocol document progression specifically. We expect MSCs to start appearing Soon™ for many areas of MIMI.
>
> ### Random MSC of the Week
>
> The random MSC of the week is... [MSC3751: Allowing widgets to read account data](https://github.com/matrix-org/matrix-spec-proposals/pull/3751)!
>
> This MSC is fairly straight forward. If you're unfamiliar with Widgets in Matrix, they're a way to embed a webview inside of a Matrix client. Widgets can request certain information from the Matrix client they're embedded in through a Widget API; defined, yet unfortunately outside of the Matrix spec still.
>
> This MSC proposes adding a new _capability_ - permissions in the Widgets world - for widgets to request a given type of account data from the user. The example given in the MSC shows a widget attempting to query the globally-configured custom emoji of the user, perhaps in order to allow the widget to help visualise them.
>
> What's missing from this MSC IMO is the ability to also write to the user's account data. That would allow said example widget to actually manage a user's custom emoji collection. Of course, the user would be prompted before any such capabilities were granted.
>
> If that's interesting to you, check out the MSC at the above link!
## Dept of Servers 🏢
### Synapse ([website](https://github.com/matrix-org/synapse/))
Synapse is a Matrix homeserver implementation developed by the matrix.org core team
[dmr](https://matrix.to/#/@dmrobertson:matrix.org) announces
> This week Element [announced its intention to fork Synapse](https://element.io/blog/element-to-adopt-agplv3/) (plus other server-side Matrix components). Element's fork will be continue to be free (libre) software, licensed under the [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.en.html) ([summary](https://choosealicense.com/licenses/agpl-3.0/)). However, contributors to Element's fork will be required to sign a CLA. Please see the [element.io blog post]((https://element.io/blog/element-to-adopt-agplv3/) ) for motivation, and also the [Matrix.org blog post](https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite/) for the Matrix Foundation's point of view.
>
> Element and the Matrix.org Foundation are still discussing the finer details and the best way to implement this. Both of us want to minimise the disruption to Synapse operators and their end-users; we'll update the community as soon as we have more news to share.
>
> For Synapse itself, there hasn't been much room for code changes this week. We have deferred the promotion of the current release candidate [v1.96.0rc1](https://github.com/matrix-org/synapse/releases/tag/v1.96.0rc1) to a full release for the time being. We've found the time to squeeze in a little activity on develop, though. Myself and Patrick have been [working](https://github.com/matrix-org/synapse/pull/16590) [on](https://github.com/matrix-org/synapse/pull/16583) [various](https://github.com/matrix-org/synapse/pull/16609) [small](https://github.com/matrix-org/synapse/pull/16613) [performance](https://github.com/matrix-org/synapse/pull/16612) [fixes](https://github.com/matrix-org/synapse/pull/16616). As before, we don't expect these to have a huge impact, but they may help reduce spikes in memory and DB connection pool usage.
>
> Separately, Patrick has landed some [preparatory](https://github.com/matrix-org/synapse/pull/16615) [work](https://github.com/matrix-org/synapse/pull/16618) for using the [psycopg3](https://www.psycopg.org/psycopg3/) database driver. This is a small stepping stone to benefitting from the new [pipeline mode](https://www.psycopg.org/psycopg3/docs/advanced/pipeline.html#pipeline-mode), which we may be able to use to gain more performance in the future.
>
> That's all from us. As ever, we extend our sincere thanks to our community of server admins and users.
[Matthew](https://matrix.to/#/@matthew:matrix.org) announces
> Going forwards, Element is going to be releasing its work on Synapse, Dendrite & related server-side projects under the AGPLv3 license rather than Apache 2.0: <https://element.io/blog/element-to-adopt-agplv3>. Switching license to copyleft is a big deal, but we believe this is the right thing to do in order to keep Element's contributions to Matrix continuing sustainably for the greatest benefit of Matrix. The AGPLv3'd repositories will require contributors to sign an Apache [CLA](https://www.apache.org/licenses/contributor-agreements.html#clas) to Element, to allow Element to provide alternative licensing to commercial forks where necessary. See also [the coverage by The Register](https://www.theregister.com/2023/11/06/element_moves_to_agplv3/). Discussion is probably best routed to [#foundation-office:matrix.org](https://matrix.to/#/#foundation-office:matrix.org). -- Matthew (with his Element CEO hat on).
## Dept of Clients 📱
### Nheko ([website](https://nheko-reborn.github.io))
Desktop client for Matrix using Qt and C++17.
[Nico](https://matrix.to/#/@deepbluev7:neko.dev) says
> Nheko - The most curious bugs
>
> Continuing the polish work, this week my focus was on getting the calls to work reliably on the Qt6 version. This first started by the required gstreamer modules not loading at all. Once that was resolved, none of the ringtones were playing. After adding an audio output to the ringtone player (and troubleshooting my system audio for a while), it then turned out that only ever the second call in a room would ring. After resolving that, we got to one of the most fun bugs I had in a while: whenever a call ended, Nheko would just freeze. But not actually freeze! You still got notifications, the mouse cursor would change when hovering different parts, but the UI... would just always show a frame from shortly after stopping the call. And more interestingly, this only happened on Wayland. Well, it turns out gstreamer uses the same EGL display for rendering as Qt does and being a good citizen, it cleans up after itself. However, it doesn't remember, that it was actually just borrowing the display and since the display is not refcounted on EGL (but it is on WGL, GLX, etc), that rips out the rendering from between Qt and Nheko as such gets left holding a bag of new frames it can't hand out anymore. Anyway, we now just leak the display. This is inevitably going to bite us in the ass, but for now it should be fine, since we will be using that display until we stop the application anyway, hopefully, maybe. In any case I am sure this is not a problem!
>
> While working on the call stuff, I also got to pick up the ringtones I started creating a year ago. However... musescore wouldn't play them! Turns out the way it is using Alsa is not happy on my system, but if you just downgrade to version 3, change the audio backend and upgrade again, it will work fine. It also adds some weird silence, that I mostly cut off, but what can you do... If you want to give the new ringtones a listen, you can find them here: <https://github.com/Nheko-Reborn/nheko/tree/master/resources/media>. Maybe you can even figure out, what distro inspired me. Just don't be too harsh, I know almost nothing about music.
>
> Lastly, if you noticed that any profile you created would complain, that you got signed out: Nheko now again correctly recognizes, that you are signed out instead of always thinking you are signed in, but your userid, access token, homeserver name and EVERYTHING is invalid...
>
> Calls can be fun, huh? At some point I was very close to calling the Ghostbusters actually, but calls didn't work, so that was a bit of a conundrum... See ya next week!
### Neochat ([website](https://invent.kde.org/network/neochat))
A client for matrix, the decentralized communication protocol
[Tobias Fella](https://matrix.to/#/@tobiasfella:kde.org) reports
> A lot has happened in NeoChat in the last few weeks:
>
> * Too many UI improvements and bug fixes to name here.
> * James has continued his work on bringing complete spaces support to NeoChat. It's now possible to perform most space management tasks from NeoChat.
> * He's now working on supporting Threads, where so far, it's possible to send messages to a thread, with viewing a thread being work-in-progress.
> * Joshua has cleaned up NeoChat's config files, which now contain fewer things that aren't actually configuration.
> * I have improved NeoChat's handling of room replacements; you will no longer apparently loose rooms that have been upgraded if you haven't joined the new room yet.
> * On our path towards full end-to-end encryption support, we now have a settings page for security options. So far, it only contains some basic information about the device's keys.
> * The user information dialog will now show a QR code that can be scanned from a different device to quickly exchange contact information. This will soon be complemented by the corresponding QR code scanning part.
> * James has improved the layout of NeoChat's mobile mode.
> * Joshua has implemented a nicer style for showing blockquotes.
> * He also added support for switching to the dark mode on android (unsurprisingly, one of our most requested features!).
> * I've fixed our most annoying bug: When NeoChat fails to connect to the server of the last active connection on startup, it gets stuck in a loading screen forever. The only way of fixing that was to delete a line from NeoChat's config. Now, the user can choose on startup which connection to continue with. Further improvements to this will come in the next weeks.
> * Room access can now be configured to be based on space membership.
> * I have improved the implementation of the chat bar, which should now be less buggy and look a bit nicer.
> * On libQuotient's side, support for key backup and cross-signing is progressing nicely.
> ![](/blog/img/20231110-neochat1.png)
>
> ![](/blog/img/20231110-neochat2.png)
### Fractal ([website](https://gitlab.gnome.org/GNOME/fractal))
Matrix messaging app for GNOME written in Rust.
[Kévin Commaille](https://matrix.to/#/@zecakeh:tedomum.net) announces
> Fractal 5.rc1 is out!
>
> Fractal 5.rc1 is the first release candidate since the rewrite of Fractal to take advantage of GTK 4 and the Matrix Rust SDK, an effort that started in March 2021.
>
> The most notable changes since Fractal 5.beta2, that was released 2 months ago, are:
>
> * An awesome new look thanks to libadwaita 1.4
> * Read receipts tracking has been largely improved thanks to some upstream work in the Matrix Rust SDK
> * The same upstream work allows to have much better tracking of the activity in the rooms list
> * The full lists of read receipts and reactions on messages can be perused in popovers
> * Destructive actions like removing a message or leaving a room now ask for confirmation
> * The most noticeable performance issues and memory leaks were fixed to make Fractal run as smoothly as ever
>
> This list is far from complete and hides more enhancements, including bug fixes and new translations thanks to all our contributors, and our upstream projects.
>
> It is available to install via Flathub Beta, see the [instructions in our README](https://gitlab.gnome.org/GNOME/fractal#beta-version).
>
> As the version implies, if we don't find any major bug in the next 2 weeks, our next release should be the long-awaited Fractal 5 stable version!
>
> In the meantime, if you want to fix bugs, implement new features, or any other kind of contribution, you can get inspired by taking a look at our [issues tracker](https://gitlab.gnome.org/GNOME/fractal/-/issues) on GitLab. Any help is greatly appreciated!
> ![](/blog/img/20231110-fractal.png)
### Element X iOS ([website](https://github.com/vector-im/element-x-ios))
A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.
[Ștefan](https://matrix.to/#/@stefan.ceriu:matrix.org) says
> With another massive release out the door it was time to switch gears and tackle those little (and not so little) things that we didnt get a chance to do previously. As such, this week we focused on:
>
> * Refactoring some of our biggest classes and files
> * Fixing leaks in the notification extension
> * Enhancing the voice message recording experience
> * Tweaking the new in-app lock screen
> * Improving voice over throughout the app
> * Adding the test that were skipped
### Element X Android ([website](https://github.com/vector-im/element-x-android))
Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose
[benoit](https://matrix.to/#/@benoit.marty:matrix.org) says
> * Element X Android 0.3.0 is now released. We have pushed a version 0.3.1 on the open testing.
> * We take time to stabilise and polish the existing features, as well as doing some cleanup on the codebase.
### Element Web/Desktop ([website](https://github.com/vector-im/element-web))
Secure and independent communication, connected via Matrix. Come talk with us in [#element-web:matrix.org](https://matrix.to/#/#element-web:matrix.org)!
[Johannes Marbach](https://matrix.to/#/@johannesm:element.io) announces
> * Our stuck notifications project saw both a setback and a victory this week. First we had to back out an earlier fix as we've detected a regression caused by it in the release candidate. We have a re-fix ready that we're planning to land soon. Separately from this, we've managed to fix around 10 failing test cases by improving our handling of invalid receipts. As usual, check out https://github.com/vector-im/element-web/issues/24392 for more details.
> * Due to team changes our work on updating the room header and details UX has slowed down. We're currently regrouping to reassess what still needs fixing before a public release.
> * Final testing of our native OIDC implementation was delayed as we discovered a [bug](https://github.com/vector-im/element-web/issues/26466). In investigating it turned out that Element X has the same problem and that a follow-up on the spec level is required.
> * Work on streamlining our release process has continued and we're getting close to being able to make releases without dedicated hardware.
> * Lastly, we've also struggled with a few more CI issues around Cypress and our current usage of it that took away time from other activities.
## Dept of SDKs and Frameworks 🧰
### Rory&::LibMatrix
[Emma [it/its] ⚡️](https://matrix.to/#/@emma:conduit.rory.gay) announces
> These last few weeks have been fairly un-noteworthy (c2s/s2s http clients have internally been separated, fixed a concurrency bug)
> Due to declining mental health (unrelated), I do want to put out a **call for help**.
> I strongly believe in the Matrix community at large, and as such would love some help with anything I can get (documentation, examples, new features, code review or cleanup, ...).
>
> The code is publicly available at [cgit.rory.gay](http://cgit.rory.gay/matrix/LibMatrix.git/), and the main discussion room is at [#libmatrix:rory.gay](https://matrix.to/#/#libmatrix:rory.gay).
>
> The code is licensed under AGPLv3, anyone is free to contribute or extend as they see fit.
>
> Regards,
> Emma
### Trixnity ([website](https://gitlab.com/trixnity/trixnity))
Multiplatform Kotlin SDK for Matrix
[Benedict](https://matrix.to/#/@benedict:imbitbu.de) reports
> The next big release of Trixnity (4.0.0) is available for testing. I made some performance and memory usage improvements, cleaned up the API, added some convenience features and many more. I also added the [API docs to the website](https://trixnity.gitlab.io/trixnity). So check out the release candidate ([v4.0.0-RC1](https://gitlab.com/trixnity/trixnity/-/releases/v4.0.0-RC1)) and let me know if everything is working as expected.
### matrix-rust-sdk ([website](https://github.com/matrix-org/matrix-rust-sdk))
Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM
[Jonas Platte](https://matrix.to/#/@jplatte:flipdot.org) reports
> * [The `matrix-sdk` crate now provides a convenient API for secret storage!](https://github.com/matrix-org/matrix-rust-sdk/pull/2621)
> * Lots of small improvements in the crypto crate, mostly around backups
> * [A bug in back-pagination that could lead to busy looping was fixed](https://github.com/matrix-org/matrix-rust-sdk/pull/2812) (thanks Kévin Commaille!)
> * Some FFI improvements
> - [Don't leak `Client` instances](https://github.com/matrix-org/matrix-rust-sdk/pull/2815) plus [followup simplification](https://github.com/matrix-org/matrix-rust-sdk/pull/2821)
> - [Expose `NamedTempFile.persist()` through `MediaFileHandle`](https://github.com/matrix-org/matrix-rust-sdk/pull/2789)
## Dept of Services 🚀
### Matrix Rooms Search got room previews!
[Aine](https://matrix.to/#/@aine:etke.cc) reports
> The [#mrs:etke.cc](https://matrix.to/#/#mrs:etke.cc) project we're building at [etke.cc](https://etke.cc/), and its demo instance on [MatrixRooms.info](https://matrixrooms.info/) just got room previews in the form of [MSC3266](https://github.com/matrix-org/matrix-spec-proposals/pull/3266) implementation. With that update, client apps and services like `matrix.to` will show proper room name, topic, avatar, and joined members count when you share a matrix room alias using MRS instance.
>
> It looks like a simple feature, but under the hood a lot was changed, [numerous of Matrix CS API endpoints](https://gitlab.com/etke.cc/mrs/api/-/blob/main/openapi.yml) were implemented to support it.
>
> Try it yourself on [MatrixRooms.info](https://matrixrooms.info/) (even in Element apps!), check the [source code](https://gitlab.com/etke.cc/mrs/api), and say hi in the [#mrs:etke.cc](https://matrix.to/#/#mrs:etke.cc)
## Dept of Events and Talks 🗣️
[Thib](https://matrix.to/#/@thib:ergaster.org) reports
> Building on last year's success, the Matrix.org Foundation is excited to host a Matrix.org Foundation and Community devroom in person this year again at FOSDEM. Half a day of talks, demos and workshops around Matrix itself and projects built on top of Matrix.
>
> [The Matrix Foundation & Community devroom CfP is available here](https://matrix.org/blog/2023/11/fosdem-cfp/)
>
> ![](/blog/img/matrix-fosdem.png)
## Matrix Federation Stats
[Aine](https://matrix.to/#/@aine:etke.cc) says
> collected by [MatrixRooms.info](https://matrixrooms.info) - an [MRS](https://gitlab.com/etke.cc/mrs/api) instance by [etke.cc](https://etke.cc)
>
> As of today, `8127` Matrix federateable servers have been discovered by matrixrooms.info, `2052` (`25.2%`) of them are publishing their rooms directory over federation.
> The published directories contain `273884` rooms.
>
> [How to add your server](https://gitlab.com/etke.cc/mrs/api/-/blob/main/docs/indexing.md) | [How to remove your server](https://gitlab.com/etke.cc/mrs/api/-/blob/main/docs/deindexing.md)
## 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|maunium.net|217|
|2|beeper.com|238|
|3|nerdhouse.io|247.5|
|4|tcpip.uk|258|
|5|aguiarvieira.pt|322|
|6|shortestpath.dev|367.5|
|7|matrix.lukeog.com|368.5|
|8|chrrreeeeesss.com|505.5|
|9|rom4nik.pl|506|
|10|matrix.its-tps.fr|760|
### [#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|dendrite.s3cr3t.me|132|
|2|spqr2gang.com|160|
|3|frei.chat|164|
|4|nerdhouse.io|176|
|5|kanp.ai|237|
|6|herkinf.de|258|
|7|l1qu1d.net|272|
|8|fsky.io|275.5|
|9|kumma.juttu.asia|368|
|10|matrix.org|391|
## 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!