Dept of Spec 📜
Andrew Morgan (anoa) says
- MSC3984: Sending key queries to appservices
- MSC3983: Sending One-Time Key (OTK) claims to appservices
- MSC3982: Limit maximum number of events sent to an AS
MSCs in Final Comment Period:
- No MSCs were accepted this week.
The Matrix.org Foundation (mostly Travis) are beavering away preparing for the MIMI meeting at IETF 116 this weekend! This is part of our continual work to contribute to a IETF standard that can be used for interoperable messaging between gatekeepers (large companies in the chat world) under the EU's Digital Markets Act. See our earlier blogpost for more context on this topic.
In terms of our previous proposals on this subject; it turns out that implementing full-scale DAGs is a bit difficult, particularly when aiming to achieve interoperability on a short timeline. So we've been working on building an API surface for Matrix which makes rooms easier to access/implement in chat settings. We unfortunately don't have much to share today, but keep an eye on next week's TWIM for details 👀
Random MSC of the Week
The random MSC of the week is... MSC3480: Make device names private!
This MSC proposes hiding device names from any other user, while still allowing your own devices to see the names of the others.
You may question why device names being shown to other users was considered a good idea at all in Matrix. Initially these being public was really useful for verifying the devices of other users! Back in the days before cross-signing (where you only need to verify another user once), you had to verify every one of your friend's devices from every one of your own devices. It was an n * m problem, whereas if you had 4 devices, and your friend had 5, you'd need to do 20 verifications! And 4 more if your friend got a new phone!
So having device names back then were handy, but today any justification is moot and they're just a metadata leak. So we should get rid of them!
This MSC is blocked on a proven implementation. I actually wrote one up for Synapse a little while ago, and I plan to polish and merge it soon. Anyone else is free to do so in the meantime as well (just let me know first if you plan to do so in Synapse :).
Here's to improved privacy by default in Matrix!
Dept of Servers 🏢
Synapse is a Matrix homeserver implementation developed by the matrix.org core team
The days just keep flying past and it's Friday again (how???). We here at Synapse have released v1.80.0rc2, filled with features and bugfixes. Some notable highlights are:
- Fix a bug introduced in Synapse 1.75.0rc1 where the SQLite port_db script
would fail to open the SQLite database
- Fix a long-standing bug in which the user directory would assume any remote membership state events represent a profile change.
- Mirror images to the GitHub Container Registry (
- Allow loading
/register/availableendpoint on workers
and much more! If you'd like to take a deep dive you can find the release notes here.
A performance-oriented homeserver with minimal dependencies.
Jason Volk says
This week Construct introduced Peristalith Mode in an effort to fill the void left by last week's unfortunate demise of Dendrite's Polylith mode. Peristalith allows multiple instances of Construct to scale together in a hub-and-spoke configuration. This is a single-writer/multiple-reader strategy which uses the filesystem to share data between instances. In the long run, we're still working on Construct Cluster which is a homogeneous multiple-reader/multiple-writer design using Matrix itself for communication. For now, this is an improvement over simply not having any solution in case your deployment really needs to shed some load quickly. I'd like to thank Yan Minari for coming up with some Traefik configs for this and we're going to be spending the weekend playing around with it.
Let us know your needs for scaling your homeserver in #construct:zemos.net
Dept of Clients 📱
iamb, a terminal-based Matrix client that uses Vim keybindings, had a new release this week. Release v0.0.7 includes:
- Room state events are now lazily loaded in the initial sync to help w/ memory usage and timeout issues
- New configuration options for adjusting log level and HTTP request timeouts
- Several bug fixes and improvements for displaying messages in the scrollback
iamb-gitpackage has been added to the Arch User Repository (AUR)
- Release builds now use LTO
Desktop client for Matrix using Qt and C++17.
0xDEADCADE fixed a few dialog windows, that would get a width of 0 on some window managers. Meanwhile tastytea made the scroll down button automatically refocus the message input.
The other work (apart from some cool work in progress stuff, was mostly minor improvements to communities. LcsTen made unjoinable and unpreviewable rooms in a community now hidden by default. This matches what the /hierarchy API does and as such what other clients show and since you have no way to fix it, why bother you with it? Admins of a community can still see those rooms and are suggested to remove them, since nobody will be able to join them. While the upsides generally outweigh them, there are a few downsides to this approach. Some users will never see some rooms in a community now and will have no way of telling you about the room not being joinable. Note that this only affects rooms added using a m.space.child event. The correct way to add a hidden room to a community, is by only setting a parent in that room. But many clients don't do that or rooms just naturally become unjoinable because of membership changes.
The last one is now properly handled in Nheko. Nheko will regularly update the join information for community rooms now. Each space child or parent event usually includes some routing information to figure out, what servers are in the room. If that server list is outdated, you will not be able to join the room, because none of the servers in the list know about the room anymore. Nheko now checks every 20 minutes if any of your space relation events haven't been updated in more than a week and if that is the case (and you have space edit permissions), it verifies that the routing information would still be the same if Nheko updated it. If it isn't, Nheko will write the new routing information into the state event. This is a bit of a compromise, since you might have more member changes in 7 days and the room can still become unroutable, but this is done to prevent to frequent updates if clients come to different results for the routing information. This should improve the long term experience of communities by a lot, since you won't have them randomly break anymore.
I talked a lot about routing information now. The spec actually has a section for how to calculate that: https://spec.matrix.org/v1.6/appendices/#routing. Nheko now implements that algorithm slightly more correctly, but we still don't implement everything. This should make room links look more reasonable and prevents some of the problems talked about in the previous section. Some parts I haven't implemented yet though. Nheko does not ignore ip address only servers (for now). And we also decided to ignore the powerlevel >= 50 requirement and changed it to users that have a
powerlevel >= max(events_default, state_default). This is done, because the spec handwaves away concerns, that rooms might have non-default powerlevels, but I am in a lot of those and it would be annoying to me.
I guess this was a bit of a more technical update this time, but maybe it had some interesting bits. I spent a lot of time the last weeks fixing stuff in Qt, profiling memory usage as well as code size and others are working on cool stuff as well, so stay tuned for next week. :3
Small update from FluffyChat:
- I'm currently finalizing the long requested "Jump to last read message" feature (see screenshot)
- A workaround for Linux arm64 not building has been applied so we will soon publish arm64 on Flathub again (snap has to wait a little bit longer)
- FluffyChat v1.10.0 is now in all stores
- Next version of FluffyChat will display a read marker in the chat
- FluffyChat will now use a SliverList widget for the chat list page, which means that the search bar will disappear on scroll down and pop up on scroll up like in other Material3 apps
- Some work on cleaning up the huge CI scripts have been done to make contribution Merge Requests more easy
Element iOS (website)
Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!
- Yet another packed week in iOS land. Starting with ElementX we have made great progress on structured logging, migrating our translations to Localazy, adding support for ignoring users and the DM creation flows. We have also fixed offline mode, UI tests and added form styles to Compound. In the background we’ll still working on tracking down our more complex bugs, adopting async-uniffi and improving our developer experience
- In Element iOS there’s a new release out, with new and improved links for users, rooms and messages and we released a hotfix for a regression which affected a small proportion of users at one point this week.
Element Android (website)
Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!
Jorge Martín says
- This week the Element X team for Android have been working on setting up push notifications, permission management, shared localization with iOS and independent releases for the Rust SDK for Android and the Crypto Rust SDK. There have also been work around polishing the session verification and server selection flows and creating a new room details screen.
- On Element Android the way pills are rendered in the timeline has been improved to fix issues with very long pills.
- We are looking for an Android developer to join our team to work on Element X. If you’re interested, you can find more info here or reach out to @johannesm:element.io.
Dept of SDKs and Frameworks 🧰
We're getting closer and closer to a version 1.0.0! Today, I hacked a a quick and ugly demo to show off Elm's capabilities. The website lets you log in using an access token and the homeserver's base url, after which you can send and receive cookies 🍪 to your friends. :)
Since last week, the SDK now supports login functions at all spec versions, and banning users is now supported as well. If you're curious about the last few struggles to build a rigorous SDK in a functional language, join the discussion at #elm-sdk:matrix.org to keep track. :)
Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM
Jonas Platte says
Dept of Bots 🤖
A Matrix bot for the Friendly Linux Players community.
Events can now have a game server and password associated with them, and these are displayed in various places. For example, you can see this on the web page for the upcoming Arma 3 event this weekend: https://friendlylinuxplayers.org/events/d0a29709573b0fe7
Dept of Interesting Projects 🛰️
The next generation of Integration Managers is finally here!
(with a familiar bridge backing it!)
I am once again happy to report on our latest integrations work at Element. A couple of weeks ago you heard from me and Justin on the new Integration manager that we've been working away on and we're pleased to announce it's now LIVE and has replaced our old IM, Scalar.
Alongside the new IM, we've replaced the old Go-NEB powered bots with their matrix-hookshot equivalents. This means you can now press buttons to migrate yourselves off the old bots. As an aside, all the changes we've made to hookshot to scale up for the big release are of course landing in the open source project, should you wish to spin up your own bots instead. We're hoping that the ability to now embed our all-powerful config widgets directly into the integration manager will make it easier to add new features to these already-powerful bots.
If you encounter any issues, please post an issue in https://github.com/vector-im/element-integration-manager/issues where we will be happy to assist!
Dept of Ping
Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
That's all I know
See you next week, and be sure to stop by #twim:matrix.org with your updates!
The Foundation needs you
The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.
It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.Support us