Matrix Live

Dept of Status of Matrix 🌡️

uhoreg announces

Messaging Layer Security approved by the IETF

The IETF has approved Messaging Layer Security (MLS) for publication. MLS is an end-to-end encryption method designed for group messaging. We have been working on integrating a variant of MLS into Matrix. Keep an eye out for demos in the near future.

Dept of Spec 📜

Andrew Morgan (anoa) [GMT-8] 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:

• MSC3987: Push actions clean-up
• MSC3985: Break-out rooms
• MSC3984: Sending key queries to appservices

MSCs in Final Comment Period:

• MSC3980: Dotted Field Consistency (merge)

Accepted MSCs:

• MSC3923: Bringing Matrix into the IETF process
• MSC2677: Annotations and reactions

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

Last week we mentioned that we'd have more to share this week about an easier API for accessing rooms in Matrix, and while it was our intention to have an MSC out by now, our priorities shifted slightly after the MIMI working group session at IETF 116. Some exciting news on that front though: our proposed easier API, called Linearized Matrix (apologies to all the mathematicians), is very much in line with what the working group is thinking about. So much so that we're going through the effort of writing up Matrix as a series of proper Internet-Draft specifications.

We don't currently have an up-to-date document which covers Linearized Matrix completely, but the short version is it allows a server to support individual rooms being linear arrays instead of DAGs. This doesn't prevent a DAG-capable server from joining the room and speaking full-blown DAG either, which is particularly important for compatibility with the existing Matrix network. Currently our efforts on Linearized Matrix are in implementation rather than documentation, though once things are slightly more stable we'll be getting an MSC out there for everyone to review more easily. Watch this space for news.

Following IETF 116, we have an immense amount of work ahead of us to define Matrix as the standard for interoperable chat, but we're well on our way on getting through it all. Namely, we're going around and mapping Matrix's functionality onto MIMI's concepts, defining Matrix as a proper IETF standard along the way. The expected outcome of this for the implementation authors of Matrix is a spec that is significantly easier to follow, finally.

For an idea of what's ahead, here's what the SCT will be looking at over the next several months:

• Linearized Matrix (implementation & MSC)
• Extensible Events (at least the core types) - this will serve as the basis for an interoperable messaging format in our IETF drafts
• Decentralized MLS & interoperability of crypto
• Clarification gaps and bugs in the current spec
• Pseudonymous user IDs and account portability
• Almost certainly something that was missed when writing this list

Considering the above list, the Matrix 2.0 objectives (sliding sync, OIDC, native VoIP conferencing, and faster room joins), and the core team's work around mentions, abuse reporting, and more, the SCT will be a bit busy. That said, if you have MSCs you think we should be looking at, let us know in the #sct-office:matrix.org room. We've recently started doing our weekly planning in that room too, which should help give an idea for what the SCT is expecting to look at each week.

Random MSC of the Week

The random MSC of the week is... [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix!

This MSC provides a mechanism for implementing Dynamic Client Registration (RFC 7591) for OAuth 2.0 between Matrix clients and homeservers. Without this, homeserver admins would need to manually configure OAuth metadata (Redirect URIs, application names, client secrets, and more) for every Matrix client that wanted to connect to the homeserver. Since that doesn't really scale in an environment that allows anyone to use any client they like, dynamic registration is critical! Dynamic registration allows clients to communicate this metadata to the homeserver at the login/registration step.

MSC2966 is part of a series of MSCs that add first-class OpenID Connect (OIDC) support to Matrix. You can see an overview of the related MSCs (here) and https://areweoidcyet.com/ for the latest progress on integrating OIDC into the Matrix spec!

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

Shay says

It's yet another Friday which means it's TWIM day. This week the backend team released Synapse 1.80.0. Notable highlights include:

• Fixed a bug in which the POST /_matrix/client/v3/rooms/{roomId}/report/{eventId} endpoint would return the wrong error if the user did not have permission to view the event. This aligns Synapse's implementation with MSC2249
• Fixed a bug introduced in Synapse 1.75.0rc1 where the SQLite port_db scriptwould fail to open the SQLite database
• Stabilized support for MSC3966: event_property_contains push condition
• Fixed a long-standing bug in which the user directory would assume any remote membership state events represent a profile change

and much more! You can learn more here in the release notes: https://github.com/matrix-org/synapse/releases.

Nico says

It has been quiet for a while, but mostly because I was busy or I felt like there was nothing worth talking about. But this time I fixed a bug, that I am actually so proud of, that I need to share it!

I regularly ban users in my rooms temporarily, if they are behaving like an asshole and I want to show them, that such a behaviour is not accepted, even if they usually contribute useful stuff. This tactic has in general worked pretty well and led to a noticeable improvement in the conversation culture in those rooms.

HOWEVER one bug has plagued us for ages and made this method way more destructive, than it should be. Everytime you banned someone on a single user homeserver or even just if they were the only user in the room from that server, you couldn't unban them. That is because there is no member in the room anymore to send the unban event to, so the other server never received an unban. Now, you might think, why is that a problem, you can join the room initially as well. And that was my thought as well, but considering that this bug was transferred to Github in 2016 and several people looked at it, I thought it was just way more complicated to fix. But since I hit this a few times a year and sometimes even multiple times a month, I spent a lot of time looking at the issue on Github. And I did see a few times, that there was a Complement test for it and every server passed that test, but only Synapse got blocklisted. So it couldn't be a fundamental problem...

So I thought, okay, this is annoying me regularly now, I will just get my hands dirty this time and fix it. Even if it takes me weeks or months. So I set up Complement, allowed the test to run on Synapse and watched it fail. Sadly, the complement logs were so long, that I couldn't find the actual error, but a few tries (and hours of runtime) later I got useful output, searched for the error message in synapse and looked at the code. It looked more complicated than Dendrite, all of the membership transitions were in 1 function instead of different ones. But apart from that, the obvious thing that jumped out was that Synapse verified against the room state if the user was allowed to join before checking if it was in the room and then attempting a remote join. Now usually it makes sense to verify the state locally, but not if you are not in the room, so I just moved the in room check up a bit and moved the local verification behind that check, so that the local state is only used for verification, if we are in the room. And it worked! So apart from indentation changes, this was a 1 line change in Complement, a 1 line change in Sytest (to make it fail on the right error) and a 3 line change in synapse (+ 50 lines or so of indentation changes...). This bug has been bothering me for ages and that was all it took to fix!

Now, bugs often look easy in hindsight, so don't use this to judge the Synapse devs or anyone. I just had the right motivation and a bit of luck finding the problem quickly (and help from Synapse devs). Possibly that change broke something else deep down in Synapse and we get to deal with demons soon. But I am happy for now!

Context links: https://github.com/matrix-org/synapse/pull/15323 https://github.com/matrix-org/synapse/issues/1563 (look, they both start with 15!)

Construct (website)

A performance-oriented homeserver with minimal dependencies.

Jason Volk announces

This week we focused on build system improvements. First, a huge thank you to Giovanni Bottaro for digging into the Ubuntu docker image and slimming it down to nearly half its size. It's still not as compact as our Alpine image, which is the smallest of any of the Matrix servers, but it's the one I would say is the most stable at this time. On the heels of this, I decided to overhaul the docker image matrix. Construct now offers several dozen combination docker images from Ubuntu 22.04, 22.10, Alpine 3.16, 3.17, gcc-10, 11, 12, clang 14, 15, and on arm64 with neon, amd64 with avx, avx2, and avx512.

Check out #test:zemos.net today!

Dept of Clients 📱

Nheko (website)

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

Nico reports

While I was mostly spelunking in CI land, some people did some really cool stuff!

Dtelsing implemented screenshare support on Wayland. This requires a proper pipewire + xdg-desktop-portal ScreenCast interface setup, but it means Nheko will properly ask your OS for a screenshare and your OS then gets to decide, what screen or window you are allowed to share. Especially considering how little documentation there is for this, I am pretty impressed how quickly they got this working and it seems to work quite nicely on the platforms I have tested, but feel free to test it yourself and report issues you find!

LorenDB tweaked the design of our switches, because they bothered him. Now, I have no eye for that, so I can't tell you what changed, but I assume people who can tell if something is pretty will be happy! Ryandesign also fixed the macOS build on case sensitive filesystems, a pseudonymous contributor added querying your own status message to the dbus interface and Nheko now linkifies improperly encoded matrix.to links again.

I think that is all, thank you all for the cool contributions!

Ement.el (website)

Matrix client for Emacs

alphapapa announces

Ement.el, a Matrix client for the GNU Emacs text editor and Lisp environment, has been released at version 0.8. Changes since the last release include:

Additions

• Command ement-create-space creates a new space.
• Command ement-room-toggle-space toggles a room's membership in a space (a way to group rooms in Matrix).
• Visibility of sections in the room list is saved across sessions.
• Command ement-room-list-kill-buffer kills a room's buffer from the room list.
• Set device_id and initial_device_display_name upon login (e.g. Ement.el: [email protected]).

Changes

• Room-related commands may be called interactively with a universal prefix to prompt for the room/session (allowing to send events or change settings in rooms other than the current one).
• Command ement-room-list reuses an existing window showing the room list when possible.
• Command ement-tag-room toggles tags (rather than adding by default and removing when called with a prefix).
• Default room grouping now groups "spaced" rooms separately.

Fixes

• Message format filter works properly when writing replies.
• Improve insertion of sender name headers when using the "Elemental" message format.
• Prompts in commands ement-leave-room and ement-forget-room.

Feel free to join us in the chat room: #ement.el:matrix.org.

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!

Danielle reports

• This week we’ve been making some great progress on all notifications fronts:
  • Our stuck notifications MSC is in progress, other work on these bugs is also on-going
  • The new notifications settings pages are designed and being worked on
  • The Intentional Pings MSC is also making progress; hoping to remove those pesky pings and allow us to stop using l33t speak!
• The cloud packaging improvements we’ve been making are nearly at an end - here’s to quicker, more reliable releases for our teams! 🎉
• Other product improvements include updates to the permalinks behaviour - try sending a matrix.to link to a message and let us know what you think.
• Our Product and Design teams have been taking a closer look at community PRs and are putting processes in place to reduce the time PRs are blocked by either department.

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Ștefan reports

This week in Element X on iOS:

• We’ve been fixing some issues with the timeline including updates to edits and messages that failed to send. You’ll also see the timeline ordering is more reliable also.
• Started to look into OIDC and how we integrate the new systems there
• Room details are making forward progress also and we’ve recently added “Ignore user” right to the DM details screen.
• We have also started working on the media upload flows and are making good progress

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

benoit says

On Element X for Android this week we:

• Introduced push notifications!
• We’re also looking at how we share translations across mobile platforms.
• And! The Room Details screens are continuing to grow; now you can see the room member list.

Release of Element Android get delayed because we want to fix an issue on the timeline first.

Dept of VoIP 🤙

Element Call (website)

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

Dave reports

We have a new Element Call release -> 0.3.6. This release principally contains a fix for a bug where participants could see video from other users but not be shown themselves (matrix-org/[email protected]). Feature wise you can use Element Call now for screen sharing only (without any media device attached to the computer). Here is the full changelog

Dept of SDKs and Frameworks 🧰

matrix-nio (website)

Paarth Shah announces

Hello all! I'm a new maintainer for this project, and I'm happy to say that we've released a new version, 0.20.2, already available on Pypi!

This release was mainly for upgrading dependencies and fixing bugs, (see the full changelog for details!) but I'm hopeful that I'll be able to dedicate some time to advancing some new features, and being able to help get new contributions rolling in!

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte reports

• Lots of additions to our bindings in the matrix-sdk-ffi crate
  • We've been working on adding bindings to the tracing library to matrix-sdk-ffi such that Kotlin or Swift code like ElementX that calls into the Rust SDK can benefit from the same structured logging infrastructure
  • We switched matrix-sdk-ffi to use the new sqlite crypto store
  • We added Client::ignore_user, Client::get_profile
• We fixed a problem where gappy syncs (which happen mostly when a process using the SDK is suspended and resumed a while later after many events arrived) would result in an invalid timeline item ordering
• We updated the read marker code for the timeline to never insert the marker at the very end

Matrix in the News 📰

Oleg announces

It became a habit to talk about the new Matrix stuff after FOSDEM in the German Podcast Das Duumvirat. 🙂

Feel free to check out the Recording (in 🇩🇪)

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.

#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.

That's all I know

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

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427 / GHSA-mwq8-fjpf-c2gr for matrix-js-sdk and CVE-2023-28103 / GHSA-6g43-88cp-w5gv for matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.

Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.

We found these issues during a codebase audit that we had previously announced in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 and CVE-2022-36060 / GHSA-2x9c-qwgf-94xr, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) says

