🔗Matrix Live 🎙

🔗Dept of Status of Matrix 🌡️

Thib says

Taking my GNOME Foundation hat on for this news: the GNOME Foundation is adopting Matrix! Is this TWIM worthy? It probably wouldn't have been if it wasn't for all the great work of Gwmngilfen! We published a joint blog post (though in all fairness Greg did all the heavy lifting) to explain how the decision was taken, and transparently share the data we had at hand.

In practice that means after years of Matrix being around in the GNOME community and being the most popular platform, it's finally moving out of the grey zone of "everyone is using it but some older contributors really like their current set up, so it exists but it's not officially our primary platform". For now we're keeping both our Matrix instance and the bridge to GIMPnet (the IRC network GNOME people have been using for years). The major change is that IRC is now our legacy, so if tradeoffs have to be made Matrix will keep the premium experience.

Again, huge shout out to Gwmngilfen who gave meaning to the data I handed to him.

https://blog.ergaster.org/post/20220425-adopting-matrix/

🔗Dept of Spec 📜

Andrew Morgan (anoa) reports

🔗Spec

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://matrix.org/docs/spec/proposals.

🔗MSC Status

New MSCs:

• MSC3784: Using room type of m.policy for policy rooms
• MSC3783: Fixed base64 for SAS verification

MSCs with Proposed Final Comment Period:

• MSC3244: Room version capabilities

MSCs in Final Comment Period:

• No MSCs are in FCP.

Merged MSCs:

• No MSCs were merged this week.

🔗Spec Updates

Hello again everyone! Your regularly-scheduled TWIM Spec update has returned, along with graph-based media!

Quick news to point out this week is that a new maubot plugin has been written to simply note the details of MSCs after their IDs ("msc1234") have been posted in a room. The bot supports multiple MSC IDs in a message, message edits, threads and end-to-end encrypted rooms.

A copy of the bot is currently running under @mscbot:matrix.org, so feel free to invite it to a room if you'd find that useful!

🔗Random MSC of the Week

The random MSC of the week is... MSC3216: Synchronized access control for Spaces!

This MSC serves as an alternative to MSC2962, and essentially allows for user permissions to be simultaneously enforced across a set of rooms in a Space. This would allow functionality to users of platforms like Discord, where a user can be a moderator in a guild, and thus in all of that guild's channels.

🔗Dept of Servers 🏢

🔗Synapse (website)

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

richvdh says

A few operational issues have taken up quite a bit of the team's time this week, but we've still found time to cut a couple of release candidates of v1.58. Highlights include:

• Locked python dependencies for our Docker images and Debian packages, thanks to David's poetry work.
• Some big performance fixes, including an optimisation to login from Erik and one to message backfill from yours truly.

We're also excited to see quite a few contributions from outside the core maintenance team: thanks to Dirk, Beeper, Famedly and everyone else in the community who has made pull requests!

Meanwhile on the core team, Sean has been continuing to lay groundwork for faster room joins, and Olivier has been doing some exciting work so that we will (finally) be able to test Synapse in worker mode under Complement.

🔗Dendrite (website)

Second generation Matrix homeserver

neilalexander says

This week we announced Dendrite 0.8.2 with a bunch of usability fixes. As always, join us in #dendrite:matrix.org for more discussion and updates.

🔗Features

• Lazy-loading has been added to the /sync endpoint, which should speed up syncs considerably
• Filtering has been added to the /messages endpoint
• The room summary now contains "heroes" (up to 5 users in the room) for clients to display when no room name is set
• The existing lazy-loading caches will now be used by /messages and /context so that member events will not be sent to clients more times than necessary
• The account data stream now uses the provided filters
• The built-in NATS Server has been updated to version 2.8.0
• The /state and /state_ids endpoints will now return M_NOT_FOUND for rejected events
• Repeated calls to the /redact endpoint will now be idempotent when a transaction ID is given
• Dendrite should now be able to run as a Windows service under Service Control Manager

🔗Fixes

• Fictitious presence updates will no longer be created for users which have not sent us presence updates, which should speed up complete syncs considerably
• Uploading cross-signing device signatures should now be more reliable, fixing a number of bugs with cross-signing
• All account data should now be sent properly on a complete sync, which should eliminate problems with client settings or key backups appearing to be missing
• Account data will now be limited correctly on incremental syncs, returning the stream position of the most recent update rather than the latest stream position
• Account data will not be sent for parted rooms, which should reduce the number of left/forgotten rooms reappearing in clients as empty rooms
• The TURN username hash has been fixed which should help to resolve some problems when using TURN for voice calls (contributed by fcwoknhenuxdfiyv)
• Push rules can no longer be modified using the account data endpoints
• Querying account availability should now work properly in polylith deployments
• A number of bugs with sync filters have been fixed
• A default sync filter will now be used if the request contains a filter ID that does not exist
• The pushkey_ts field is now using seconds instead of milliseconds
• A race condition when gracefully shutting down has been fixed, so JetStream should no longer cause the process to exit before other Dendrite components are finished shutting down

🔗Dept of Bridges 🌉

🔗matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair announces

The bridge should finally be at "Good Enough" status--and to celebrate, I've bumped the version to 0.2.0 🥳

Features & fixes include:

• KT->Matrix file messages
• Matrix->KT room leaves
  • To leave a KT channel from Matrix, issue the !kt leave command in a portal room.
• Ability to name the virtual "device" for the KakaoTalk login session created by the bridge
  • This makes it easier to distinguish between multiple login sessions of the bridge
• Improvements to KT->Matrix joins, kicks, and admin status
• Many significant stability & correctness improvements
• Docker support
  • This is currently in the testing branch until I can confirm that it works properly

I've also opened a PR to showcase this bridge on https://matrix.org/bridges/ 😃

---

Discussion: #matrix-appservice-kakaotalk:miscworks.net Testing room: #kakaotalk-bridge-testing:miscworks.net / https://open.kakao.com/o/gjGQFuae Issue page: https://src.miscworks.net/fair/matrix-appservice-kakaotalk/issues

🔗Dept of Clients 📱

🔗Element (website)

Everything related to Element but not strictly bound to a client

Danielle says

Threads

• The Threads Beta is live! Turn it on in Labs

  • Let us know your feedback as we continue to work on this feature.

• The next step for Threads is improving our notifications and push rules on threaded messages. We’ve drafted some MSCs and are excited to move them forwards.

Community testing

• Thank you all who joined the async community testing sessions.

• Next week, we are planning to test:

  • Improvements to the new search experience on web
  • Video rooms!
  • And the new release candidate

• For more info on our next testing sessions (sync or async), you can join us at #element-community-testing:matrix.org!

🔗Element Web/Desktop (website)

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

Danielle says

• We have increased our pool of issue triagers, so expect to meet more of our web team on GitHub

• Published epic issue for our tech strategy for 2022

• The way that read receipts are displayed in rooms with lots of people has improved

• In labs (you can enable labs in settings on develop.element.io or on Nightly)

  • Focusing on resolving last issues with threads, currently blocking on MSCs for read receipts for threads and push rules for mutually related events
  • Video rooms are getting ready to enter beta!

🔗Element iOS (website)

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

Danielle announces

• The leaving space experience is now in line with web: you can leave all rooms, none of the rooms or only selected ones
• Our first time user experience and create account flow is being improved.
• Started prototypes for IA experiments. We’re hoping to make the app much easier to use and will test out new interactions and patterns to see what works for users.

🔗Element Android (website)

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

Danielle reports

• Hard at work fixing bugs - we’ve squashed one where the UI would freeze after incremental syncs and we’ve also made improvements to the read line and read markers.
• Our team is still working on the sign up flow. It’ll be ready soon and we hope that new-to-element users will find it much easier (and less scary) to create an account and get chatting.
• We’ve started designing and building prototypes for a new home experience; we’re excited to start experimenting with ways we can simplify our app.

🔗Dept of Non Chat Clients 🎛️

🔗Thirdroom (website)

A browser-based open metaverse client

Matthew reports

lots of exciting progress happening on Third Room - an open metaverse client powered by Matrix: https://github.com/matrix-org/thirdroom/discussions/47

🔗Matrix Wrench (website)

Matrix Wrench is a web client to tweak Matrix rooms.

ChristianP says

v0.6.2

• Added: A "Remember login" checkbox lets you decide whether to store an access token in localStorage.
• Added: The room lists now have external matrix.to links.

🔗Dept of SDKs and Frameworks 🧰

🔗Ruma (website)

A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.

Jonas Platte announces

Our last update included the words "if things go to plan", and even though that's usually calling for trouble, not so this time! We released Ruma 0.6.0 yesterday and apart from a tiny missing feature that was fixed and released as 0.6.1 today, everything went smooth 🙂

The biggest breaking changes are

• new owned identifier types – calling .to_owned() on &UserId now gives you an OwnedUserId instead of Box<UserId>
• a new event enum hierarchy, where redacted events are better taken into account

Also, with this release we can now claim practically 100% coverage of Matrix v1.2, that is you can send and receive requests for all specified endpoints of the various APIs, as well as send and inspect all specified event types, all with a strongly-typed Rust API.

🔗Dept of Ops 🛠

🔗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 the Buscarron bot. It's a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) Matrix room

See our Setting up Buscarron documentation to get started.

🔗Buscarron (website)

Web forms (HTTP POST) to matrix

Aine reports

the Miounne's successor is here - meet Buscarron!

There were no news about miounne for a while because we worked on a new "iteration" that can handle matrix encryption (thanks to the mautrix-go).

So, here is it - Buscarron v1.0.0 with e2e encryption and multiarch (arm32, arm64, amd64) support. It can handle any HTTP POST/HTML form and send it to a (encrypted) matrix room. Of course, Buscarron has small neat features like spam checker and rate limiter.

etke.cc is migrating to Buscarron and deprecating Miounne.

Go check out the source code and say hi in the #buscarron:etke.cc

🔗Dept of Bots 🤖

🔗Location streams bot for MSC3489

ChristianP announces

I wrote a small, extensible bot that replays GPX recordings as a location sharing stream. This is an implementation of MSC3489: Sharing streams of location data with history and may help you debug the feature or see it with real world data. Join my Space to see this in action (with the Element Web Labs feature): #geo-trackers:iot-staging.ems.host or run the bot with your own rooms and GPX files. https://gitlab.com/jaller94/matrix-location-sharing

🔗Opsdroid (website)

An open source chat-ops bot framework

Cadair says

Opsdroid 0.26 has been released this week. Included in this release are some improvements to the Rasa NLU parser if you want natural language training for your matrix bots as well as some small documentation improvements to the matrix connector and other bug fixes. Big thanks to Oleg for many of the changes as well as all the other contributors.

🔗Matrix Community Manager (website)

The highly configurable message aggregation and filtering bot for matrix!

Sleuth reports

Matrix Community Manager has seen some work in the features department over the past week.

With the new Ansible playbook I think it's possible for someone with a bit of Ansible experience to get this bot up and running in under 10 minutes. I did a fresh install in 4 minutes. That is a fresh VPS and creating a new matrix account. Instructions for the Ansible deploy can be found here.

The major features are:

• An Ansible playbook that should simplify the installation process for new users.
• Edits to the message that triggered the bot will now be reflected in the bots message. This bot now has a feature Twitter doesn't have :laughing:.
• Hashtags are now called filters. Filters are more customizable allowing for custom delimiters and now show the originating room.
• The AutoJoin feature has filters to control who or from where invites will be excepted.
• Announcements can have more than one output room. Using a comma separated list of room ids.

A few bugs were fixed as well:

• Some text characters were causing messages to be classed incorrectly thus causing crashes.
• Exotic characters specifically in links were causing crashes.

Come chat on Matrix

🔗Dept of Events and Talks 🗣️

🔗Matrix Meetup Berlin

ChristianP says

We're meeting on Fri, 6th May at 6:30 PM in the c-base. Please join us, if you're looking for locals who work with Matrix and use it regularly. Our Matrix room is Matrix Meetup Berlin.

🔗Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	maunium.net	259
2	envs.net	315
3	neko.dev	366
4	carnot.cc	481
5	tchncs.de	562.5
6	jeroenhd.nl	588
7	broccoli.town	604.5
8	kohlernet.de	762
9	matrix.cirk2.de	867
10	quyo.de	1126

🔗#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	carnot.cc	294
2	matrix.sum7.eu	389
3	cry.is	499.5
4	foxo.me	654
5	rustybever.be	693.5
6	matrix.awesomesheep48.me	898
7	beckmeyer.us	899
8	sspaeth.de	991
9	dendrite.matrix.org	1370.5

🔗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 Servers 🏢

🔗Synapse (website)

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

dmr says

Hello again everyone. This week the team released Synapse 1.57.0, followed by a 1.57.1 patch release that fixed a problem in the 1.57.0 docker image.

This week was a little on the quieter side again, with some of us away on holiday and others away with illness. Nevertheless, this week develop saw a variety of activity. Some personal highlights:

• Shay's effort to document Synapse's numerous config options landed. This is a huge and comprehensive effort that'll help administrators to understand all the options they have to configure Synapse.
• Further progress from Rich on the fast room joins project. In some tests we've seen a 5x speed-up over the status quo!
• A subtle bugfix from Erik which corrects incorrect counts in one of the Admin API endpoints.
• The remainder of the poetry work has landed. There were a few last-minute complications in CI to smooth out, but we've now finished the migration. Synapse's docker images and debian package now come with a fixed set of dependencies (even transitive ones) in a way that lets us support multiple Python versions and interpreters.

We're looking forward to shipping these in Synapse 1.58, whose RC is scheduled for Tuesday the 26th of April.

I'm also keen to see how PR 12522 from Rich and Olivier progresses. It aims to fix a nasty memory bug which can cause Synapse to get stuck in an OOM loop.

As ever, I'd like to express thanks to our community of users, server operators and contributors. Thanks are also due to @callahad: today is his last day of managing the Synapse team. We're all going to miss him and wish him well: thank you for everything you'd done over the last year and a half.

🔗Dept of Bridges 🌉

🔗Heisenbridge (website)

Heisenbridge is a bouncer-style Matrix IRC bridge.

hifi reports

Release v1.12.0 🥳

• Make MAXLINES and PASTEBIN option available to every room & global defaults (thanks @BtbN)
• Fix 'NoneType' is not iterable error (thanks @BtbN)
• Upgrade to Mautrix 0.16

Not much to see here. A small contribution release which is always a nice thing when people come around and help 🤗.

Go and get some ☀️ sunlight from GitHub, PyPI or matrix-docker-ansible-deploy!

Thanks!

🔗Dept of Clients 📱

🔗Sailtrix (website)

Sailtrix is a matrix client for SailfishOS

HengYeDev says

Summary of development this week

• Sailtrix is fixed on Sailfish 4.4, which added sandboxing to all apps
• Sorting is fixed in the favorites tab
• The create room dialog is fixed
• Some validation is added to the login page
• Sharing with other apps and bluetooth is added for newer Sailfish versions
• SSO seems to be working, still in testing

🔗Element (website)

Everything related to Element but not strictly bound to a client

kittykat announces

Location sharing

• As a follow on from our previous launches, the team is building “live location sharing”. This will allow you to automatically share where you are in the world with others for a period you choose (15 minutes, 1 hour, or 8 hours), instead of sending a single static location.

Community testing

• We ran our first async community testing session this week. Thank you all who joined in! We found 13 issues so far, which is good going.
• We have some new features landing for the search experience on Web, join us for testing from Thursday!
• You can join us at #element-community-testing:matrix.org to find out more!

🔗Element Web/Desktop (website)

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

Danielle says

• Threads is in Beta! The team is hard at work smashing bugs and improving notifications so that we can remove the beta label and get everybody access to our new feature!
  • If you’re using Threads, don’t forget to give us your feedback.
• This week the team discussed how our Web product looks and feels to new users. While we use our own products all the time, it can be good to take a step back and ensure that our product decisions benefit all users, including the newbies. Watch this space for more info in the coming weeks as we continue to trial things that we hope will make onboarding to Element easier.
• In labs (you can enable labs in settings on develop.element.io or on Nightly)
  • Video rooms are coming together nicely, with the addition of lobby screens and room list stickiness to wrap up the design implementation

🔗Element iOS (website)

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

Manu announces

• The newest version of the app (1.8.13) is ready! In this release we’ve made a bunch of improvements and bug fixes, check it out here.
  • Our favourites include: Force touching room previews no longer update your read receipts, there’s a congratulations screen for new users when creating an account, and we’ve reduced the number of home page reloads.
• Also new in product are presence indicators! From your home page or DMs you’ll be able to see if a user is present or away. Note; this is only supported if your homeserver has it enabled.
• Upcoming; We’re working on adding ‘mention pills’ when tagging users in a room.
• Please note; We’ll soon be removing support for iOS 12 and iOS 13

🔗Element Android (website)

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

benoit says

• The team is working on fixing bugs and making improvements to flows like “ignore user”. We’ve also made some changes to the way we format code.
• Element Android 1.4.12 is ready to be released but currently on hold in the Play Store due to rules around User Generated Content (UGC). We’re chatting with Google and the new update should be available soon.

🔗Dept of Non Chat Clients 🎛️

🔗Populus Viewer (website)

A Social Annotation Tool Powered by Matrix

gleachkr says

We've added two major user-facing features to populus viewer:

1. A two-up view in the pdf viewer, allowing you to view and annotate two pages at once on a wider screen
2. An audio viewer, complete with audio annotation, so that you can annotate temporal segments of an audio recording

I'm especially excited about the latter - being able to discuss audio recordings will be a great teaching tool, and I'm hoping it might also be useful for things like people who want to talk about podcasts together (for purposes of editing, or just for fun), and people who want to annotate recordings of public talks of various kinds. The last use case would also be pretty well served by video annotation - so that's now rising on the agenda. I've created an MSC, here where I'll be filling in the details of a proposed format for interoperable audiovisual media annotations. As always, if you've got questions, want to follow development progress, or just want to talk about the future of social annotation on Matrix, come join us at #opentower:matrix.org.

🔗nheko-krunner (website)

A KRunner plugin to list joined rooms and possibly other things from nheko.

LorenDB says

nheko-krunner has finally been released! Version 0.1.0 contains several handy features such as searching your rooms, joining new rooms, and starting and switching to direct chats. Furthermore, if a room has unread notifications, nheko-krunner will let you know by tacking on a notification count to the room name (e.g. This Week in Matrix (TWIM) (1). Currently this feature is not disable-able, but I plan to dive into writing KCMs (KConfig Modules) soon so that I can add a toggle for this.

Hopefully a few people find this handy, and remember that if you don't use KDE, nheko still has a handy D-Bus API that you can use to write integrations with other software.

🔗Dept of SDKs and Frameworks 🧰

🔗matrix-rust-sdk (website)

Matrix Client-Server SDK for Rust

Jonas Platte says

Over the last weeks, we've been doing a lot of refactoring in preparation for the 0.5.0 release, but we also

• Added support for retrieving room account data
• Made it easier to create a client while being offline
• Fixed a rare bug with SSO login (localhost didn't always resolve, so we switched to 127.0.0.1)
• We made some progress on sliding sync and adding an FFI interface for the main matrix-sdk crate

🔗Matrix Dart SDK (website)

Matrix SDK written in pure Dart.

Henri Carnot [famedly] says

We haven't done any regular posts about it in a while, but the SDK sees almost weekly releases. (We did release version 0.8.20 last week) If you forgot about it, the Matrix Dart SDK is the SDK FluffyChat, the Famedly clients and a few others use. Let me summarize some of the changes for those who haven't kept up:

One of the killer features is probably WebRTC support 🚀. It handles all the signalling for you, which makes integrating call support into your Flutter or Dart Matrix client fairly simple. Currently it supports version 1 of the call protocol, which is still an MSC and implements a few of the other MSCs. Experiments with group calls are still in progress.

We also switched databases a few times and tuned it more (we posted about FluffyBox last year). The database backend should now be a lot more stable and more performant, while also using less memory.

Continuing with stability, we worked a lot on how the timeline is stored and structured, leading to a much more robust experience. The SDK is also now completely nullsafe 🎉, which gets rid of a lot of annoying error modes. There were some fixes to E2EE here and there, but mostly the experience has been really solid and didn't need much work.

Some of the more recent developments include widget support as well as improving the file upload experience. The SDK now inserts a dummy event for a pending upload, images are thumbnailed and resided in a different isolate and uploads are automatically retried after a connection failure. We are also working on improving the push support, making it easier to fetch events from a push.

And I'm currently working on bringing fragmented timeline support. Nico told me it would be pretty (not) easy to do... and I have to say, he was right. Good first issue 🙃

See you next week ;)

🔗Dept of Ops 🛠

🔗Nix-matrix-appservices

Pacman99 announces

I've created a NixOS module, nix-matrix-appservices, that can simplify the bootstrap and maintenance of matrix appservices on nixos. With it, appservices can be spun up easily with registration and tokens handled by the module. Most mautrix and mx-puppet bridges have been tested to work and they can be setup in a couple lines of nix code. There are plenty of options you can make use of to configure more complex appservices. You can find the the code, matrix room(gitlab badge), and usage information here: https://gitlab.com/coffeetables/nix-matrix-appservices

🔗Synatainer (website)

Synapse Maintenance Container – Docker container with tools for synapse & postgres database maintenance

saces announces

Synatainer v0.4.0

New since v0.3.x

• autocompressor have only one setting
• add a golang tool stui - synatainer terminal ui
• replace the vacuum shell script with stui

stui is a typical golang binary, it's also available as stand alone version from the release page

For now it can only do a full vacuum and show some rugged formatted database info

[docker run -it --rm registry.gitlab.com/mb-saces/synatainer:latest] stui vacuum-db --help
[docker run -it --rm registry.gitlab.com/mb-saces/synatainer:latest] stui db-info

The doc have a lot of space for improvements…

---

Start the container without command and let do its magic :)

What it does by default:

• daily:
  • purge all rooms without local members
  • run the state autocompressor (500/100)
• weekly:
  • delete old remote media (>90 days)
  • delete old message history from public joinable rooms (>180 days)
• monthly:
  • vacuum the database

Source: https://gitlab.com/mb-saces/synatainer

Room: #synatainer:c-base.org

Compose example: https://gitlab.com/mb-saces/synatainer/-/snippets/2264828

---

If you are looking for a docker container with just the auto compressor for linux amd64/arm64 in it, her you go: https://gitlab.com/mb-saces/rust-synapse-compress-state

🔗matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi announces

Thanks to Julian-Samuel Gebühr (@moan0s) - moanos [he/him], matrix-docker-ansible-deploy can now help you set up matrix-registration-bot - a bot that is used to create and manage registration tokens for a Matrix server.

See our Setting up matrix-registration-bot documentation to get started.

Slavi says

Thanks to Aine of etke.cc, matrix-docker-ansible-deploy can now set up Borg backups with borgmatic of your Matrix server.

See our Setting up borg backup documentation to get started.

🔗Dept of Interesting Projects 🛰️

🔗MinesTRIX (website)

A privacy focused social media based on MATRIX

Henri Carnot announces

just did release V.1.5.5 today, this is the last update since a few months ago.

Some of the changes are:

• feat: compliance to the latest version of MSC3639: Matrix for the social media use case
• feat: added images support for posts. You can now send multiple images in a post and display them in a gallery view.
• feat: New emoji picker, you can now select and react to message in one continuous press.
• feat: Comments nesting, (using threads)
• feat: Image comment (read only :()
• feat: Dark theme support
• feat: New settings page (added a lab section :D, seems you need to have one if you want to build a proper Matrix client)
• feat: proper emoji support for desktop. Thanks fluffychat :)
• feat: Initial story support
• feat: various UI enhancements.

Concerning the messaging feature:

• feat: Initial poll support
• feat: read only spaces support
• feat: room list search box
• feat: chat settings dialog
• feat: read receipts list dialog
• feat: reaction list dialog
• feat: now use rounded avatar. Let's be consistent with other clients.
• feat: better display for replies and m.notice.
• feat: Localization support thanks to the Matrix Dart SDK