MSC Status

New MSCs:

• MSC3984: Sending key queries to appservices
• MSC3983: Sending One-Time Key (OTK) claims to appservices
• MSC3982: Limit maximum number of events sent to an AS
• MSC3981: /relations recursion

MSCs in Final Comment Period:

• MSC3923: Bringing Matrix into the IETF process (merge)
• MSC2677: Annotations and reactions (merge)

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• MSC1796: improved e2e notifications

Spec Updates

The Matrix.org Foundation (mostly Travis) are beavering away preparing for the MIMI meeting at IETF 116 this weekend! This is part of our continual work to contribute to a IETF standard that can be used for interoperable messaging between gatekeepers (large companies in the chat world) under the EU's Digital Markets Act. See our earlier blogpost for more context on this topic.

In terms of our previous proposals on this subject; it turns out that implementing full-scale DAGs is a bit difficult, particularly when aiming to achieve interoperability on a short timeline. So we've been working on building an API surface for Matrix which makes rooms easier to access/implement in chat settings. We unfortunately don't have much to share today, but keep an eye on next week's TWIM for details 👀

Random MSC of the Week

The random MSC of the week is... MSC3480: Make device names private!

This MSC proposes hiding device names from any other user, while still allowing your own devices to see the names of the others.

You may question why device names being shown to other users was considered a good idea at all in Matrix. Initially these being public was really useful for verifying the devices of other users! Back in the days before cross-signing (where you only need to verify another user once), you had to verify every one of your friend's devices from every one of your own devices. It was an n * m problem, whereas if you had 4 devices, and your friend had 5, you'd need to do 20 verifications! And 4 more if your friend got a new phone!

So having device names back then were handy, but today any justification is moot and they're just a metadata leak. So we should get rid of them!

This MSC is blocked on a proven implementation. I actually wrote one up for Synapse a little while ago, and I plan to polish and merge it soon. Anyone else is free to do so in the meantime as well (just let me know first if you plan to do so in Synapse :).

Here's to improved privacy by default in Matrix!

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

Shay announces

The days just keep flying past and it's Friday again (how???). We here at Synapse have released v1.80.0rc2, filled with features and bugfixes. Some notable highlights are:

• Fix a bug introduced in Synapse 1.75.0rc1 where the SQLite port_db script
  would fail to open the SQLite database
• Fix a long-standing bug in which the user directory would assume any remote membership state events represent a profile change.
• Mirror images to the GitHub Container Registry (ghcr.io/matrix-org/synapse)
• Allow loading /register/available endpoint on workers

and much more! If you'd like to take a deep dive you can find the release notes here.

Construct (website)

A performance-oriented homeserver with minimal dependencies.

Jason Volk says

This week Construct introduced Peristalith Mode in an effort to fill the void left by last week's unfortunate demise of Dendrite's Polylith mode. Peristalith allows multiple instances of Construct to scale together in a hub-and-spoke configuration. This is a single-writer/multiple-reader strategy which uses the filesystem to share data between instances. In the long run, we're still working on Construct Cluster which is a homogeneous multiple-reader/multiple-writer design using Matrix itself for communication. For now, this is an improvement over simply not having any solution in case your deployment really needs to shed some load quickly. I'd like to thank Yan Minari for coming up with some Traefik configs for this and we're going to be spending the weekend playing around with it.

Let us know your needs for scaling your homeserver in #construct:zemos.net

Dept of Clients 📱

iamb

ulyssa says

iamb, a terminal-based Matrix client that uses Vim keybindings, had a new release this week. Release v0.0.7 includes:

• Room state events are now lazily loaded in the initial sync to help w/ memory usage and timeout issues
• New configuration options for adjusting log level and HTTP request timeouts
• Several bug fixes and improvements for displaying messages in the scrollback
• An iamb-git package has been added to the Arch User Repository (AUR)
• Release builds now use LTO

Nheko (website)

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

Nico says

0xDEADCADE fixed a few dialog windows, that would get a width of 0 on some window managers. Meanwhile tastytea made the scroll down button automatically refocus the message input.