And some work already in for multiple profiles support, and profile as space (just use a public space to store your profile rooms).

If you are interested, come say hi in the room.

PS: You can also help us to design the underlying MSC, especially, we need some opinions on how to name things (the profile rooms) the room !!

🔗Dept of Ping 🏓

We know you missed it, here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	envs.net	359.5
2	intothecyber.space	443
3	tedomum.net	468
4	maescool.be	693
5	jeroenhd.nl	729
6	jauriarts.org	734
7	alemann.dev	855.5
8	nevarro.space	969
9	0wnz.at	998
10	quyo.de	1494

🔗#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	nognu.de	278
2	cry.is	391
3	rustybever.be	558
4	sspaeth.de	700.5
5	beckmeyer.us	911
6	grin.hu	981

🔗That's all I know 🏁

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

Hey everyone! Guess what? Synapse 1.57 has just been released! Let's see what's new in this version!

🔗Application services

Application services are piece of software that have privileged access to some of the homeserver's features. For example, they can create and manage multiple users at the same time, which is especially useful for bridges.

This release of Synapse changes the way Synapse manually manages transaction identifiers when talking to application services (a transaction being a group of events the application service should know about). While this doesn't have much impact on the everyday life of a server administrator (besides fixing a bug and paving the way for future performance improvements), this change means server admins should take extra care when updating Synapse.

More specifically, if you are running a dedicated Synapse worker for handling traffic related to application services, this worker must be stopped when upgrading the main Synapse process to ensure the update is performed safely. See the upgrade notes for more information about this change, and instructions on recovering from an incorrect upgrade.

This release of Synapse also continues work on bringing end-to-end capabilities to application services, which I was already telling you about in the Synapse 1.50 release blog post. More specifically, Synapse now supports sending device list updates to applications services, as part of implementing MSC3202. This is still very experimental and definitely not production ready, but also very exciting!

🔗Improvements to the module system

Modules allow third-party developers to expand Synapse with extra features that wouldn't necessarily fit into the Matrix specification and/or ecosystem. In the past release of Synapse, we have been improving this system to add more functionality to it, and this one is no exception!

Synapse modules can now implement new callbacks to react to account data updates, as well as to react to new 3PID (email address, phone number) associations. On the latter, note that this callback will only be called after a 3PID has been validated on the homeserver, and does not trigger when the validation happens on an identity server (e.g. when publishing a 3PID so that other users can look it up).

The ModuleApi (which is the Python class enabling modules to interact with Synapse) has also been updated to allow module to read and write global account data. This can be done by using the new AccountDataManager class, which can be accessed as api.account_data_manager (where api is an instance of ModuleApi).

The module API has also been updated with a new method, to allow modules to promote an existing user to server administrator (or demote a server administrator to a normal user). This follows up on an improvement introduced in Synapse 1.56 allowing modules to promote users to server administrators when registering them.

🔗Everything else

This release also includes a performance improvement for workers handling /sync requests. While this change makes starting this kind of workers slightly more heavy performance-wise, it aims at improving the load associated with the first /sync requests hitting it right after starting. See this comment for more details.

Synapse 1.57 also now includes bundled aggregations in message search results by default, as MSC3666 has been accepted and has finished its final comment period.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Famedly and Jorge Florian.

🔗Dept of Servers 🏢

🔗Conduit (website)

cel says

• Gained v9 room support on next branch: https://gitlab.com/famedly/conduit/-/merge_requests/257
  • Binaries available here: https://gitlab.com/famedly/conduit/-/blob/next/DEPLOY.md#installing-conduit
  • v9 rooms enable private rooms to allow access to members of a Space or other room without a separate invite.

🔗Synapse (website)

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

dmr reports

Hello everyone. This week the Synapse team cut a release candidate for Synapse 1.57. It contains:

• Continued work on the faster joins project.
• Additional Module API support for working with 3PID associations, account data changes and making users admins. The first two in particular are vital to to merge the DINSIC fork of Synapse into the mainline source tree.
• Experimental, partial support for MSC3202, Encrypted Appservices; additional support for threads via MSC3666 and via MSC2675.
• Plus a number of bugfixes within Synapse and fixes for spec compliance issues.

As ever, our warmest thanks to to our contributors for sharing their time, effort and expertise with the project. We look forward to seeing your work in the wild, come the 1.57 release proper on Tuesday the 19th of April.

On develop, we have been powering through a number of different tasks:

• further work on fast room joins;
• efforts to better document Synapse's config file;
• strides towards making Synapse's requests internally cancellable;
• performance improvements for device list updates; and
• another spurt of work to get complement (finally!) testing Synapse in worker mode.

Speaking personally, my efforts to manage Synapse's dependencies using poetry are coming to a close. As I write this, I've just submitted my last (planned!) PR for this project. It's been several months in progress now, and there were many moving parts; some unexpected bugs in poetry and even one in pip; plus a heck of a lot of CI config to change and understand. My sincere thanks to the broader Synapse team for their help in getting the last batch of changes made, reviewed and merged. Once this is all said and done I hope we'll all reap the benefits of

• a stabler CI pipeline,
• reproducible virtual environments in our docker and debian images, and
• automated PRs for security updates.

🔗Dept of Bridges 🌉

🔗matrix-hookshot 1.5.0 (website)

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

Half-Shot reports

Hey webhook-consuming-people! The hookshot webhook bridge 1.5.0 update has now been released. This release is a bit softer than 1.4.0, containing some smaller features and bugfixes. Thanks to everyone who contributed!. The highlights are:

• Allow specifying msgtype for generic webhook transformations. (#282)
• Add new GitHubRepo config optionnewIssue.labels which allows admins to automatically set labels on new issues. (#292)
• Allow priority ordering of connection command handling by setting apriority: number key in the state event content. (#293)
• Support GitLabpush webhook events (#306)

The matrix-docker-ansible-deploy playbooks have also been updated to be 1.5.0 compatible :)

🔗matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports:

A Matrix-KakaoTalk puppeting bridge.

This week brings many new features:

• KT<-> Matrix message deletion/redaction
  • Note that KT doesn't allow deleting a message if it's too old, so Matrix->KT redactions will fail for old messages.
• KT->Matrix user name/avatar live updates
  • As opposed to only being updated on backfill / manual sync
• KT<->Matrix read receipts
  • Caveat: KT->Matrix read receipts are only updated live, not on backfill / manual sync
• KT->Matrix member join/leave
  • Only joins were tested so far, but leaves should work too
• KT<->Matrix admin status / power levels
• KT->Matrix channel name, description, and cover photo
• General stability & usability improvements
• systemd setup instructions

I've also launched an instance of the bridge & opened a public portal room for testing purposes:

• Matrix side: #kakaotalk-bridge-testing:miscworks.net
• KakaoTalk side: https://open.kakao.com/o/gjGQFuae

Logging in to my bridge instance is restricted, but Matrix users can still join the room thanks to the magic of relaying!

At this point, I'd say the bridge is now fairly usable. Please try self-hosting if interested!

Discussion: #matrix-appservice-kakaotalk:miscworks.net Issue page: https://src.miscworks.net/fair/matrix-appservice-kakaotalk/issues

🔗Dept of Clients 📱

Matthew reports

A new GTK4 matrix client called gotktrix surfaced on HN, written in Go with a bespoke matrix client SDK implementation. Looks impressive!

🔗Nheko (website)

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

Nico reports

After a long and arduous journey, LorenDB's dbus interface for Nheko got finally merged. Currently this allows you to list rooms as well as switch between them. In the future we might add simple messaging support, so that you can automatically send messages into specific rooms using scripts. The API is disabled by default, since it is not authenticated. Enable it at your own risk!

Another long standing PR, that finally got merged, was MTRNord (they/them)'s support for pretty power level formatting. Nheko can now tell you what changed in a power level instead of just telling you that it changed. This should make them much more accessible to users, that don't like looking at the raw event source all the time (weird, eh?).

The image viewer should also be more reliable now and notification counts should be correct after a restart.

We have also been playing around with qt6 support. At this point we have a working Qt6 branch, with a few functional regressions:

• No voip (gstreamer has no Qt6 support yet)
• No drop shadows on buttons
• No switchable color schemes

So far Qt6 looks pretty great and seems to fix a lot of the minor annoyances.

We are also still looking for some student or interested individuum to take part in the Google Summer of Code and improve the call support in Nheko! Deadline is drawing close, so if you intend to apply, better work on your proposal quickly! If you need any feedback for your proposal, feel free to DM me and ask me to review it/questions. I'm looking forward to someone applying! <3

Anyway, merry christmas everyone or whatever you are celebrating this weekend!

🔗Element Web/Desktop (website)

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

kittykat announces

• Threads Beta is live, find it in Labs!
  • As always, check it out and let us know what you think.
• We’re aligning on a style guide and a new module system (links will be shared once both are finalised)
• Added our first Cypress test - this will improve how we create and run e2e (end to end) tests. The tests will continue to be run by CI.
• In labs (you can enable labs in settings on develop.element.io or on Nightly)
  • Continuing to get a native lobby screen for video rooms together

🔗Element iOS (website)

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

Manu announces

• We will inform users in the next release that we will no longer support iOS12 and 13. It will be effective the release after, i.e. April 25th.
• We had a big drop on UTDs (Unable to Decrypt errors) since 1.8.8.
• We are setting up the ElementX-iOS project to rewrite the Element-iOS app. It will be based on SwiftUI and the Matrix Rust SDK. The roadmap is available here.

🔗Element Android (website)

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

kittykat says

• Element 1.4.11 is available on the PlayStore and on F-Droid. Release notes: https://github.com/vector-im/element-android/releases
• We may experience some delays in shipping the app through the Android PlayStore as we are in discussions about whether not decrypted messages should be reportable
• Cleanup to the SDK API has landed on develop - this will help with generating API documentation and migrating to the Rust SDK
• Roadmap for migration to the Rust SDK

🔗Element (website)

Everything related to Element but not strictly bound to a client

kittykat announces

Threaded Messaging

• Exciting news this week; the Threads Beta is live on all platforms! If you haven’t seen Threads yet, head to Settings > Labs and check it out.
  • Please note; If your homeserver doesn’t yet support threads functionality you may not see the beta, or your experience will be degraded. If this applies to you, you’ll see a warning message before you activate Threads.
• The team is continuing to squash bugs and improve performance, we’ve also started working on the next improvements…
• Notifications and badges are top of mind for us next. We need to ensure accuracy of badge counters and consistency between platforms (if you use more than one). We’re looking at this now so keep your eyes peeled for our upcoming MSCs.

Community testing sessions

• We are restarting our testing sessions! Join #element-community-testing:matrix.org to take part
• We are trying out a new asynchronous format with office hours for discussion to enable more people to be involved

🔗Dept of Encryption 🔐

🔗libolm

uhoreg reports:

libolm 3.2.11 has been released. This release mainly features improvements to the Objective-C and Java bindings, but also fixes building of the documentation, which was broken for quite a while. For more details, see the release notes.

🔗Dept of SDKs and Frameworks 🧰

🔗Ruma (website)

A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.

Jonas Platte says

Over the last two weeks, we have been busy working towards the 0.6.0 crates.io release of Ruma. If things go to plan, it should be published in the coming weeks (but no promises). That means mostly finishing some large refactorings, but we also got some bug fixes in, as well as a number of convenience functions for working with certain events:

• Add RoomPowerLevelsEvent::power_levels
• Add convenience methods
• Add transaction_id accessors
• Add convenience constructors for threads

🔗Dept of Internet of Things 💡

🔗HASSkbot - Home-Assistant ask bot

Oleg reports

HASSkbot can be used to control an action in Home-Assistant via Matrix reactions.

It's an Opsdroid bot, which reacts to a home-assistant entity state change (like person leaving a zone) and asks for confirmation in Matrix if it should run additional home-assistant automation. Matrix reactions are used for confirming or canceling an action.

🔗Dept of Bots 🤖

Arya K reports

Merseklo is now out of beta it is a moderation bot for matrix written in pure bash with the only deps being jq and curl

🔗Honoroit (website)

A Matrix helpdesk bot

Aine reports

benpa is back in town and I can't keep silence: here is a small update on Honoroit - v0.9.6 comes with "stable spaces" support that will work with new versions of element (yes, even on Element Android from F-Droid).

Go check the source code and say hi in the #honoroit:etke.cc

🔗Dept of Events and Talks 🗣️

🔗DWeb Camp

cel reports

DWeb Camp 2022 website and registration launched: https://dwebcamp.org/

• August 22-24 BUILD; August 24-28 CAMP; Aug 28-29 TAKE DOWN.
• Camp Navarro, CA, USA
• Announcement: https://matrix.to/#/!WBhcGXTDMlzyTPWoJv:matrix.org/$164991727237835sdywy:matrix.org
• Volunteer: https://dwebcamp.org/participate/
• Apply for fellowship: https://dwebcamp.org/fellowships/
• Sponsor: PDF

DWeb Camp is a gathering hosted by Internet Archive and volunteers dedicated to Decentralized/Distributed web projects. Previously it happened in 2019, and Matrix had some presence there. Maybe people from Matrix projects and/or Matrix.org will be there this year?

🔗That's all I know 🏁

Come back next week for a much restored TWIM! With Matrix Live, Spec updates, Dept of Ping and so on. :D

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

🔗Matrix Live 🎙

🔗Dept of Status of Matrix 🌡️

Matthew announces

https://arewep2pyet.com is finally here as a tracker for our progress on P2P Matrix

🔗Dept of Spec 📜

TravisR 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://matrix.org/docs/spec/proposals.

🔗MSC Status

Merged MSCs:

• No MSCs were merged this week.

MSCs in Final Comment Period:

• MSC3700: Deprecate plaintext sender key (merge)
• MSC3666: Bundled aggregations for server side search (merge)

New MSCs:

• MSC3767: Time based notification filtering
• MSC3765: Rich text in room topics

🔗Spec Core Team

In terms of Spec Core Team MSC focus for this week, we've been largely looking at proposals which are at or near FCP in an effort to get them through the last stages of the process. We're also thinking about what the next release (v1.3) looks like and when we'll end up putting it out into the world. If you have MSCs which you'd like included, please stop by the #sct-office:matrix.org on Matrix with your suggestions - if they're near enough, we'll try to get them in.

🔗Random MSC of the week

The script has elected MSC3391: Removing account data as the random MSC this week. It's a small but interesting MSC which helps clean up account data on the server when it's no longer needed, though how this sort of removal gets represented to clients can be a challenge. It's currently missing an implementation if someone is looking for a medium complexity contribution this weekend 😉

🔗The Chart

So many MSCs are in the open state, which is why we're continually looking at merging MSCs which are ready to go.

🔗Dept of Servers 🏢

🔗Synapse (website)

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

Brendan Abolivier reports

This week, we've released Synapse 1.56! It includes only a couple of new features but quite a few bug fixes and internal improvements. One of the main changes included in this version is that Synapse will now refuse to start if configured with open registration with no verification (e.g. email, recaptcha, etc). This is an attempt at reducing the likelihood of spam across the federation, as most cases of abuse we've observed over time usually involves the attacker(s) finding homeservers with open registration and automatically creating a lot of accounts on them in order to evade sanctions.

This version of Synapse also deprecates the groups/communities feature of Matrix. This is a feature we introduced back in 2017, and was the predecessor of Matrix spaces. But now that it has been mostly replaced by spaces, we have decided to retire this feature, which we thank dearly for its 4 years of good and loyal service to the federation.

Read all about this, and more, in the release announcement on the Matrix.org blog! 🙂

🔗Dendrite / gomatrixserverlib (website)

Second generation Matrix homeserver

neilalexander announces

This week we released Dendrite 0.8.0, which is primarily a feature release, and then Dendrite 0.8.1 which fixes an emergency bug. It's also a recommended upgrade if you are running a Dendrite deployment. It includes:

• Support for presence has been added

  • Presence is not enabled by default
  • The global.presence.enable_inbound and global.presence.enable_outbound configuration options allow configuring inbound and outbound presence separately

• Support for room upgrades via the /room/{roomID}/upgrade endpoint has been added (contributed by DavidSpenler, alexkursell)

• Support for ignoring users has been added

• Joined and invite user counts are now sent in the /sync room summaries

• Queued federation and stale device list updates will now be staggered at startup over an up-to 2 minute warm-up period, rather than happening all at once

• Memory pressure created by the sync notifier has been reduced

• The EDU server component has now been removed, with the work being moved to more relevant components

• It is now possible to set the power_level_content_override when creating a room to include power levels over 100

• /send_join and /state responses will now not unmarshal the JSON twice

• The stream event consumer for push notifications will no longer request membership events that are irrelevant

• Appservices will no longer incorrectly receive state events twice

Our sytest compliance numbers are now:

• Client-server APIs: 83%
• Server-server APIs: 95%

As always, join us in #dendrite:matrix.org for more news and discussion.

🔗Dept of Bridges 🌉

🔗matrix-hookshot (website)

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

Half-Shot says

🔗Matrix-Hookshot: The one with the widgets release

Hello webhook fans! As teased last week, configuration widgets have landed in hookshot! 1.4.0 now contains all you need to setup your very own webhooks without having to leave the comfort of your GUI. The plan is for widgets to be greatly expanded over the new few releases to support more services. Eventually, this work is going to propagate out to other matrix.org bridgey projects 🌉.

The full feature list for this release looks a bit like:

• Add support for configuring generic webhooks via widgets. (#140)
• Show the closing comments on closed GitHub PRs. (#262)
• Webhooks created via !hookshot webhook now have their secret URLs sent to the admin room with the user, rather than posted in the bridged room. (#265)
• Automatically link GitHub issues and pull requests when an issue number is mentioned (by default, using the # prefix). (#277)
• Support GitLab release webhook events. (#278)

Update away, and let me know how you get on.

🔗matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports:

A Matrix-KakaoTalk puppeting bridge.

Many updates this week! New features include:

• Mentions & replies, both incoming & outgoing
  • Small exception: Matrix->KT replies don't yet work in KT "open channels" yet.
• Ability to create a portal by inviting a KT puppet to a DM
  • Note that this currently only works for KT direct chat channels that already exist & have been active recently.
• Connection resilience between the Python and Node components of the bridge
  • i.e. If the Node component ever exits & restarts, the Python component will reconnect to it automatically. This helps both with deployment (since it allows the components to be started in any order) and crash tolerance (since a Node crash & restart no longer requires a manual restart of the Python component)
• Clear warnings when receiving a KT message that the bridge doesn't yet support

At this point, the bridge should be fairly usable now. Very soon I'll open a Matrix-bridged KT channel to act as a public stress-test!

Discussion: #matrix-appservice-kakaotalk:miscworks.net Issue page: https://src.miscworks.net/fair/matrix-appservice-kakaotalk/issues

🔗Heisenbridge (website)

Heisenbridge is a bouncer-style Matrix IRC bridge.

hifi reports

Heisenbridge roundup!

Heisenbridge is a bouncer-style Matrix IRC bridge.

Release v1.11.0 🥳

• Fixed retry behavior on startup to wait for HS startup
• Ignore TAGMSG messages from IRC server
• Fixed HTML messages not working as commands
• Fixed room aliases in messages dropping the message completely
• Upgrade to Mautrix 0.15

Just your typical bug fix release but this release also breaks support for homeservers not supporting the "v3" API path so if you run Synapse 1.47 or older the bridge will not start. Sorry.

Go and get some spring cleaning from GitHub, PyPI or matrix-docker-ansible-deploy!

Thanks!

🔗Dept of Clients 📱

🔗Thunderbird

freaktechnik reports

Thunderbird is a free open-source email, calendar & chat app.

The latest Thunderbird beta finally has Matrix support enabled by default. Get Thunderbird beta now to try it out. There have been many improvements to the Matrix implementation since the last update, including:

• Almost complete end-to-end encryption support
• Support for displaying formatted messages
• .well-known home server discovery
• Message redactions
• Now all room invites let you respond
• Lazy loading room members

🔗Element Web/Desktop

kittykat reports

• We removed skinning! It won’t be in the release this week, but will land in 2 weeks (roughly). If you notice bugs, please report them!
• Threads Beta went into the RC!
• Looking at a module system for extending functionality - if you have modules we haven’t talked about, come by #element-dev:matrix.org to let us know.
• In labs (you can enable labs in settings on develop.element.io or on Nightly)
  • Work on video rooms continues, and we’re exploring how we can make them feel more native.

🔗Syphon (website)

Chat with your privacy and freedom intact

0x1a8510f2 says

Syphon is a Matrix client with heavy emphasis on privacy and ease of use; currently in open alpha.

Hi all 👋.

We released 0.2.13 this week mainly fixing an annoying bug that could cause messages sent while a configured proxy server was down to be re-sent multiple times once the proxy came back online. If you use a proxy with Syphon, this update is highly recommended!

In addition, this release will only show the option to use hidden read receipts if the feature is supported by your server.

Finally, a range of translation updates and improvements are included in this release.

More changes are coming soon, including a (currently work-in-progress) implementation of MSC2228 (self destructing events). As far as we know, we're on track to be the first user-facing implementation of this MSC, putting Syphon on the bleeding edge of Matrix!

🔗Nheko (website)

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

Nico reports

Thanks to the awesome polyjuice client, Nheko now supports MSC3700, which slightly improves privacy in encrypted rooms. It also lead to us fixing issues with the secure symmetric secret storage, where some clients use a different base64 encoding than recommended in the spec, which could make unlocking the secrets with a recovery key or passphrase fail. And we also improved the key queries on initial login, which would sometimes fail to_device messages with a warning, that the device is unknown.

As a small feature, you can now close the currently open room using Ctrl-W, spaces are not treated as DMs under some circumstances anymore, you should get a less confusing error message than 500 when entering an invalid alias now and lots of fixes to the translations.

Thank you, LorenDB, Apurv and Mikaela for the contributions!

🔗Hydrogen (website)

Hydrogen is a lightweight matrix client with legacy and mobile browser support

Bruno reports

Have released the SDK, v0.0.10 with custom tiles support. Calls and theming are getting closer, the latter we were planning to release this week but hit a blocker for theming support in develop mode, so we'll have to postpone to next week.

🔗Element iOS (website)

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

Manu announces

• Considering dropping support for iOS12 - this will impact 0.9% of sessions. Requiring iOS 13 or newer will allow us to use SwiftUI libraries.
• You will be able to opt in to threads in the next release (currently in testing), alongside updates to room preview on long press in room list, ability to share any location and support for more languages

🔗Element Android (website)

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

benoit reports

• Release candidate 1.4.11 is currently available on the PlayStore if you are a tester. Should be pushed to production next Monday! F-Droid publication is in progress too. Learn more about the full release content here: https://github.com/vector-im/element-android/releases
• Add banner to timeline when location sharing is running. Live Location Sharing (a.k.a. LLS) is still a work in progress and not available in the Element app yet.
• Improved unit test coverage (especially around login with MXID)
• Improved how threads look in the main timeline
• Add notification for users to opt in to threads
• Polishing around spaces to bring them into line with latest designs
• Hotfix for leaving all rooms in a space without leaving the DMs. The hotfix is included in the release candidate 1.4.11.
• We are considering modifying our rules to format source code. We will try to limit the impact on forks, but it will not be easy.

🔗Dept of Non Chat Clients 🎛️

🔗Populus Viewer (website)

A Social Annotation Tool Powered by Matrix

gleachkr reports

Since last time, we've made a lot of small quality-of-life improvements, but a few changes that stand out are:

1. We've improved support for offline PWA usage.
2. We've improved caching of space contents, reducing the number of times that we need to hit the spaceHierarchy endpoint and improving performance.
3. We've moved to a more in-the-spirit-of-the-spec way of handling hidden annotations: these are now represented by rooms with an m.space.parent event, and no correpsponding m.space.child event in the resource-space.
4. We've added a modal for viewing image messages at full-size.

Number 4 works nicely with my teaching-assistant-bot (built with matrix-bot-sdk, mathjs, and chartjs), which helps me visualize information about student activity.

MSC3752 - Markup Locations for Text, has also filled out quite a bit! Implementation coming soon hopefully.

As always, if you'd like to learn more, or talk about the future of social annotation at matrix, come join us at #opentower:matrix.org!

🔗Matrix Highlight (website)

A decentralized and federated way of annotating the web based on Matrix.

Daniel announces

Matrix highlight saw some "under the hood" changes this week, in particular a refactor to rely less on the Chrome/Firefox extension API. This should make it possible (in theory, and with some more work) to run Matrix Highlight on pages without installing anything! Aside from the obvious, I think that there are additional use cases opened up by this change; one such case I have in mind is as a commenting system on a site (a la cactus comments, but with the ability to highlight page snippets!).

In the process of all of this, I've spent some time running Matrix Highlight in Firefox. I've encountered no issues during this time, so it seems like the tool is usable from FF, too.

🔗Dept of SDKs and Frameworks 🧰

🔗Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict reports

Trixnity 2.0.0-RC1 has been released. This release candidate contains many breaking changes due to a large refactoring, which allows us to share a lot code between server and client implementations of the Matrix APIs. Yes, that means Trixnity can be used to implement a matrix server! We also made some progress to make the client module (with all the high level logic) multiplaform. This is the only module, which does not support Kotlin/Native and Kotlin/JS yet. There are many other features (like client-side notifications!), which has been added. See the changelog for more details:

features/improvements:

• clientserverapi-server: new module for server-side REST endpoints of the Client-Server-API (Server-Server-API will follow soon)
• olm: libolm is bundled into trixnity-olm jars
• client: push notification support (push rules are evaluated)
• client: introduce helpers to get complete timeline as flow (no more complicated loops to get the timeline)
• client: allow subscribing to all timeline events -> really helpful for bots with e2e support
• client: allow to sync once (e. g. for push notifications)
• client: content field of TimelineEvent gets also set for unencrypted events
• client: public access to keys
• clientserverapi-model: allow custom field in pusher data
• core: introduce BaseEventContentSerializerMappings

bugfixes:

• client: remove direct room, when other user leaves room
• client: change varchar length to support MariaDB
• clientserverapi-client: first sync after pause without timeout

🔗simplematrixbotlib (website)

simplematrixbotlib is an easy to use bot library for the Matrix ecosystem written in Python and based on matrix-nio.

krazykirby99999 says:

An easy to use bot library for the Matrix ecosystem written in Python. https://matrix.to/#/#simplematrixbotlib:matrix.org

🔗Version v2.6.3 Released!

🔗2022-04-06 5f54f69

🔗Notes:

• The command matcher now has support for case-insensitive matches.

🔗Additions:

• Add case insensitive option to command matcher

🔗Modifications

• Update Pillow Dependency to version 9.0.1

🔗Removals:

• None

🔗Deprecations

• None

🔗Polyjuice (website)

Elixir libraries related to the Matrix communications protocol.

uhoreg announces

Polyjuice Client Test is a testing tool for Matrix clients. Since the last TWIM update,

• two new tests have been added: key history sharing (MSC3061) and no plaintext sender key (MSC3700).
• more clients endpoints have been implemented or stubbed. This has improved compatibility with some Matrix clients, and reduced noise in the logs.
• the deployment at https://test.uhoreg.ca/ now automatically runs the latest version from git. This Matrix-based continuous deployment is powered by another personal side-project, which will be revealed in the future.
• the UI is now significant less ugly (unless you hate purple, in which case you may find it more ugly).
• #polyjuice:uhoreg.ca now exists for discussing anything related to the Polyjuice project

🔗Dept of Ping 🏓

Dept of Ping will return!

🔗That's all I know 🏁

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

Happy release day everyone! Synapse 1.56 is out! Let's have a look at what's new in this release.

🔗Additional restrictions around registration

One common abuse scenario we have seen on Matrix over the years is attackers making use of public homeservers with open registration to automatically create multiple accounts in order to evade sanctions. Sometimes, this can lead to these public homeservers being banned across multiple public rooms despite their administrator(s) not being directly at fault.

In order to mitigate this, starting from this release, Synapse will refuse to start by default if it is configured with open registration with no additional verification. This means users wishing to register on these homeservers will need to authenticate themselves, either via email, recaptcha or registration tokens.

Please see the upgrade notes for more information.

🔗So long groups, and thanks for all the fish

Long-time users of Matrix might remember when, way back in 2017, we introduced groups (also known as communities in some clients). Groups would let users define a curated set of users and rooms to represent a given community that others could refer to. We even used to have +matrix:matrix.org which was the official group for the Matrix team and community.

If this sounds a bit familiar to you (and remind you of a certain other feature of Matrix), that's no coincidence. Some time ago, we had already identified a good amount of shortcomings with groups, and decided to redesign the feature entirely and release it under the name "spaces". If you're curious about this, then you may wish to read the spaces announcement blogpost we released at the time.

Now that spaces have been out of beta for some time, and have shown to be a very useful feature to the ecosystem, we decided it was time to retire support for groups from Synapse, after more than 4 years of good and loyal service. This release of Synapse deprecates the feature, with a plan to disable it by default in Synapse 1.58 (which is expected to be released next month).

🔗Everything else

As of this version, Synapse will also refuse to start the if the Postgres database it is running against has a non-C locale, in order to prevent accidental database corruption. See the upgrade notes for more information.

This release also includes the ability for modules to register server administrators through the register_user method, as well as a new method to allow modules to store external 3PID associations into Synapse's database.

See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Dirk Klimpel, Beeper, Famedly, IronTooch and villepeh.

🔗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://matrix.org/docs/spec/proposals.

🔗MSC Status

New MSCs:

• MSC3761: State event change control
• MSC3760: State sub-keys
• MSC3759: Leave event metadata for deactivated users
• MSC3758: Expand push rule conditions
• MSC3757: Restricting who can overwrite a state event

MSCs in Final Comment Period:

• No MSCs are in FCP.

MSCs with Proposed Final Comment Period:

• No MSCs had FCP proposed this week.

Merged MSCs:

• MSC3667: Enforce integer power levels

🔗Spec Updates

There's been lots of new MSCs this week! Three of them - those regarding state restrictions and subkeys - are related to the ongoing live location sharing work that Element is currently working on. See MSC3672 for the current state of the spec work for that feature.

Otherwise the spec core team has been reviewing a flurry of MSCs this week. This includes MSC3383 (Include destination in X-Matrix Auth Header), MSC3700 (Deprecate plaintext sender key) and MSC2246 (Asynchronous media uploads). Exciting things in the pipeline!

🔗Random MSC of the Week

The random MSC of the week is... MSC2815: Proposal to allow room moderators to view redacted event content!

Another MSC in the sphere of moderation, and one that aims to put moderation control more in the hands of room admins rather than homeserver admins. A similar MSC in this realm is MSC3215 (Aristotle), which aims to send event reports to room admins, rather than homeserver admins that may not even have control over the malicious user.

🔗Dept of Servers 🏢

🔗Synapse (website)

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

Brendan Abolivier announces

Happy Friday everyone!

In case you missed it, we've released the first release candidate for Synapse 1.56 on Tuesday. This one includes a couple new module-related features, but also quite a few bugfixes and internal improvements. I'll talk about this in more details next week when Synapse 1.56 gets properly released, but the key points of this release is that Synapse will now refuse to start if it's configured with unsafe registration settings (i.e. open registration without any form of verification) as well as if it's running against a PostgreSQL database with the wrong locale values. Have a look at the upgrade notes for more information about this.

Apart from that, the team still continuing work on the two main topics I've been mentioning in previous weeks: fast room joins and integrating poetry. The latter is getting reeeally close to the finish line now, as the pull request has recently entered the review stage. So watch this space for more exciting news on this topic!

That's all for this week, catch you all next time 🙂

🔗matrix-media-repo (website)

Matrix media repository with multi-domain in mind.

TravisR reports

MMR v1.2.12 is out now with a bunch of added features, removal of in-memory cache (per last release's deprecation notice), and some bug fixes.

Most notable are some added/improved support for JPEG XL, HEIF, and HEIC thumbnails, content ranges support (allowing the ability to skip to a part of a video), and a way to make the logs a bit quieter.

Give it a go and report issues to the issue tracker 🙂

🔗Dept of Bridges 🌉

🔗matrix-hookshot (website)

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

Half-Shot announces

It feels like one of these comes out nearly every month, which probably means we're doing something right! This release takes a step back and fixes quite a few of our more longstanding bugs and fixes many nits here and there. Please read the change notes carefully as some APIs have moved around and your load balancers / config may need adjusting. One final note is that this release drops support for Node 12, making the minimum version Node 14.

Once again, thanks to the wider Matrix community for filing bugs and submitting PRs, it's very much appreciated!

🔗matrix-appservice-bridge 4.0.0

Half-Shot says

More updates! This week the bridge library itself gets a major update. We've made a few breaking changes, notably we now expect target homeservers to at least be Matrix v1.2 compatible. Also, this release brings the new "Provisioning and Widgets API" which allows developers to start creating HTTP APIs for their bridges which work for both provisioning mode (shared secret tokens) and widget API style (authenticating via Matrix OpenID token sharing). This stuff is still a little experimental, but it's starting to power our new experiments in the bridge world.

You can check out the release here

🔗matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair announces

Media messages, both from or to KakaoTalk, are now supported! The biggest exceptions are inbound files & stickers. The latter may be a hard sell to get working, due to how KT manages stickers, but I'll look into it some more before giving a concrete answer.

The bridge is also now responsive to disconnects, like when you log in from another KakaoTalk desktop client (since the bridge mimics the desktop client, and KT only allows one desktop client to be logged in at a time!). Luckily, not all KakaoTalk APIs rely on the same connection that chatting does, meaning that some functionality can continue to work even when "disconnected". The bridge now takes advantage of this, meaning that profile-management commands (currently just the list-friends command) will work even if you get disconnected from chats for whatever reason.

The bridge is drawing ever closer to "good enough" status... Please give it a try if curious!

---

Discussion: #matrix-appservice-kakaotalk:miscworks.net Issue page: https://src.miscworks.net/fair/matrix-appservice-kakaotalk/issues

🔗matrix-appservice-irc (website)

Node.js IRC bridge for Matrix

Half-Shot reports

Heyo, we released a hotfix release for the IRC bridge this week. This fixed a rather nasty regression where the bridge would kick everyone from the Matrix side when a Matrix ban list is updated. People who aren't using the new ban lists feature don't need to upgrade.

Please check out https://github.com/matrix-org/matrix-appservice-irc/releases/tag/0.33.1 for more details

🔗Dept of Clients 📱

Michael says

The perthchat.org team has created their own Android client, a promotional fork of the popular Element Android client!

For more details checkout: https://news.perthchat.org/perthchats-new-android-app/ https://play.google.com/store/apps/details?id=im.perthchat.app

🔗Nheko (website)

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

Nico announces

1.0 is a big number and a step not taken lightly. But Nheko has been in development for half a decade and we think it is time to take a step forward! As such we worked hard to fix readability issues in the app. Your messages should now be readable on any theme, because we send the first half as white text and the second half as black text (thank you, rrogalski for the contribution). For accessibility reasons this is enabled by default. We also added an improved typing indicator. Sometimes it is hard to notice when a message is too long, as such we gradually adjust the background color the longer the message gets. It also helps a lot, if you have a bad theme and can't read the text against the background color. Just enter a few characters and the background will change, so the messages should become readable. But that is not all! We all know some people have a harder time seeing colors than others. So for accessibility we also slowly rotate the screen, so that even if your display is monochrome, you don't miss out. Please see the attached video for a demo or check out our release candidates here and here.

Before this month we also rewrote the room creation dialogs to be less confusing. We now have separate dialogs for direct chats and group chats, which should cut down confusion between the options by a lot. You can also now edit the topic and name of a room inline and Malte added a jump to bottom button. On mobile you can also now drag to the sides to reply. Last but not least, you can now knock on rooms from Nheko using /knock or if an invite failed because you were not allowed to join a room and you can add a reason to room joins, leaves, invites, knocks and everything. Some of those features require the server to support Matrix v1.1, so make sure you update your servers to use them.

Nico announces

Excuse the blurry picture, but Bubu just sent me this and I just had to share it!

🔗Neochat (website)

A client for matrix, the decentralized communication protocol

Tobias Fella says

NeoChat now has a KRunner plugin thanks to work done by Nico (not the one from Nheko 🙂). This allows plasma users to search for and open matrix rooms directly from their desktop. You will be able to enable it from the KRunner settings after the next release.

Snehit changed the room preview to no longer show markdown characters, fixing a few situations where this would be unexpected.

On the end-to-end encryption side, we're currently working on implementing device verification.

🔗Fractal (website)

Matrix messaging app for GNOME written in Rust.

Julian Sparber reports

This week I have something really exciting to report. We moved Fractal-next to the main development branch. This means that we now have nightly flatpak builds[1], so users can already try out the new version of Fractal without having to build it from source. This will also give use much more feedback and many more bug reports, hopefully not too many :) Note that this isn't a release and the software should still be considered unstable.

[1] https://gitlab.gnome.org/GNOME/fractal#development-version

🔗Element (website)

Everything related to Element but not strictly bound to a client

Danielle announces

It’s April Fool’s day but there will be no tricks here; We’re far too excited to share all our good work with you 😉

Message Threading

• Exciting news for Threads; Next week we’re releasing a public beta!

  • It’ll be opt-in, so don’t forget to head to Settings and join in if you haven’t already.

• We’re still working on perfecting notifications, so none of your messages are missed.

• The team is also working hard at improving the stability of Threads, ahead of the release next week.

• As always, please let us know your thoughts and feedback!

🔗Element Web/Desktop (website)

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

Kegan says

Coming soon to an Element-Web near you...

Danielle announces

In labs (you can enable labs in settings on develop.element.io or on Nightly)

• Voice rooms are now known as video rooms! We’ve landed some new designs to help make the experience more coherent, and bring them out of ‘prototype’ status.
• Threads! From next week you’ll be able to turn on threads in all versions of Element but for a sneak preview you can head to Labs in Develop or Nightly and access Message Threading from there.
• We’re continuing to work on our updated search experience: we are going to be merging the people and room search dialogs into the new search experience and adding filtering. Expecting work to start early next week.
• Along with some feature work in Labs, the team is hard at work closing issues and clearing pesky bugs.

🔗Element iOS (website)

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

Manu reports

• Our latest release is a hotfix (1.8.10) resolving a crash that occurred when uploading a photo via the camera in the timeline.
• Following a team discussion and input from all areas we’ve decided to change how we launch new languages in Element. We’ll soon be moving to an automatic rollout model meaning, if there’s any amount of a language available, and it’s set as your preference, you’ll see it in the app.
  • Previously we’d wait until hitting the 80% mark and then manually push the translation. This leaves too much room for us to forget, or restricts access to those languages hanging around the 70% mark…
• Other things we’ve been working on this week include; improving the new user experience, and starting to prototype with the layout for the app.
• We released spaces on iOS this week! Where you could only view spaces before, you can now create and manage them from your phone. We have more improvements planned for the next release.

🔗Element Android (website)

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

Danielle announces

• The Android team has been determined over the past weeks to improve our internal process, increasing efficiency and quality of building and deploying. With that in mind, we’ve recently published a guide for PRs on our Android Repo. It’s still a draft right now but if you want to know more about our approach, read it here.
• In terms of building we’re continuing on our path of improving the quality of the app by focussing on bugs and UI issues.
• We’re also working on improving our new user experience to make it easier for newbies to get up and running on Element Android!

🔗Dept of Non Chat Clients 🎛️

🔗matrix-streamchat (website)

Matrix powered stream overlay for OBS, to integrate live chat in your favorite (selfhosted) streaming setups.

f0x announces

matrix-streamchat got it's first proper release, after some battletesting by another streamer :D https://git.pixie.town/f0x/matrix-streamchat/releases/tag/0.0.2 hosted instance is also available at https://streamchat.pixie.town

🔗Matrix Highlight (website)

A decentralized and federated way of annotating the web based on Matrix.

Daniel announces

Matrix Highlight got an update this week. I've switched the highlighting widget to use a shadow DOM, which means styles from the page don't affect styles from the extension itself. This used to affect quite a lot of pages, but shouldn't be much of a problem anymore!

🔗Dept of SDKs and Frameworks 🧰

🔗Ruma (website)

A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.

Jonas Platte says

This week, we

• updated the space-hierarchy rooms chunk type to use a decicated join-rule type
• added support for more transitional extensible-event types
• removed the origin field from PDUs
• added support for MSC2654 (Unread count)

🔗matrix-rust-sdk (website)

Matrix Client-Server SDK for Rust

Jonas Platte announces

In the last two weeks,

• Support for vodozemac as an alternative to libolm has been merged, and enabled by default 🎉
• A bug around invitations to previously-left rooms was fixed

There was also a decent amount of internal cleanup / developer experience work, so if you previously tried to contribute but ran into weird IDE bugs or code inconsistencies, make sure to check back. The same goes for sliding sync, which has been making decent progress – stay tuned!

🔗Dept of Events and Talks 🗣️

andybalaam reports

I'm doing a talk about Matrix at the ACCU Conference on Saturday 9th April. Recordings of talks will be available soon after the conference, and tickets are still available to be there live in person or online! Here's the talk summary:

The Matrix network provides messaging (like WhatsApp or Slack) that offers all the features you expect, but without centralised control: it's an open standard, and anyone can run a server. The servers link together, so you can talk to other people even if they use a different server (kind of like email).

In the first half of this session, we will explore the basics of the protocol: making simple HTTP requests to send and receive messages, and discuss some of the interesting distributed-systems issues that make writing a server exciting.

In the second half we will explore the fact that messaging is only one potential use of this network, and look into some examples of other real-time use cases that are in active development, taking note of how these use cases benefit from the real-time and distributed nature of the network.

🔗Dept of Interesting Projects 🛰️

🔗matrix-art (website)

An image gallery for Matrix

MTRNord (they/them) reports

There was some silence lately on this, but activity is picking back up.

Mainly, the project is getting rewritten. Why? Well, I learned from the issues and ran into issues with the framework used. There are going to be various changes to the architecture (like no more SSR, no nextjs, pwa support and more).

Feel free to follow https://github.com/MTRNord/matrix-art/pull/121 for progress.

Another big thing that's going to change is that I am working on a complete redesign. While I am still fairly early in the iterations, I wanted to share the first art direction Matrix Art is going to go. The main changes are that I try to have an art language which distinguishes it from the other proprietary players, as well as compensating for the fact that Matrix Art has a much lower volume of images on it's feed. Please be aware that this is way before the first round of polish. :)

If you want to connect with matrix-art please join the room: #matrix-art:nordgedanken.dev or follow/star the github project :)

🔗Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	envs.net	449
2	neko.dev	455
3	tchncs.de	475.5
4	aria-net.org	484
5	quyo.de	535.5
6	settgast.org	737
7	catgirl.cloud	975
8	alemann.dev	1066
9	jeroenhd.nl	1228
10	maescool.be	1422

🔗#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	cry.is	215
2	nognu.de	368
3	conduit.grich.sk	417
4	sspaeth.de	616.5
5	xethos.net	798
6	dendrite.s3cr3t.me	1256.5

🔗That's all I know 🏁

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

Hi all,

We've been flooded with questions about the DMA since it was announced last week, and have spotted some of the gatekeepers jumping to the wrong conclusions about what it might entail. Just in case you don't want to wade through yesterday's sprawling blog post, we've put together a quick FAQ to cover the most important points based on our understanding.

🔗What does DMA mean for the gatekeepers?

The gatekeepers will have to open and document their existing APIs, so that alternative clients and/or bridges can connect to their service. The DMA requires that the APIs must expose the same level of privacy for remote users as for local users. So, if their service is end-to-end-encrypted (E2EE), the APIs must expose the same E2EE semantics (e.g. so that an alternative client connecting would have to implement E2EE too). For E2EE-capable APIs to work, the gatekeeper will likely have to model remote users as if they were local in their system. In the short term (one year horizon) this applies only to 1:1 chats and file transfers. In the long term (three year horizon) this applies to group chats and voip calls/conferences too.

🔗Who counts as a “gatekeeper”?

The DMA defines any tech company worth over €75B or with over €7.5B of turnover as a gatekeeper, who must open their communication APIs. This means only the tech giants are in scope (e.g. as of today that includes Meta, Apple, Google, Microsoft, Salesforce/Slack - not Signal, Telegram, Discord, Twitter).

🔗Does this mean the gatekeepers are being forced to implement an open standard such as Matrix or XMPP?

No. They can keep their existing implementations and APIs. For interoperability with other service providers, they will need to use a bridge (which could bridge via a common language such as Matrix or XMPP).

🔗Are bridges secure?

If the service lacks end-to-end-encryption (Slack, Teams, Google Chat, non-secret chats on Facebook Messenger, Instagram, Google Messages etc) then the bridge does not reduce security or privacy, beyond the fact that bridged conversations by definition will be visible to the bridge and to the service you are interoperating with.

If the service has E2EE (WhatsApp, iMessage, secret chats on Messenger) then the bridge will necessarily have to decrypt (and reencrypt, where possible) the data when passing it to the other service. This means the conversation is no longer E2EE, and thus less secure (the bridge could be compromised and inspect or reroute their messages) - and so gatekeepers must warn the user that their conversation is leaving their platform and is no longer E2EE with something like this:

🔗Why is the DMA good?

The upside is that the user has the freedom to use an infinite number of services (bots, virtual assistants, CRMs, translation services, etc) as well as speak to any other user in the world, regardless what platform they use.

It also puts much-needed pressure on the gatekeepers to innovate and differentiate rather than rely on their network effects to attract new users - creating a much more vibrant, open, competitive marketplace for users.

See "What's driven the DMA?" for more details.

🔗If the DMA requires that remote users have the same security as local users, how can bridges work?

The DMA requires that the APIs expose the same level of security as for local users - ie E2EE must be exposed. If the users in a conversation choose to use a bridge and thus reencrypt the messages, then it is their choice to tradeoff encryption in favour of interoperability for a given conversation.

🔗Does this undermine the gatekeepers’ current encryption?

Absolutely not. Users talking to other users within the same E2EE-capable gatekeeper will still be E2EE (assuming the gatekeeper doesn’t pull that rug from under its users) - and in fact it gives the gatekeepers an excellent way to advertise the selling point that E2EE is only guaranteed when you speak to other users on the same platform.

🔗But why do we need bridges? If everyone spoke a common protocol, you wouldn’t ever have to decrypt messages to convert them between protocols.

Practically speaking, we don’t expect the gatekeepers to throw away their existing stacks (or implement multihead messengers that also speak open protocols). It’s true that if they natively spoke Matrix or XMPP then the reencryption problem would go away, but it’s more realistic to focus on opening the existing APIs than interpret the legislation as a mandate to speak Matrix. Perhaps in future players will adopt Matrix of their own volition.

🔗Where do these bridges come from?

There is already a vibrant community of developers who build unofficial bridges to the gatekeepers - eg Element, Beeper and hundreds of open source developers in the Matrix and XMPP communities. Historically these bridges have been hampered by having to use unofficial and private APIs, making them a second class citizen - but with open documented APIs guaranteed by the DMA we eagerly anticipate an explosion of high quality transparent bridges which will be invisible to the end user.

🔗Can you run E2EE bridges clientside to make them safer?

Maybe. For instance, current iMessage bridges work by running iMessage on a local iPhone or Mac and then reencrypting the messages there for interoperability. Given the messages are already exposed on the client anyway, this means that E2EE is not broken - and avoids decrypting them on a server. There is lots of development in this space currently, and with open APIs guaranteed by DMA the pace should speed up significantly.

🔗How can you tell what service you should use to talk to a given remote user?

For 1:1 chats this is easy: you can simply ask the user which service they want to use to talk to a given user, if that user is not already on that service.

For group chats it is harder, and this is why the deadline for group chats is years away. The problem is that you need a way to verify the identity of arbitrary numbers of remote users on different platforms - effectively looking up their identity in a secure manner which stops services from maliciously spoofing identities.

One possible way to solve this would be for users to explicitly link their identity on one service with that on the gatekeeper’s service - eg “Alice on AliceChat is talking in the same room as Bob on BobChat; Bob will be asked to prove to AliceChat that he is the real Bob” - and so if AliceChat has already validated Bob’s identity, then this can be used to spot him popping up on other services. It also gives Bob a way to block themselves from ever being unwittingly bridged to AliceChat.

There are many other approaches too - and the onus is on the industry to figure out the best solution for decentralised identity in the next 3-4 years in order to realise the most exciting benefits of the DMA.

---

For a much deeper dive into the above, please check out our post at "How do you implement interoperability in a DMA world?"

With last week’s revelation that the EU Digital Markets Act will require tech gatekeepers (companies valued at over $75B or with over $7.5B of turnover) to open their communication APIs for the purposes of interoperability, there’s been a lot of speculation on what this could mean in practice, To try to ground the conversation a bit, we’ve had a go at outlining some concrete proposals for how it could work.

However, before we jump in, we should review how the DMA has come to pass.

🔗What’s driven the DMA?

Today’s gatekeepers all began with a great product, which got more and more popular until it grew to such a size that one of the biggest reasons to use the service is not necessarily the product any more, but the benefits of being able to talk to a large network of users. This rapidly becomes anti-competitive, however: the user becomes locked into the network and can’t switch even if they want to. Even when people have a really good reason to move provider (e.g. WhatsApp’s terms of use changing to share user data with Facebook, Apple doing a 180 on end-to-end encrypting iCloud backups, or Telegram not actually being end-to-end encrypted), in practice hardly anything changes - because the users are socially obligated to keep using the service in order to talk to the rest of the users on it.

As a result, it’s literally harmful to the users. Even if a new service launches with a shiny new feature, there is enormous inertia that must be overcome for users to switch, thanks to the pull of their existing network - and even if they do, they’ll just end up with their conversations haphazardly fragmented over multiple apps. This isn’t accepted for email; it isn’t accepted for the phone network; it isn’t accepted on the Internet itself - and it shouldn’t be accepted for messaging apps either.

Similarly: the closed networks of today’s gatekeepers put a completely arbitrary limit on how users can extend and enrich their own conversations. On email, if you want to use a fancy new client like Superhuman - you can. If you want to hook up a digital assistant or translation service to help you wrangle your email - you can. If you want to hook up your emails to a CRM to help you run your business - you can. But with today’s gatekeepers, you have literally no control: you’re completely at the mercy of the service provider - and for something like WhatsApp or iMessage the options are limited at best.

Finally - all the users’ conversation metadata for that service (who talks to who, and when) ends up centralised in the gatekeepers’ databases, which then become an incredibly valuable and sensitive treasure trove, at risk of abuse. And if the service provider identifies users by phone number, the user is forced to disclose their phone number (a deeply sensitive personal identifier) to participate, whether they want to or not. Meanwhile the user is massively incentivised not to move away: effectively they are held hostage by the pull of the service’s network of users.

So, the DMA exists as a strategy to improve the situation for users and service providers alike by building a healthier dynamic ecosystem for communication apps; encouraging products to win by producing the best quality product rather than the biggest network. To quote Cédric O (Secretary of State for the Digital Sector of France), the strategy of the legislation came from Washington advice to address the anticompetitive behaviour of the gatekeepers “not by breaking them up… but by breaking them open.” By requiring the gatekeepers to open their APIs, the door has at last been opened to give users the option to pick whatever service they prefer to use, to choose who they trust with their data and control their conversations as they wish - without losing the ability to talk to their wider audience.

However, something as groundbreaking as this is never going to be completely straightforward. Of course while some basic use cases (i.e. non-E2EE chat) are easy to implement, they initially may not have a UX as smooth as a closed network which has ingested all your address book; and other use cases(eg E2EE support) may require some compromises at first. It’s up to the industry to figure out how to make the most of that challenge, and how to do it in a way which minimises the impact on privacy - especially for end-to-end encrypted services.

🔗What problems need to be solved?

We’ve already written about this from a Matrix perspective, but to recap - the main challenge is the trade-off between interoperability and privacy for gatekeepers who provide end-to-end encryption, which at a rough estimate means: WhatsApp, iMessage, secret chats in Facebook Messenger, and Google Messages. The problem is that even with open APIs which correctly expose the end-to-end encrypted semantics (as DMA requires), the point where you interoperate with a different system inevitably means that you’ll have to re-encrypt the messages for that system, unless they speak precisely the same protocol - and by definition you end up trusting the different system to keep the messages safe. Therefore this increases the attack surface on the conversations, putting the end-to-end encryption at risk.

Alex Stamos (ex-CISO at Facebook) said that “WhatsApp rolling out mandatory end-to-end encryption was the largest improvement in communications privacy in human history” – and we agree. Guaranteed end-to-end encrypted conversations on WhatsApp is amazing, and should be protected at all costs. If users are talking to other users on WhatsApp (or any set of users communicating within the same E2EE messenger), E2EE should and must be maintained - and there is nothing in the DMA which says otherwise.

But what if the user consciously wants to prioritise interoperability over encryption? What if the user wants to hook their WhatsApp messages into a CRM, or run them through a machine translation service, or try to start a migration to an alternative service because they don’t trust Meta? Should privacy really come so spectacularly at the expense of user freedom?

We also have the problem of figuring out how to reference users on other platforms. Say that I want to talk to a user with a given phone number, but they’re not on my platform - how do I locate them? What if my platform only knows about phone numbers, but you’re trying to talk to a user on a platform which uses a different format for identifiers?

Finally, we have the problem of mitigating abuse: opening up APIs makes it easier for bad actors to try to spam or phish or otherwise abuse users within the gatekeepers. There are going to have to be changes in anti-abuse services/software, and some signals that the gatekeeper platforms currently use are going to go away or be less useful, but that doesn't mean the whole thing is intractable. It will require changes and innovative thinking, but we’ve been making steady progress (e.g. the work done by Element’s trust and safety team). Meanwhile, the gatekeepers already have massive anti-abuse systems in place to handle the billions of users within their walled gardens, and unofficial APIs are already widespread: adding official APIs does not change the landscape significantly (assuming interoperability is implemented in such a way that the existing anti-abuse mechanisms still apply).

In the past, gatekeepers dismissed the effort of interop as not being worthwhile - after all, the default course of action is to build a walled garden, and having built one, the temptation is to try to trap as many users as possible. It was also not always clear that there were services worth interoperating with (thanks to the chilling effects of the gatekeepers themselves, in terms of stifling innovation for communication startups). Nowadays this situation has fundamentally changed however: there is a vibrant ecosystem of open communication startups out there, and a huge appetite to build a vibrant open ecosystem for interoperable communication, but like the open web itself.

🔗What are the requirements?

Before going further in considering solutions, we need to review the actual requirements of the DMA. Our best understanding at this point is that the DMA will mandate that:

• Gatekeepers will have to provide open and documented APIs to their services, on request, in order to facilitate interoperability (i.e. so that other services can communicate with their users).
• These APIs must preserve the same level of end-to-end encryption (if any) to remote users as is available to local users.
• This applies to 1:1 messaging and file transfer in the short term, and group messaging, file-transfer, 1:1 VoIP and group VoIP in the longer term.

🔗So, what could this actually look like?

The DMA legislation deliberately doesn’t focus on implementation, instead letting the industry figure out how this could actually work in practice. There are many different possible approaches, and so from our point of view as Matrix we’ve tried to sketch out some options to make the discussion more concrete. Please note these are preliminary thoughts, and are far from perfect - but hopefully useful as a starting point for discussion.

🔗Finding Bob

Imagine that you have a user Alice on an existing gatekeeper, which we’ll call AliceChat, who runs an E2EE messaging service which identifies users using phone numbers. Say that they want to start a 1-to-1 conversation with Bob, who doesn’t use AliceChat, but Alice knows he is a keen user of BobChat. Today, you’d have no choice but to send them an SMS and nag them to join AliceChat (sucks to be them if they don’t want to use that service, or if they’re unable to for whatever reason - e.g. their platform isn’t supported, or their government has blocked access, etc), or join BobChat yourself.

However, imagine if instead the gatekeeper app had a user experience where the app prompted you to talk to the user via a different platform instead. It’d be no different to your operating system prompting you to pick which app to use to open a given file extension (rather than the OS vendor hardcoding it to one of their own apps - another win for user rights led by the EU!).

Now, the simplest approach in the short term would be for each gatekeeper to pre-provision a set of options of possible alternative networks. (The DMA says that, on request, other service providers can ask to have access to the gatekeeper’s APIs for the purposes of interoperability, so the gatekeeper knows who the alternative networks may be). “Bob is not on AliceChat - do you want to try to reach him instead on BobChat, CharlieChat, DaveChat (etc)”.

Much like users can configure their preferred applications for file extensions in an operating system today, users would also be able to add their own preferred service providers - simply specifying their domain name.

🔗Connecting to Bob

Now, AliceChat itself needs to figure out how to query the remote service provider to see if Bob actually exists there. Given the DMA requires that gatekeepers provide open APIs with the same level of security to remote users as their local ones using today’s private APIs - and very deliberately doesn’t mandate specific protocols for interoperability - they will need to locate a bridge which can connect to the other system.

In this thought experiment, the bridge used would be up to the destination provider. For instance, bobchat.com could announce that AliceChat users should connect to it via alicechat-bridge.bobchat.com using the AliceChat protocol(or matrix-bridge.bobchat.com via Matrix or xmpp-bridge.bobchat.com via XMPP) by a simple HTTP API or even a .well-known URL. Users might also be able to override the bridge used to connect to them (e.g. to point instead at a client-side bridge), and could sign the advertisement to prove that it hadn’t been tampered with.

AliceChat would then connect to the discovered bridge using AliceChat’s vendor-specific newly opened API, and would then effectively treat Bob as if they were a real AliceChat user and client to all intents and purposes. In other words, Bob would effectively be a “ghost user” on AliceChat, and subject to all their existing anti-abuse mechanisms.

Meanwhile, the other side of the bridge converts through to whatever the target system is - be that XMPP, Matrix, a different proprietary API, etc. For Matrix, it’d be chatting away to a homeserver via the Application Service API (using End-to-Bridge Encryption via MSC3202). It’s also worth noting that the target might not even be a bridge - it could be a system which already natively speaks AliceChat’s end-to-end encrypted API, thus preserving end-to-end encryption without any need to re-encrypt. It’s also worth noting that while historically bridges have had a bad reputation as being a second class (often a second class afterthought), Matrix has shown that by considering them as a first class citizen and really focusing on mapping the highest common denominator between services rather than lowest common denominator, it’s possible for them to work transparently in practice. Beeper is a great example of Matrix bridging being used for real in the wild (rather amusingly they just shipped emoji reactions for WhatsApp on iOS via their WhatsApp<->Matrix bridge before WhatsApp themselves did…)

Architecturally, it could look like this:

Or, more likely (given a dedicated bridge between two proprietary services would be a bit of a special case, and you’d have to solve the dilemma of who hosts the bridge), both services could run a bridge to a common open standard protocol like Matrix or XMPP instead (thus immediately enabling interoperability with everyone else connected to that network):

Please note that while these examples show server-side bridges, in practice it would be infinitely preferable to use client-side bridges when connecting to E2EE services - meaning that decrypted message data would only ever be exposed on the client (which obviously has access to the decrypted data already). Client-side bridges are currently complicated by OS limits on background tasks and push notification semantics (on mobile, at least), but one could envisage a scenario where you install a little stub AliceChat client on your phone which auths you with AliceChat and then sits in the background receiving messages and bridging them through to Matrix or XMPP, like this:

Another possible architecture could be for the E2EE gatekeeper to expose their open APIs on the clients, rather than the server. DMA allows this, to the best of our knowledge - and would allow other apps on the device to access the message data locally (with appropriate authorisation, of course) - effectively doing a form of realtime data liberation from the closed service to an open system, looking something like this:

Finally, it's worth noting that when peer-to-peer decentralised protocols like P2P Matrix enter production, clientside bridges could bridge directly into a local communication server running on the handset - thus avoiding metadata being exposed on Matrix or XMPP servers providing a common language between the service providers.

🔗Locating users

Now, the above describes the simplest and most naive directory lookup system imaginable - the problem of deciding which provider to use to connect to each user is shouldered by the users. This isn’t that unreasonable - after all, users may have strong feelings about what providers to use to talk to a given user. Alice might be quite happy to talk to Bob via BobChat, but might be very deliberately avoiding talking to him on DaveChat, for whatever ominous reasons.

However, it’s likely in future we will also see other directory services appear in order to map phone numbers (or other identities) to providers - whether these piggyback on top of existing identity providers (gatekeepers, DNS, telcos, SSO providers, governments) or are decentralised through some other mechanism. For instance, Bob could send AliceChat a blinded proof that he authorises them to automatically route traffic to him over at BobChat, with BobChat maintaining a matching proof that Bob is who he claims to be (having gone through BobChat’s auth process) - and the proofs could be linked using a temporary key such that Bob doesn’t even need to maintain a long-term one. (Thanks to James Monaghan for suggesting this one!)

Another alternative to having the user decide where to find each other could be to use a decentralised Keybase-style identity system to track verified mappings of identities (phone numbers, email addresses etc) through to service providers - perhaps something like IDX might fit the bill? While this decentralised identity lookups have historically been a hard problem, there is a lot of promising work happening in this space currently and the future looks promising.

🔗Talking to Bob

Meanwhile, Alice still needs to talk to Bob. As already discussed, unless everyone speaks the same end-to-end encrypted protocol (be it Matrix, WhatsApp or anything else), we inevitably have a trade-off here between interoperability and privacy if Bob is not on the same system as Alice (assuming AliceChat is end-to-end encrypted) - and we will need to clearly warn Alice that the conversation is no longer end-to-end encrypted:

To be clear: right now, today, if Bob were on AliceChat, he could be copy-pasting all your messages into (say) Google Translate in a frantic effort to workaround the fact that his closed E2EE chat platform has no way to do machine translation. However, in a DMA world, Bob could legitimately loop a translation bot into the conversation… and Alice would be warned that the conversation was no longer secure (given the data is now being bridged over to Google).

This is a clear improvement in user experience and transparency. Likewise, if I’m talking to a bridged user today on one of these platforms, I have no way of telling that they have chosen to prioritise interop over E2EE - which is frankly terrifying. If I’m talking to someone on WhatsApp today I blindly assume that they are E2EE as they are on the same platform - and if they’re using an unofficial app or bridge, I have no way to tell. Whereas in a DMA world, you would expect the gatekeeper to transparently expose it.

If anything, this is good news for the gatekeeper in that it consciously advertises a big selling point for them: that for full E2EE, users need to talk to other users in the same walled garden (unless of course the platform speaks the same protocol). No more need for bus shelter adverts to remind everywhere that WhatsApp is E2EE - instead they can remind the user every time they talk to someone outside the walled garden!

Just to spell it out: the DMA does not require or encourage any reduction in end-to-end encryption for WhatsApp or similar: full end-to-end encryption will still be there for users in the same platform, including through to users on custom clients (assuming the gatekeeper doesn’t flex and turn it off for other reasons).

Obviously, this flow only considers the simple case of Alice inviting Bob. The flow is of course symmetrical for Bob inviting Alice; AliceChat will need to advertise bridges which can be used to connect to its users. As Bob pops up from BobChat, the bridge would use AliceChat’s newly open APIs to provision a user for him, authing him as per any other user (thus ensuring that AliceChat doesn’t need to have trusted BobChat to have authenticated the user). The bridge then sends/receives messages on Bob’s behalf within AliceChat.

🔗Group communication

This is all very well for 1:1 chats - which are the initial scope of the DMA. However, over the coming years, we expect group chats to also be in scope. The good news is that the same general architecture works for group chats too. We need a better source of identity though: AliceChat can’t possibly independently authenticate all the new users which might be joining via group conversations on other servers (especially if they join indirectly via another server). This means adopting one of the decentralised identity lookup approaches outlined earlier to determine whether Charlie on CharlieChat is the real Charlie or an imposter.

Another problem which emerges with group chats which span multiple service providers is that of indirect routing, especially if the links between the providers use different protocols. What if AliceChat has a direct bridge to BobChat (a bit like AIM and ICQ both spoke OSCAR), BobChat and CharlieChat are connected by Matrix bridges, and AliceChat and CharlieChat are connected via XMPP bridges? We need a way for the bridges to decide who forwards traffic for each network, and who bridges the users for which network. If they were all on Matrix or XMPP this would happen automatically, but with mixed protocols we’d probably have to extend the lookup protocol to establish a spanning tree for each conversation to prevent forwarding loops.

Here’s a deliberately twisty example to illustrate the above thought experiment:

There is also a risk of bridge proliferation here - in the worst case, every service would have to source bridges to directly connect to every other service who came along, creating a nightmarish n-by-m problem. But in practice, we expect direct proprietary-to-proprietary bridges to be rare: instead, we already have open standard communication protocols like Matrix and XMPP which provide a common language between bridges - so in practice, you could just end up in a world where each service has to find a them-to-Matrix or them-to-XMPP bridge (which could be run by them, or whatever trusted party they delegate to).

🔗Conclusion

A mesh of bridges which connect together the open APIs of proprietary vendors by converting them into open standards may seem unwieldy at first - but it’s precisely the sort of ductwork which links both phone networks and the Internet together in practice. As long as the bridging provides for highest common denominator fidelity at the best impedance ratio, then it’s conceptually no different to converting circuit switched phone calls to VoIP, or wired to wireless Ethernet, or any of the other bridges which we take entirely for granted in our lives thanks to their transparency.

Meanwhile, while this means a bit more user interface in the communication apps in order to select networks and warn about trustedness, the benefits to users are enormous as they put the user squarely back in control of their conversations. And the UX will improve as the tech evolves.

The bottom line is, we should not be scared of interoperability, just because we’ve grown used to a broken world where nothing can interconnect. There are tractable ways to solve it in a way that empowers and informs the user - and the DMA has now given the industry the opportunity to demonstrate that it can work.

Yesterday the EU Parliament & Council agreed on the contents of the Digital Markets Act - new legislation from the EU intended to limit anticompetitive behaviour from tech “gatekeepers”, i.e. big tech companies (those with market share larger than €75B or with more than €7.5B a year of revenue).

This is absolutely landmark legislation, where the EU has decided not to break the gatekeepers up in order to create a more competitive marketplace - but instead to “break them open”. This is unbelievably good news for the open Internet, as it is obligating the gatekeepers to provide open APIs for their communication services. In other words: no longer will the tech giants be able to arbitrarily lock their users inside their walled gardens - there will be a legal requirement for them to expose APIs to other services.

While the formal outcomes of yesterday’s agreement haven’t been published yet (beyond this press release), our understanding is that the DMA will mandate:

• Gatekeepers will have to provide open and documented APIs to their services, on request, in order to facilitate interoperability (i.e. so that other services can communicate with their users).
• These APIs must preserve the same level of end-to-end encryption (if any) to remote users as is available to local users.
• This applies to 1:1 messaging and file transfer in the short term, and group messaging, file-transfer, 1:1 VoIP and group VoIP in the longer term.

This is the best possible outcome imaginable for the open internet. Never again will a big tech company be able to hold their users hostage in a walled garden, or arbitrarily close down or sabotage their APIs.

🔗So, what’s the catch?

Since the DMA announcement on Thursday, there’s been quite a lot of yelling from some very experienced voices that mandating interoperability via open APIs is going to irrevocably undermine end-to-end encrypted messengers like WhatsApp. This seems to mainly be born out of a concern that the DMA is somehow trying to subvert end-to-end encryption, despite the fact that the DMA explicitly mandates that the APIs must expose the same level of security, including end-to-end encryption, that local users are using. (N.B. Signal doesn’t qualify as a gatekeeper, so none of this is relevant to Signal).

So, for WhatsApp, it means that the API would expose both the message-passing interface as well as the key management APIs required to interoperate with WhatsApp using your own end-to-end-encrypted WhatsApp client - E2EE would be preserved.

However, this does mean that if you were to actively interoperate between providers (e.g. if Matrix turned up and asked WhatsApp, post DMA, to expose an API we could use to write bridges against), then that bridge would need to convert between WhatsApp’s E2EE’d payloads and Matrix’s E2EE’d payloads. (Even though both WhatsApp and Matrix use the Double Ratchet, the actual payloads within the encryption are completely different and would need to be converted). Therefore such a bridge has to re-encrypt the traffic - which means that the plaintext is exposed on the bridge, putting it at risk and breaking the end-to-end encryption guarantee.

There are solutions to this, however:

• We could run the bridge somewhere relatively safe - e.g. the user’s client. There’s a bunch of work going on already in Matrix to run clientside bridges, so that your laptop or phone effectively maintains a connection over to iMessage or WhatsApp or whatever as if it were logged in… but then relays the messages into Matrix once re-encrypted. By decentralising the bridges and spreading them around the internet, you avoid them becoming a single honeypot that bad actors might look to attack: instead it becomes more a question of endpoint compromise (which is already a risk today).

• The gatekeeper could switch to a decentralised end-to-end encrypted protocol like Matrix to preserve end-to-end encryption throughout. This is obviously significant work on the gatekeeper’s side, but we shouldn’t rule it out. For instance, making the transition for a non-encrypted service is impressively little work, as we proved with Gitter. (We’d ideally need to figure out decentralised/federated identity-lookup first though, to avoid switching from one centralised identity database to another).

• Worst case, we could flag to the user that their conversation is insecure (the chat equivalent of a scary TLS certificate warning). Honestly, this is something communication apps (including Matrix-based ones!) should be doing anyway: as a user you should be able to tell what 3rd parties (bots, integrations etc) have been added to a given conversation. Adding this sort of semantic actually opens up a much richer set of communication interactions, by giving the user the flexibility over who to trust with their data, even if it breaks the platonic ideal of pure E2E encryption.

On balance, we think that the benefits of mandating open APIs outweigh the risks that someone is going to run a vulnerable large-scale bridge and undermine everyone’s E2EE. It’s better to have the option to be able to get at your data in the first place than be held hostage in a walled garden.

🔗Other considerations

One other complaint which has come up a bunch is around speed of innovation: the idea that WhatsApp or similar would be seriously slowed down by having to (effectively) maintain stable documented federation APIs, and figure out how to do backwards compatibility for new features. It’s true that this will take a bit more effort (similar to how adding GDPR compliance takes some effort), but the ends make it more than worth it. Plus, if the rag-tag Matrix ecosystem can do it, it doesn’t seem unreasonable to think that a $600B company like Meta can figure it out too...

Another consideration is that it might make it too easy to build malicious 3rd party clients - e.g. building your own "special" version of Signal which connects to the official service, but deliberately or otherwise has security flaws. The fact is that we're already in this position though: there are illicit alternative clients flying around all over the place, and the onus is on the app stores to protect their users from installing malware. This isn't reason to throw the baby of interoperability out with the bathwater of bootleg clients.

The final complaint is about moderation and abuse: while open APIs are good news for consumer choice, they can also be used by spammers, phishers and other miscreants to cause problems for the users within the gatekeeper. Much like a mediaeval citadel; opening up your walled garden means that both good and bad people can turn up. And much like real life, this is a solvable problem, even if it’s unfortunate: the benefits of free trade massively outweigh the downsides of having to police strangers more effectively. Frankly, moderation and anti-abuse approaches on the Internet today are infamously broken, with centralised moderation by gatekeepers producing increasingly erratic results. By opening the walled gardens, we are forcing a much-needed opportunity to review how to empower users and admins to filter unwanted content on their own terms. There’s a recent write-up of the proposed approach for Matrix at https://element.io/blog/moderation-needs-a-radical-change/, which outlines one strategy - but there are many others. Honestly, having to improve moderation tooling is a worthwhile price to pay for the benefits of open APIs.

So, there you have it. Hopefully you’ll agree that the benefits here outweigh the risks: without open APIs we wouldn't even have the option to talk about interoperability. We should be celebrating a new dawn for open access, rather than fearing that the sky is falling and this is nefarious attempt to undermine end-to-end encryption.