The other work (apart from some cool work in progress stuff, was mostly minor improvements to communities. LcsTen made unjoinable and unpreviewable rooms in a community now hidden by default. This matches what the /hierarchy API does and as such what other clients show and since you have no way to fix it, why bother you with it? Admins of a community can still see those rooms and are suggested to remove them, since nobody will be able to join them. While the upsides generally outweigh them, there are a few downsides to this approach. Some users will never see some rooms in a community now and will have no way of telling you about the room not being joinable. Note that this only affects rooms added using a m.space.child event. The correct way to add a hidden room to a community, is by only setting a parent in that room. But many clients don't do that or rooms just naturally become unjoinable because of membership changes.

The last one is now properly handled in Nheko. Nheko will regularly update the join information for community rooms now. Each space child or parent event usually includes some routing information to figure out, what servers are in the room. If that server list is outdated, you will not be able to join the room, because none of the servers in the list know about the room anymore. Nheko now checks every 20 minutes if any of your space relation events haven't been updated in more than a week and if that is the case (and you have space edit permissions), it verifies that the routing information would still be the same if Nheko updated it. If it isn't, Nheko will write the new routing information into the state event. This is a bit of a compromise, since you might have more member changes in 7 days and the room can still become unroutable, but this is done to prevent to frequent updates if clients come to different results for the routing information. This should improve the long term experience of communities by a lot, since you won't have them randomly break anymore.

I talked a lot about routing information now. The spec actually has a section for how to calculate that: https://spec.matrix.org/v1.6/appendices/#routing. Nheko now implements that algorithm slightly more correctly, but we still don't implement everything. This should make room links look more reasonable and prevents some of the problems talked about in the previous section. Some parts I haven't implemented yet though. Nheko does not ignore ip address only servers (for now). And we also decided to ignore the powerlevel >= 50 requirement and changed it to users that have a powerlevel >= max(events_default, state_default). This is done, because the spec handwaves away concerns, that rooms might have non-default powerlevels, but I am in a lot of those and it would be annoying to me.

I guess this was a bit of a more technical update this time, but maybe it had some interesting bits. I spent a lot of time the last weeks fixing stuff in Qt, profiling memory usage as well as code size and others are working on cool stuff as well, so stay tuned for next week. :3

FluffyChat (website)

Krille reports

Small update from FluffyChat:

• I'm currently finalizing the long requested "Jump to last read message" feature (see screenshot)
• A workaround for Linux arm64 not building has been applied so we will soon publish arm64 on Flathub again (snap has to wait a little bit longer)
• FluffyChat v1.10.0 is now in all stores
• Next version of FluffyChat will display a read marker in the chat
• FluffyChat will now use a SliverList widget for the chat list page, which means that the search bar will disappear on scroll down and pop up on scroll up like in other Material3 apps
• Some work on cleaning up the huge CI scripts have been done to make contribution Merge Requests more easy

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Ștefan says

• Yet another packed week in iOS land. Starting with ElementX we have made great progress on structured logging, migrating our translations to Localazy, adding support for ignoring users and the DM creation flows. We have also fixed offline mode, UI tests and added form styles to Compound. In the background we’ll still working on tracking down our more complex bugs, adopting async-uniffi and improving our developer experience
• In Element iOS there’s a new release out, with new and improved links for users, rooms and messages and we released a hotfix for a regression which affected a small proportion of users at one point this week.

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

Jorge Martín says

• This week the Element X team for Android have been working on setting up push notifications, permission management, shared localization with iOS and independent releases for the Rust SDK for Android and the Crypto Rust SDK. There have also been work around polishing the session verification and server selection flows and creating a new room details screen.
• On Element Android the way pills are rendered in the timeline has been improved to fix issues with very long pills.
• We are looking for an Android developer to join our team to work on Element X. If you’re interested, you can find more info here or reach out to @johannesm:element.io.

Dept of SDKs and Frameworks 🧰

Elm SDK

Bram reports

We're getting closer and closer to a version 1.0.0! Today, I hacked a a quick and ugly demo to show off Elm's capabilities. The website lets you log in using an access token and the homeserver's base url, after which you can send and receive cookies 🍪 to your friends. :)

Since last week, the SDK now supports login functions at all spec versions, and banning users is now supported as well. If you're curious about the last few struggles to build a rigorous SDK in a functional language, join the discussion at #elm-sdk:matrix.org to keep track. :)

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte says

• Update account_data when creating a new dm room
• Fix: Remove event contents from (Sync)TimelineEvent Debug impls
• Added an API for ignoring a user
• Support getting push actions of decrypted events
• More improvements around Sliding Sync, with a focus on testing

Dept of Bots 🤖

flip-matrix-bot (website)

A Matrix bot for the Friendly Linux Players community.

HER0 says

Events can now have a game server and password associated with them, and these are displayed in various places. For example, you can see this on the web page for the upcoming Arma 3 event this weekend: https://friendlylinuxplayers.org/events/d0a29709573b0fe7

Dept of Interesting Projects 🛰️

Half-Shot reports

The next generation of Integration Managers is finally here!

(with a familiar bridge backing it!)

I am once again happy to report on our latest integrations work at Element. A couple of weeks ago you heard from me and Justin on the new Integration manager that we've been working away on and we're pleased to announce it's now LIVE and has replaced our old IM, Scalar.

Alongside the new IM, we've replaced the old Go-NEB powered bots with their matrix-hookshot equivalents. This means you can now press buttons to migrate yourselves off the old bots. As an aside, all the changes we've made to hookshot to scale up for the big release are of course landing in the open source project, should you wish to spin up your own bots instead. We're hoping that the ability to now embed our all-powerful config widgets directly into the integration manager will make it easier to add new features to these already-powerful bots.

If you encounter any issues, please post an issue in https://github.com/vector-im/element-integration-manager/issues where we will be happy to assist!

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.

#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.

That's all I know

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

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) reports

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:

• MSC3980: Dotted Field Consistency
• MSC3979: Revised feature profiles
• MSC3977: Matrix as a Messaging Framework (IETF/MIMI)

MSCs in Final Comment Period:

• MSC1796: improved e2e notifications (close)

Accepted MSCs:

• No MSCs were merged this week.

Closed MSCs:

• MSC3978: Deprecate room tagging

Spec Updates

The Spec Core Team has started to publish their weekly list of MSCs to focus on reviewing in the Office of the Spec Core Team room. The list consists of the MSCs that are ready for immediate review, and would most help advance the Matrix protocol on any given week. This used to happen internally (they started out as weekly ping by a bot, and then slowly became curated by our resident human, Travis). But the idea to publish the list both allows people to easily follow along with what they're doing on a weekly basis (much like these posts, but in real time!), as well as helps push subsequent discussion to public channels.

Otherwise, Travis continues to be hard at work integrating Matrix into the IETF process. MSC3923 - initially published in November 2022 - was proposed for FCP this week (and has nearly passed!). Additionally, MSC3977 was published this week and talks about how Matrix is a great fit for the goals of the IETF's MIMI working group.

This is all ahead of the IETF 116 event which starts on March 26th. The Matrix.org Foundation will be attending remotely.

Random MSC of the Week

The random MSC of the week is... MSC3735: Add device information to m.room_key.withheld message!

This MSC proposes adding a new field, from_device, to m.room_key.withheld messages. This to-device message type is used to inform devices why a megolm session was not sent to them after they requested it.

Devices can request megolm sessions from multiple devices at once, but upon receiving a m.room_key.withheld message from one of them is currently unable to tell which of the devices responded with that message.

The proposed from_device field should not be added to m.room_key.withheld messages that are sent outside of key request flows.

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

Shay reports

Friday, Friday, Friday, also known as TWIM day. We here at Synapse have another release for you: Synapse v1.79.0. As always it is packed with features and bugfixes. Some notable highlights include:

• Added media information to the command line user data export tool.
• Added an admin API to delete a specific event report
• Added support for knocking to workers
• Fixed a bug introduced in Synapse 1.79.0rc1 where attempting to register a on_remove_user_third_party_identifier module API callback would be a no-op
• Fixed a long-standing bug where a URL preview would break if the discovered oEmbed failed to download

and much more. Feel free to take a deep dive in the release notes and have a happy Friday!

Dendrite (website)

Second generation Matrix homeserver

Till says

This week we released Dendrite 0.12.0, which marks the end of polylith/HTTP API mode.

Features

• The userapi and keyserver have been merged (no actions needed regarding the database)
• The internal NATS JetStream server is now using logrus for logging (contributed by dvob)
• The roomserver database has been refactored to have separate interfaces when working with rooms and events. Also includes increased usage of the cache to avoid database round trips. (database is unchanged)
• The pinecone demo now shuts down more cleanly
• The Helm chart now has the ability to deploy a Grafana chart as well (contributed by genofire)
• Support for listening on unix sockets has been added (contributed by cyberb)
• The internal NATS server was updated to v2.9.15
• Initial support for runtime/trace has been added to further track down long-running tasks

Fixes

• The session_id is now correctly set when using SQLite
• An issue where device keys could be removed if a device ID is reused has been fixed
• A possible DoS issue related to relations has been fixed (reported by sleroq)
• When backfilling events, errors are now ignored if we still could fetch events

Other

• ⚠️ DEPRECATION: Polylith/HTTP API mode has been removed
• The default endpoint to report usages stats to has been updated

If you have a Dendrite homeserver, staying up-to-date is highly recommended so please upgrade when you can. Otherwise, if you want to play with Dendrite without having to set up your own infrastructure, the dendrite.matrix.org homeserver is open for registration (upon completion of a CAPTCHA, so you may need to register using Element Web).

As always, please feel free to join us in #dendrite:matrix.org for related discussion.

Construct (website)

A performance-oriented homeserver with minimal dependencies.

Jason Volk says

Construct is inching closer toward public-registration safety for its upcoming 1.0 release. This week I'd like to thank tiix for helping me fix a bug in the registration availability checker, and @dynfox for dropping some documentation for how to launch Construct dockers with certbot.

I'd like to thank @qg:schildi.chat and @bgiovanni for helping me hunt down an elusive auth-rules divergence between Synapse and Construct. This bug affects Synapse users who have been kicked from a room before the summer of 2022 by an admin who runs Construct. After Synapse 1.62, those users are not able to rejoin that room -- ever. This was due to a bug which added unnecessary m.room.join_rules to the auth_events which is no longer accepted by Synapse after that version. This is now fixed on our end going forward, but fixing this retroactively is something I'll be working on over the weekend. I'd like to send my regards to Philantrop 🏳️‍🌈 who first brought this to my attention and is still trying to get back into #construct:zemos.net even at this very moment. Don't worry, we haven't forgotten you! 😁

Construct has over five years of battle-tested experience federating at scale from the very first days of Matrix. If you're looking for an alternative to Synapse to run on a cheap host: less than or equal to 100% CPU usage is our guarantee or your money back. I use it every day at

#construct:zemos.net

Homeserver Deployment 📥️

Helm Chart (website)

Matrix Kubernetes applications packaged into helm charts

Ananace says

My Helm Charts continue to be updated regularly, now offering an improved first-install experience for Synapse through running the original signing key generation as an install hook. The sliding sync proxy is now also packaged as a Chart for those wanting to spin one up to test with.

Dept of Bridges 🌉

Vermicularis (Website)

mijutu says

Vermicularis, the unidirectional Päikky to Matrix bridge, now forwards pictures too.

matrix-hookshot (website)

A multi purpose multi platform bridge, formerly known as matrix-github

Half-Shot says

Hookshot 3.0.0 storms in and demands attention

Howdy folks, another big release for you coming up. So you remember how last week Justin and Myself came onto Matrix Live to talk about the new bridge widgets and show off how sleek and snappy they are? Well, Hookshot is also getting some updates of a similar flavor. The more observant of you may be starting to notice a pattern of us tarting up our public integrations. Something might well be on the horizon very, very soon :)

In the meantime, here are the latest changes for Hookshot 3.0.0:

• Add support from migrating go-neb services to Hookshot (#647)
• Implement grant system to internally record all approved connections in hookshot. (#655)
• Add support for logging into GitHub via OAuth from bridge widgets. (#661)

and a bunch of other changes too!

You'll notice we're migrating to a grant system for approving connections, which is why this is considered a breaking major release. Please check the notes before updating and give us a quick message if you have any issues or concerns.

And with that, I wish you all a great weekend!

Dept of Clients 📱

Chooj (website)

Farooq reports

In the chooj repository we haven't got any new commit. However, in KaiUIng's which is an important dependency of chooj(not the fattest one, however!) we had several new commits. Mainly, I am trying to use Typescript instead of Javascript for better productivity and catching bugs before production.

Fractal (website)

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

As predicted 3 weeks ago, Fractal 4.4.2 has been released and is available on Flathub.

As a reminder, there are no new features, but it makes Fractal compatible with newer versions of our dependencies. Big thanks to everyone who tested the beta version and feel free to uninstall it.

In another news, let's talk a bit about Fractal 5…

We have finally implemented one of the most annoying missing features: sending read receipts and updating the fully-read marker. What is doubly great about this, is that we are now only one feature away from being regression-free compared to our stable release (and a merge request is opened for the last one)!

This means that a beta release is around the corner, but we also have serious performance issues to resolve first. We hope that switching to the new store backend currently developed in the Matrix Rust SDK will fix some of it, but we still need to investigate properly how we can improve the situation.

That's all for this week, don't hesitate to come say hi in #fractal:gnome.org. If you would like to help us, take a look at our newcomers issues (and don't forget to read our CONTRIBUTING.md first).

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!

Danielle 🪖 announces

• We’re working on the remaining pieces related to sunsetting Gitter.
• Investigations on Stuck Notifications also are continuing and we think we’ve cracked part of the nut - an MSC coming soon!
• Our general work on Notifications is also still progressing with some critical MSCs starting to complete their final comment period

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Manu reports

• On Element X this week we’ve been focussed on creating the UI for new chat, and other improvements to the DM flow.
• We’ve also be adding mentions and slash commands to the new text editor and making improvements to permalinks, so tagging people in the timeline should be even easier!

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

benoit announces

• This week the Element X team for Android have been setting up the foundations for push notification, the room list, and translations
• We’ve also been adding support for mentions and slash commands in the new text editor
• Permalinks and pillifying MXIDs have also been getting improvements too.

Dept of Non Chat Clients 🎛️

mnotify (website)

stefan announces

mnotify got a few updates:

• there is now a matrix channel: https://matrix.to/#/#mnotify:hackbrettl.de
• it can now also send emote mn send --emote (in element: /me command) and notice mn send --notice (e.g. someone left a room or anything else changed) messages
• information about the current login (e.g. the homeserver url or the token) can be printed with mn homeserver or short mn hs, to ease the development of scripts which use curl for special requests
• typing notifications can be send with mn typing
• currently I am working on joining rooms

Circles (website)

E2E encrypted social networking built on Matrix. Safe, private sharing for your friends, family, and community.

cvwright reports

We just published a new Android beta of Circles, the E2E encrypted social network app.

Updates in the v1.0.10 release include:

• New feature: User profiles as Spaces, with an updated "People" tab showing the people who you're connected with
• New feature: Scan a friend's QR code to connect with them (ie to knock on their profile Space room)
• New feature: Notifications using Sygnal or ntfy
• Bugfix: Better detection of .well-known server information

Interested users can get this latest beta from all the usual sources:

• Our F-Droid beta repo: https://circu.li/fdroid/repo/
• Google Play: https://play.google.com/store/apps/details?id=org.futo.circles
• Source code: https://gitlab.futo.org/circles/circles-android/-/tags/v1.0.10

Dept of SDKs and Frameworks 🧰

Elm SDK (website)

Bram says

The Elm SDK has reached an unofficial alpha version! It can be downloaded and used for testing purposes. Now that the core has been finished, the exposed modules Matrix, Matrix.Room and Matrix.RoomInvite are available with the following features:

• Automated login & sync
• Joining / leaving rooms
• Accepting / rejecting invites
• Receiving the latest events of a room

Before publishing a version 1.0.0, I aim to implement the following features:

• Automated login & sync for spec version v1.1 and legacy versions r.0.0.0 - r0.6.1 using sync v1
• Room membership manipulation (invite, kick, ban, knock users/rooms)
• A few QOL functions to explore a room's state

You may expect these in the next few weeks. On to a version 1.0.0!

Repo: https://github.com/noordstar/elm-matrix-sdk Public room: #elm-sdk:matrix.org

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte reports

• This week, a lot of functionality was added to our foreign language bindings for Swift and Kotlin:
  • Creating rooms
  • Updating the room topic and avatar
  • Downloading media files to disk
• We also added a guide for contributing to those bindings
• We added more detailed event verification states
• We added a convenience method for setting the room name (but not for the bindings yet)
• We fixed another set of bugs in Sliding Sync
• We fixed a small bug around OIDC
• We added support for highlighted messages in the timeline (follow-up PR)

Shout-out to Kévin Commaille for contributing many of these improvements in his free time!

Dept of Ops 🛠

GitHub Action (website)

Cadair says

I have pushed a small update to my GitHub Action to send matrix notifications about builds. It now correctly backs off if it's rate limited by the matrix server, and has a new option to combine all successful statuses into a single reaction, which is useful if you have a lot of builds.

matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi reports

Thanks to Aine of etke.cc, matrix-docker-ansible-deploy can now set up rust-synapse-compress-state's synapse_auto_compressor tool to run periodically.

Learn more from our changelog entry.

Dept of Bots 🤖

flip-matrix-bot (website)

A Matrix bot for the Friendly Linux Players community.

HER0 says

flip-matrix-bot (website)

In the past two weeks, there have been a bunch of small improvements. The events page of the community website now lists upcoming events, and the event pages themselves have received some polish. As a result, links to event web pages are now included in the output of several commands. This makes it easier to see the event time in your local time and to share the event with people who are not in the Matrix room.

Looking to the future, improving these web pages brings us a step closer to integrating with Steam and Mastodon. I've started to investigate these further, but there isn't much to report yet.

Besides website-related improvements, I took some time to add unit tests for the lowest-hanging fruit parts of the code. There are more tests to be added, and further testing improvements may be possible in the future after some refactoring, but this is not a high priority for me right now.

Dept of Interesting Projects 🛰️

bridged.to project idea handing over

Alexey Murz Korepov reports

Searching for people to hand over a business idea of paid bridges for Matrix users to other messengers, for free!

I have a business idea to make a paid service for bridging Matrix (matrix.org) with other messengers using the Bridges feature (https://matrix.org/bridges/). It's like beeper.com, but which works with any MXID on any homeserver. And like t2bot.io, but commercial one and with more bridges available. Yes, t2bot.io is a great project, but free services usually got occupied by a lot of accounts, especially by spammers, and managing all of them for free sounds not so perspective to me. But bridged.to could also provide some free services for the community.

For that purposes I’ve bought a bridged.to domain several years ago, to make cool identifiers of bridges like @telegram:bridged.to, @whatsapp:bridged.to, etc.

But I still can’t find time to implement this idea at all. So, I’ve decided to stop paying for this domain and want to hand over this domain and the whole idea to someone else, who has the time and energy to implement this project.

The idea was to make the payments flexible, per-bridge, for example, $1 per month for each bridge. So, if a user will use bridges to Telegram + FaceBook + Instagram + WhatsApp, they will pay $4 per month, if they stop using some bridges - they pay less. And give a free trial period of 2 weeks for new users, to give it a try.

From the technical point of view, this should look like a standard Synapse server with a custom python module that just block-unblocks sending of messages by the user’s account balance, and also can gather some usage statistics (number of bridged messages per user, etc), and bridges instances, connected via appservices. And some admin panel with UI to manage and administrate this.

All this sounds easy to implement, but I have a lot of tasks at my main job, so have no time to accomplish this, and have decided to hand over this idea to someone else, who might be interested in it, for free.

So, if you’re interested in this idea or want to know more, or even just want to grab the cool bridged.to domain for free - please feel free to contact me via Matrix - @murz:ru-matrix.org.

The domain annual cost is $41.98, it's on namecheap.com, expires at Mar 28, 2023.

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.

#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.

That's all I know

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

A few weeks ago we found ourselves in Brussels to participate in the second stakeholder workshop for the Digital Markets Act (DMA).

The DMA is new antitrust/competition regulation from Europe which came into force in November, whose objective is to make digital markets more competitive by forcing gatekeepers (i.e. large tech companies) to reconsider some of their anti-competitive or self-preferencing practices. Gatekeepers are defined as companies which have a clear position of influence in a given market (based on revenue / market cap / number of users thresholds), and “an entrenched and durable position”. The process for designating which companies count as gatekeepers will start in May 2023.

The DMA touches upon different key topics, from self-preferencing behaviour to app store management practices - but most importantly includes interoperability for “number-independent interpersonal communication services” (NIICS), otherwise known as chat and voice/video calling and conferencing services (social media was left out for now).

This particular workshop was focused on the latter: interoperability between messaging services, with the aim of getting the different stakeholders of the industry in the same place to discuss how the legislation could be implemented. The whole idea is to figure out a practical way in which WhatsApp could interoperate with iMessage, Google Messages and others, creating an interoperable communication network where users are no longer locked into communication silos and pick their preferred service provider without compromising on who they can talk to. \

About 900 people participated online, and around 80 people were present in person: the maximum the room could hold. It was particularly fun to see representatives from the whole industry turning up in person, including folks from XMPP, MIMI (the new IETF working group on messaging interoperability), MLS, us from Matrix obviously (alongside Matrix ecosystem representatives from Beeper and NeoChat!) - all together with the Body of European Regulators for Electronic Communications (BEREC), civil society representatives (like the Federation of German Consumer Organisations (VZBV) and European Digital Rights (EDRi)), mobile network operators, local network agencies, and obviously some of those who are likely to be designated as gatekeepers, such as Meta, Apple and Google.

So what was discussed?

All of the workshop proceeds were livestreamed and archived by European Commission’s webcasting service and released under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) licence, so we’ve taken the liberty of republishing them split up into chapters so that folks can quickly refer to the discussion.

Panel 1: Introduction to horizontal interoperability between messaging services: goals, challenges and potential solutions

The first panel focused on setting up the scene and highlighting the challenges expected during the implementation phase, featuring Simonetta Vezzoso (Professor of Economics at The University of Trento), Chiara Caccinelli (Co-chair - Digital Markets WG at BEREC), Suzanne Blohm (Policy officer at Verbraucherzentrale Bundesverbands (VZBV)) and Jan Penfrat (Senior Policy Advisor at EDRi). There was a lot of emphasis around the risks of gatekeepers dragging their feet, or choosing the solution which makes it harder for SMEs or self-hosters to interoperate, as well as the challenge of introducing the new paradigm of interoperability for messaging without losing the usability aspect - see below for the full scope:

• 00:00 Welcome to the second DMA stakeholder workshop about interoperability between messaging services
• 08:03 Introduction of the panelists
• 09:26 What is the Article 7 of the Digital Markets Act (Simonetta Vezzoso)
• 26:35 Interoperability already exists in the EU, what can we learn from it (Chiara Caccinelli)
• 40:43 End user perspective and behaviour, benefits of the DMA Article 7, Challenges (Suzanne Blohm)
• 49:30 Benefits for end users, and an existing technical stack to build from (Jan Penfrat)
• 59:21 What the UI could look like (Jan Penfrat)
• 01:03:07 Question - Do users need an account on each network, or is it a true federation? (XMPP Foundation)
• 01:05:19 Question - What rule do you see for Telcos and for messaging services they provide?
• 01:10:07 Question - Does the term "user" include people running their own server/service? (Open Source Initiative)
• 01:14:50 Question - How to check the gatekeeper is not giving a suboptimal solution? (online question)
• 01:18:04 Question - Does user consent limit the power of Article 7? (Viber)
• 01:22:36 Question - Gatekeepers don't have an incentive to make appealing UIs for interoperability and might try to scare users away. Will it be addressed? (NLNet)
• 01:24:08 Question - People usually dislike popups, how to strike the balance between warning and upsetting them? (online)
• 01:27:51 Question - Have you been thinking about reputation models?
• 01:29:53 Question - Different apps use different E2EE protocols to differentiate. Could article 7 kill that differentiation? (online)
• 01:38:48 Question - What will be the paradigm of non discrimination?
• 01:33:10 Question - What about interoperability of RCS and Apple iMessage? (Orange)
• 01:34:44 Question - Do you take into account that there are not only company-run services, but also Open Source components? (Process One)
• 01:35:55 Question - What are the implications for non European users? (Beeper)
• 01:39:25 Question - Does the DMA only mandate interoperability for European users, even on a same platform? (XMPP)
• 01:40:36 Question - Will the interoperability be opt-in or opt-out? (Matrix)
• 01:41:50 Question - How avoid the standardisation to be taken over by commercial interests? (online)
• 01:43:43 Question - What will the timing look like for the DMA? (Cisco)
• 01:48:13 Question - What could be reasonable requirements for smaller services? (online)
• 01:49:00 Question - Where should gatekeeper gather to start discussion how interoperability will look like in practice? (OpenXchange)
• 01:51:11 Question - What about account portability, for users switching from one platform to another? (University of Rome)
• 01:54:53 Question - Is contact information part of the data gatekeepers need to share? (XMPP)
• 01:56:12 Closing

Panel 2: Exploring the technical aspects of interoperability (Part 1): end-to-end encryption, security of the service

Then, after a quick lunch, the second panel went into the nitty gritty of how end-to-end encrypted interoperable messaging (1:1 messaging is the first milestone to be delivered, hence the focus) could actually be implemented by the gatekeepers. The panel starred Paul Rösler from FAU Erlangen-Nürnberg, who gave a great overview of end-to-end encryption in general, Alissa Cooper from Cisco who explained the merits of open interoperable protocols, Eric Rescorla from Mozilla explaining the merits of standardisation, yours truly from Matrix explaining and demonstrating how one can actually use a standardised open protocol to interoperate without sacrificing privacy (effectively fleshing out our blog posts from last year) and then finally Stephen Hurley from Meta to explain how they are thinking about DMA obligations.

The panel ended up being a relatively exciting tour through the landscape of DMA practicalities, and it was a lot of fun to actually demonstrate a minimum viable prototype of client-side bridging thanks to Travis’s work packaging up standalone client-side bridges for WhatsApp and Google Chat (strictly for demonstration illustrative purposes only). The slides (and demo) were sadly a bit fuzzy on the recording, but you can see our slides below and grab everyone’s presentations from the European Commission website:

When DMA first became headline news last year, there was a lot of very vocal concern that it would somehow end up undermining end-to-end encryption (despite the legislation explicitly requiring that E2EE must be preserved when interoperating). Hopefully this session demonstrated that both the European Commission and the various panellists are dead serious about achieving interoperability without sacrificing privacy - whether that’s via the brute-force approach of client-side bridges, or the more sophisticated approach of client-side bridges which bridge to client-side APIs, or by incrementally or entirely adopting a true open standard protocol like Matrix, XMPP, or whatever MIMI comes up with.

You can see the whole panel split into the various sections below:

• 00:00 Opening
• 01:23 Introduction of the panellists
• Interoperable Messaging - Paul Rösler (FAU)
• 03:10 Interoperable end-to-end (E2EE) encryption options (Paul Rösler)
• 05:24 Requirements for interoperable E2EE (Paul Rösler)
• 09:22 Options for interoperable E2EE (Paul Rösler)
• 13:54 Confidentiality, Privacy & Abuse prevention (Paul Rösler)
• 19:07 Group Messaging (Paul Rösler)
• DMA Stakeholder Workshop: Interoperability - Eric Rescorla (Mozilla)
• 22:44 Learning from QUIC (Mozilla)
• 24:14 E2EE and interoperability (Mozilla)
• 25:50 Key Establishment in a E2EE interoperable system (Mozilla)
• 27:16 Message and media formats in a E2EE interoperable system (Mozilla)
• 28:30 Identity in a E2EE interoperable system (Mozilla)
• 30:49 Multiple gatekeeper scenarios (Mozilla)
• 31:41 Suggested framework for interoperability (Mozilla)
• DMA Stakeholder Workshop: Interoperability - Alissa Cooper (Cisco)
• 35:20 Discussing how the UX of a DMA compliant product can look like (Cisco)
• 36:38 The use case for enterprise interoperability (Cisco)
• 30:47 Approaches to DMA Compliance (Cisco)
• 43:57 Limits of the per-gatekeeper, in-house solution approach (Cisco)
• 48:19 Strengths of the consolidated (standardised) solution (Cisco)
• 50:00 Implications & requirements of the consolidated solution (Cisco)
• Implementing Interoperability for the DMA - Matthew Hodgson (Matrix)
• 52:03 Implementing Interoperability in practice for the DMA (Matrix)
• 53:00 A practical path to full interoperability (Matrix)
• 54:35 Defining the problem we're solving (Matrix)
• 55:15 Approach 1 Client-side bridging using server-side APIs (Matrix)
• 57:21 Approach 2 Client-side bridging using client-side APIs (Matrix)
• 58:48 Approach 3 Polyglot app, using a 3rd party protocol à la iMessage (Matrix)
• 01:00:06 Approach 4 Using an open protocol (Matrix)
• 01:00:42 Pros & Cons of each approach (Matrix)
• 01:01:55 DEMO of client-side bridging (Matrix)
• Meta's view on the DMA as seen from WhatsApp - Stephen Hurley (Meta)
• 01:06:45 Meta's view on the DMA as seen from WhatsApp (Meta)
• Questions
• 01:17:12 Matthew (Matrix) remind that not only the demo showed client-side bridging was possible, but iMessage has been doing it for years via SMS & iMessage
• 01:17:54 Meta has two IM platforms (Instagram and Facebook) that are not E2EE. What is Meta going to do about those platforms? (Beeper)
• 01:18:45 How to balance discoverability and privacy?
• 01:21:04 How to solve the problem of different E2EE protocols? (online)
• 01:24:48 Do some of the panellists think the best option is not a single standardised protocol? (OpenXchange)
• 01:33:46 Which measures by gatekeepers to preserve security integrity and privacy can be considered proportionate?
• 01:36:38 How many people have worked on the client-side demo?
• 01:38:56 Does it really matter that MLS is not "done"?
• 01:47:30 How will article 7 ensure private keys will never transit over the network? (online)
• 01:53:00 What about interoperability of features like custom emojis, removing messages, etc? (online)
• 01:57:42 What does the rest of the panel thinks about the guarantees they can provide when a message leaves a system? (XMPP)

Panel 3: Exploring the technical aspects of interoperability (II): data collection, identification of users, quality of interoperable services, system management, integrity of the service/prevention of misuse

Finally, we launched into the third and final session of the day - a second technical panel to dig into questions of identity, usability, data privacy, consent and anti-abuse in a DMA world. Relative to the second panel, there were more questions than answers here, as the panellists discussed whether users would need to consent or opt-in/opt-out of interoperability, and debated the various data privacy implications of DMA. The panel starred Stephen Hurley from Meta again, Lucas Verney from PEReN, Markus Klein from Bundesnetzagentur and Rohan Mahy from Wire introducing the MIMI working group at IETF.

• 00:00 Opening and panellists introduction
• Meta / WhatsApp
• 02:21 User Safety on WhatsApp
• 06:51 Consenting to interoperability
• 07:56 Objective criteria to assess whether a request is reasonable or not
• PEReN
• 09:00 PEReN is a French government digital expertise hub
• 10:12 Efficient design for effective interoperability
• 11:25 Reconciliation identity between services
• 13:40 Discoverability between platforms of different scales
• 16:27 Should fancy features (e.g. emoji reactions) be interoperable?
• 17:22 Quality of Service
• 19:02 Security goes beyond E2EE
• Bundesnetzagentur
• 20:26 Bundesnetzagentur views on the DMA
• Wire
• 26:39 Federation and Interoperability issues are similar
• 28:10 Standards-based interoperability and the MIMI working group
• 29:18 Identifiers, devices, handles
• 30:50 User introduction & discovery
• 31:30 Messaging content
• 34:06 Why MIMI picked MLS for E2EE?
• 35:54 Server to server transport mechanism
• 36:38 E2EE Cryptographic identity
• 39:00 MIMI's standardisation work provides a strong foundation for other features
• 40:25 Why is standardized interoperability beneficial?
• Questions
• 44:30 What about terms of service, minimum usage age enforcement etc?
• 48:03 How can identity be maintained separately from networks? How will differing policies of services be respected?
• 52:26 Does WhatsApp rely on the phone number as a primary identifier?
• 53:29 Some systems like Telegram have pseudonymous IDs. How would that work with platforms relying on e.g. phone numbers?
• 55:42 Should the service name be part of the identifier?
• 57:33 Can the DMA improve how authentication is handled?
• 59:51 What made the GDPR successful is the potential fines. What about the DMA?
• 01:03:48 How can interoperability be designed to stop leaking contact lists?
• 01:09:15 Are we doing cookie banners again?
• 01:15:57 Should we think about some integration with eIDAS for more trustworthy identities?
• 01:19:48 Are all the protocols like Matrix or MIMI free to use, or do they have a fee?
• 01:22:32 Are there really concerns about the DMA and security?
• 01:27:40 Does Meta expect to provide a EU-only and a global version of their messengers?
• 01:29:55 The views expressed here regarding consent are concerning when it comes to self-hosting
• 01:36:20 Closing

Conclusion

This was a fascinating opportunity to have a front-row seat at history being made, as the various key players finally got down to business on the practical implications of DMA interoperability.

We saw the full spectrum of options on the table, from Meta’s implications that they would simply open their existing API complete with the existing Double Ratchet Encryption, to the pragmatic approach of Matrix (“at first we’ll bridge, and then the players should gradually converge on an open standard”) to the more idealistic approach of MIMI (“everyone should natively adopt an entirely new open standard built on MLS”). The next step is to establish a reference implementation and approach, and in the end it seems likely that the approach that works will be the one which the gatekeepers can actually practically adopt within the punchy timeframes built into the legislation:

You can also check out Carl Schwan’s writeup (from NeoChat), as well as Eric Rescorla’s braindump on DMA interoperability that accompanies his talk.

We live in interesting times, and it’s fascinating to see Matrix’s vision of interoperable communication being cemented into regulation by the EU. Our view is that as long as the gatekeepers open their APIs and add support to model remote users in their systems, then at least the wider world can implement client-side bridges to crack the door of the gatekeepers open - and then as gatekeepers refresh their stacks and new players emerge, they’ll likely implement the common protocol (if it’s fit for purpose) rather than burn time reinventing the wheel on proprietary solutions. Meanwhile, the DMA provides welcome encouragement to ensure that open protocols like Matrix can rise to the challenge and fill the gap - whether that’s independently or as part of IETF’s MIMI initiative. May the best solution win!

Matrix Live

Dept of Spec 📜

Andrew Morgan (anoa) 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:

• MSC3975: rel_type for Replies

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• MSC3966: event_property_contains push rule condition
• MSC3873: event_match dotted keys
• MSC3758: Add event_property_is push rule condition kind

Closed MSCs:

• No MSCs were closed/rejected this week.

Spec Updates

Review this week from the SCT focused on the future of OIDC and logging in via a QR code (MSC3906) - a feature other platforms have and one I would love immensely. Fixing notifications (MSC3966, MSC3873, MSC3758, MSC3952, MSC3958) as per last week, as well as trying to finally get MSC2677 (spec'ing the current state of Annotations and Reactions) into FCP.

Random MSC of the Week

The random MSC of the week is... MSC3972: Lexicographical strings as an ordering mechanism!

While there already is an MSC for a top-level ordering of Spaces in use across some client implementations today (MSC3230), the algorithm recommended for clients to implement apparently has some consistency flaws, leading to edge cases. MSC3972 attempts to address this by providing a different algorithm that does not have these flaws. A real-world implementation of the algorithm is also available today in Kotlin at https://github.com/Dominaezzz/MatrixSort.

Neither of these algorithms have been merged to the spec yet, but this new MSC may finally push this conversation forwards! I recommend client developers give it a read and leave their feedback as Pull Request Review comments on the MSC.

Dept of Servers 🏢

Telodendria (website)

An open source Matrix homeserver implementation written from scratch in ANSI C and designed to be lightweight and simple, yet functional

Jordan Bancino reports

Hey everyone, it's been a while since I've posted an update here, but I'm pleased to report that progress on Telodendria is still steady. Here's a small glimpse into what's happening with the project:

• v0.2.1: The second major release of Telodendria was published earlier this week. Telodendria still isn't much yet, but the user authentication section of the client-server specification is just about complete. This means you can register for accounts, log in and get access tokens, and then log out. All the stuff that goes with that, including the static login fallback page, and user interactive authentication is in place.
• What's Next: I'm hoping to start working on the account management endpoints next. I also want to start building out an HTTP client for federation, and I want to move the configuration file into the database, so that Telodendria is configured via an admin API endpoint instead of a file. The thinking here is that this enables Telodendria to be configured at runtime, without having to restart the process to apply configuration changes.
• Help Wanted: As always, I could use your help. This is a huge project, and I am very busy so I can't dedicate as much time as I'd like to it. If you find Telodendria interesting and want it to continue, feel free to join us over in #telodendria-general:bancino.net, write some code and documentation, donate to the project, or any and all of the above!

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

Shay reports

Welcome to another Friday and another edition of the Synapse section of TWIM. This week we've released Synapse v1.79.0rc1.

Some notable highlights include:

• Added two new Third Party Rules module API callbackson_add_user_third_party_identifier and on_remove_user_third_party_identifier

• Added experimental support for MSC3967 to not require UIA for setting up cross-signing on first use.

• Fixed a long-standing bug where an initial sync would not respond to changes to the list of ignored users if there was an initial sync cached.

• Fixed a long-standing bug where the user directory search was not case-insensitive for accented characters

• Documented how to use caches in a module

  Plus much more! You can check out the details here(https://matrix.org/blog/posts) or take a deep dive in the release notes here.

Construct (website)

A performance-oriented homeserver with minimal dependencies.

Jason Volk reports

This week Construct gained support for freshly minted MSC3758 and MSC3966 enriching the pushrules subsystem. I'd like to thank Giovanni Bottaro for contributing a patch which fixes updates to the public rooms directory. I'd like to thank @qg:schildi.chat for reporting two other issues which I've been able to push fixes for this week. I'd also like to thank Yan Minari for refactoring the nix build up to date in preparation for Construct's 1.0 release.

The saga continues over at #construct:zemos.net

Dept of Clients 📱

iamb (Website)

A terminal-based Matrix client that uses Vim keybindings

ulyssa says

iamb had a new release this week. Release v0.0.6 includes:

• Support for tab completion of usernames, aliases, and commands.
• A new command for creating rooms and spaces
• Bug fixes for edits and creating new direct messages
• Improvements to text wrapping in messages
• NetBSD's pkgsrc-current now includes a package for iamb

mnotify (Website)

stefan says

mnotify gained a few features:

• Attachments can now be sent to a room with mn send -r "$ROOM_ID" --attachment CAT.jpg.
• mn sync gained a flag --raw which prints all received events, including e.g. presence or typing.
• mn rooms can list all rooms you are in, including room members and avatars.

chooj (Website)

Farooq says

chooj, the Matrix client for KaiOS feature phones, has seen many changes in the last few weeks. Many bugs were fixed and many others are probably added. We now support many other events other than message events which you can view in the rooms plus an experimental image viewer to better investigate the received images. Other than that, by removing the files KaiOS doesn't use, the production bundle size is half now. A big internal change also happened and still is not finished yet. With the assist of Simon Laux, a big portion of chooj is now a separate library which makes maintenance easier and also lets other KaiOS apps use them. I have written my plans for chooj in my last post in the BananaHackers blog. If you like to see Matrix chat on the KaiOS feature phones, you can donate an amount to help with the development of the project. Or you can donate me a debug enabled KaiOS phone with the mentioned features.

Nheko (website)

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

LorenDB announces

We've had some fun and useful things happening in the past two weeks!

• red_sky (nheko.im) worked on automating the release process to automatically create a release when a tag is pushed. This might not sound like much, but it makes life easier for maintainers who would otherwise have to waste time manually creating releases. After all, why would you want to write release notes when you could be writing code?
• Nico tweaked styling for HTML tables to increase the padding. Thanks to Cadair for the suggestion!
• Nico also fixed a bug that showed avatar changes as somebody joining a room. I seem to recall this also happening when users changed their display names, but I can't reproduce that behavior. Either way, it is nice to have this fix in place!
• I worked on closing some of our issues, and I'm happy to report that there are fewer ways to be unpleasantly surprised by the UI. For example, if you have turned on the setting to make emoji-only messages larger, all other emojis will also get a bit of a size boost to make them easier to read.
• On that note, I recently went through the issue list and closed a number of outdated issues that had already been fixed, because 260+ issues is obviously too many for any self-respecting project... right? ;)
• I also overhauled nheko's behavior when you attempt to use an invalid /command. Originally, nheko would eat any invalid commands (e.g. sending /foo would clear the input box but would not send a message). Now, if you type /foo, you will see a warning informing you that you are about to send a message that says /foo into the chat instead of running a command /foo. If you choose to disregard the warnings and hit Enter, nheko will indeed send a message saying /foo!

But that's not all: this week, mtxclient gained the ability to properly handle m.room.message events that have an unknown msgtype. With that in place, I'm working on implementing that on the nheko side. Once this work is done, you will be able to read messages that others send from Element with fireworks! Furthermore, I'm adding a bonus feature to nheko: as a proof-of-concept for fully implementing this unknown message handling, I've got a working implementation of Element's rainfall effect for those of you who like fancy effects! (All the rest of you can just turn those off in the settings, I guess.)

A note for our Mac users: somebody opened an issue last week notifying us that nheko couldn't be installed on OS X 11.1. Nico has fixed this, but you will need to either wait for the next release or install one of our nightly builds (#nheko-nightlies:neko.dev).

Ement.el (website)

Matrix client for Emacs

alphapapa says

Ement.el, a Matrix client for the GNU Emacs text editor and Lisp environment, has been released at v0.7. Changes in this version include:

Additions

• Command ement-room-override-name sets a local override for a room's display name. (Especially helpful for 1:1 rooms and bridged rooms. See [MSC3015]https://github.com/matrix-org/matrix-spec-proposals/pull/3015#issuecomment-1451017296).)

Changes

• Improve display of room tombstones (displayed at top and bottom of buffer, and new room ID is linked to join).
• Use descriptive prompts in ement-leave-room and ement-forget-room commands.

Fixes

• Command ement-view-space when called from a room buffer. (Thanks to Richard Brežák for reporting.)
• Don't call display-buffer when reverting room list buffer. (Fixes #121. Thanks to mekeor for reporting.)
• Retry sync for network timeouts. (Accidentally broken in v0.6.)

Internal

• Function ement-put-account-data accepts :room argument to put on a room's account data.

Feel free to join us in ement.el:matrix.org!

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!

andybalaam announces

• We started the process of wrapping up the remaining smaller – and non-essential – leftovers from the Gitter migration support in Element Web and are hoping to complete them next week
• Work on moving our packaging into the cloud is progressing and we also started to improve our infrastructure for updating the GPG key for our Debian packages
• Further investigation on the remaining stuck notification issues has indicated that spec changes around the handling of relations inside threads will be needed. We're planning to work on these soon.
• The React SDK changes for MSC3952 (intentional mentions) are getting ready to land

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Manu says

• This week we continue to polish Element X. It got a new Rust SDK version that fixed known bugs in the new Sliding Sync API implementation. A new public TestFlight (1.0.24) will be available during the week-end, after Apple approval.
• We resumed the work on push notifications on Element X and experimented the new instant messaging push notification APIs.
• On Element land, a new version, 1.10.4, will be available on Monday. Applications with analytics enabled will gradually use the new crypto stack, coming from the matrix-rust-sdk crypto crate. Anyone can enable it from the LABs settings at any time.

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

benoit announces

• We have just released Element Android 1.5.28, it should be pushed to production next week. Element Android is now mainly in maintenance mode.
• More and more people are working on Element X Android. We are working on updating the design, and refining the architecture of the project. It will soon be possible to verify a session, and create a room from this client. We are also preparing the work to be able to receive Push and display notifications.

Dept of SDKs and Frameworks 🧰

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict reports

Just another small release of Trixnity (v3.5.0):

improvements:

• expose more device trust level information (breaking change)

bugfixes:

• fix too long open transaction in IndexedDBMediaStore (relevant for larger media files)
• allow cancel device verification before any device answered

matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

Jonas Platte says

• The PR for client user avatar URL caching mentioned last week has been merged
• We fixed a long-standing CI problem where coverage data would frequently fail to upload
• Our state store / cache abstraction was improved (1, 2)
• We fixed some races between /sync and /keys/queries requests
• Plus lots of purely internal improvements!

Dept of Ops 🛠

synadm (website)

Command line admin tool for Synapse (Matrix reference homeserver)

jojo announces

It's been some time since synadm last showed up on TWIM, it was around summer 2022. The biggest news is that Ascurius and me just welcomed a new member to the team: jacksonchen666. We reached out since he seemed to care about synadm. He had submitted a feature but we also caught him tidying up "unloved" issues. He has a good sense for concise solutions and accurate documentation. He runs a website and a blog where he talks about "things".

Here's more we'd like to spread:

• A random list of new commands, read details in the docs to learn what they do: synadm notice send, synadm user 3pid, synadm user auth-provider, synadm room block/unblock synadm room block-status, synadm media unquarantine, synadm user modify --user-type ..., synadm user deactivate-regex.
• A new output mode minified was added and the original json mode was improved to now produce nicely human readable json.
• We finally have a contributing documentation and hope it'll make collaboration with our contributors even better.
• We introduced an auto-linter based on flake8 into our CI pipeline to catch code formatting issues quicker.
• The new Scripting Examples chapter. Please submit your one-liners or other helpful scripting examples via a pull-request or just let us know in #synadm:peek-a-boo.at

By the way, jacksonchen666 searched for synadm occurrences in the TWIM history and we found an article "next to us" about the Matrix Community Summit 2022 that took place in Berlin last summer. It reminded us that it was a blast! Thanks dear organizers, we hope you manage to do it again! Here's some musical memories in the name of our reference homeserver.

matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi announces

Thanks to Benjamin Kampmann for getting it started, FSG-Cat for fixing it up and me (Slavi) for polishing it up, matrix-docker-ansible-deploy now supports installing the Sliding Sync Proxy.

Running this additional component allows playbook users to easily test the new (still beta) Element X clients (Element X iOS and Element X Android).

To get started, see our Setting up Sliding Sync Proxy documentation page.

Dept of Bots 🤖

kfatehi announces

This is not a project but an idea nevertheless: Produced a quick and dirty PoC of an OpenAI chat completion tool used from within Element Web/Desktop. Video can be found here https://github.com/matrix-hacks/openai-reply-generator

explored making it shippable via bot, bridge, widget, and puppet-client but i have yet to find an experience that i like completely yet but still worth sharing how easy it is to test ideas in Matrix (which through bridges, can touch all media)

Dept of Interesting Projects 🛰️

Effektio is now acter.global 🚀

ben reports

Shortly after releasing our whitepaper end of last year, Effektio was approached by another organization, who has been building a NGO communication platform for a few years called Acter. Acter wanted to move away from their current centralized stack and had found Matrix.org 's Federated Model to be their preferred ideal. Very quickly within the talks that followed it became clear that both organization have the same goals and visions for the future and are perfectly matching in terms of what they already bring and what each lacks: Effektio has the technological stack, expertise and ability to build the product while Acter has existing a network of organizations, partners and even existing users, who are happy to provide feedback. Long story short, we decided to merge both into a newly funded Acter Association, which we established Jan 1st, developing the next (third) generation of the Acter Platform ("A3") on top of the existing effektio tech stack. Since then a major part of our work has been merging all the admin and tech stuff, up to moving the github repo over to acterglobal/a3, where you will find it from now on.

Next to that, we still have continued working on the product itself. Among other things we have merged the first implementation of the Adaptive Layout in A3 this week, implemented the next acter object, Pins, added Rageshake Bug Reporting to the nightly builds, started out with the new Templates infrastructure and improved our quality assurance by reactivate rust integration tests, add widget unit tests and a new cucumber desktop tests infrastructure.

More details on all of these in todays update in our very own news channel: https://matrix.to/#/#news:acter.global

MinesTRIX (website)

A privacy focused social media based on MATRIX

Henri Carnot says

website * repo

Hello hello,

today is a big day for MinesTRIX because it's finally possible to test it as we are now in Flathub! https://flathub.org/apps/details/fr.henri2h.minestrix

In parallel, I have been quite a lot of work in the background. And in last version (v1.6.5), we have:

• Switched to Material3 and redesigned the app navigation. Removed black theme for more simplicity.
• It is now possible to set permissions (room visibility and powers levels) for groups and feeds.
• Role & permissions view for room settings is now more intuitive.
• fine tuned the new feed indexing systems. Should be more stable now.
• The settings page got some love and now display all the sessions and their status (verified or not). It is also possible to logout all 90+ days sessions.
• new message search view for not encrypted conversations.
• fixed notifications count for rooms
• better experience for searching user or rooms.
• new page to list feeds and groups
• it is now possible to unfollow someone
• fixed SSO login on web
• It's now possible to switch account from home page for easier multi account usage.

In master:

• support for video messages
• speed up room media loading for the not encrypted rooms by requesting events directly from server
• allow resizing the settings and chat view

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.

#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.

That's all I know

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