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.
In terms of Spec Core Team MSC focus for this week, we’ve still got MSC2366 (verification flows) and MSC2399 (UISI messaging), however they are now joined by a third, secret MSC that we’ll be working on internally for now :)
Spec releases: Room Version 6, Client-Server r0.6.1, and Federation r0.1.4
As always, any questions about the spec itself can be answered in #matrix-spec:matrix.org, #matrix-dev:matrix.org, or in the various area-specific rooms floating around the federation.
Hello again! This week I worked on access control, which means that private rooms are private and invite-only rooms are invite-only. The public room directory only shows rooms marked as such now.
I also made a milestone to track progress on Conduit 1.0. This release marks the point where Conduit is fully usable as a non-federating homeserver. All features of the client server specification should be implemented, unless they can be seen as optional extensions (e.g. alternative registrations methods like email). Conduit should also be free of all known bugs with those features.
Adding federation on top of the 1.0 release will very likely require breaking changes. This means that the release which brings federation will be 2.0 or later and will require a partial or full database deletion.
The monolith now has a “hybrid” mode that uses the full HTTP APIs instead of short-circuiting
A number of the internal HTTP APIs are now tested fully and have been fixed as a result, which will also improve running a full polylith component deployment
Server keys are now managed by a separate server key API component
Batched sends in the federation sender are now working properly, improving send performance significantly
Error handling in the federation /send endpoint has been tweaked
/get_missing_events now returns events that don’t fail signature checks
Federated room joins by room alias now attempt the server specified in the alias much more reliably
The correct room ID is now returned from the PerformJoin API
Much of the room server storage code has been deduplicated
Fixed some bugs in the device database storage code
Sync streams are now managed per-user-per-device, rather than just per-user
We no longer incorrectly default to federated joins in response to local invites
Spec compliance:
Client-Server APIs: 34% (228/672 tests)
Federation APIs: 34% (35/103 tests)
Synapse
Says Neil:
The main news this week is that we switched event persistence away from the matrix.org master process which has made a big difference to overall performance. The impact is best demonstrated by graphing message send times.
We also shipped 1.14.0 which includes OpenId Connect support and improved cache control granularity. It also contains rooms v6.
Next week will be having a think about what to do next for matrix.org performance. Watch this space.
TARDIS (Time Agnostic Room DAG Inspection Service)
I made a TARDIS (Time Agnostic Room DAG Inspection Service) - a simple time-travelling debugger for Room DAGs which plugs into Dendrite’s internal APIs to visualise room DAGs. The intention is to provide it as a widget which Riot can use to visualise DAGs for debugging, particularly for P2P Matrix. The time-travel bit is simply that it could let you filter out the newer events to show how the DAG has evolved over time, although that isn’t hooked up yet. https://github.com/matrix-org/tardis
With the release of synapse 1.14.0 the avhost image, including jemalloc, mjolnir and coturn has been updated as well, avhost/docker-matrix:v1.14.0, as always the release candidates were uploaded at mvgorcum/docker-matrix:v1.14.0rc1 and rc2
ruma-serde 0.2.2 (an internal dependency) fixed an incomplete part of querystring deserialization, so Conduit (and other future homeservers building on ruma-*-api) can properly handle querystrings in which parameters are repeated (like the server_name in /join/{roomIdOrAlias})
Option to only get notifications on finished builds was added.
buildbot-matrix is a small plugin for the Buildbot CI framework which sends notifications to matrix rooms.
It’s available an GitHub and PyPi, take a look at https://github.com/HayWo/buildbot-matrix for more information.
I, Half-Shot, changed the status of the IRC Bridge on https://matrix.org/docs/projects/bridge/matrix-org-irc-bridge from “Early beta” to “Stable”. This does not mean it’s feature complete, or even all the way there, but it sure doesn’t crash nearly as often as it did when I started, so that’s good enough for me.
Hey folks, we’ve released the first RC for 1.4.0 of the slack bridge. This change includes a number of bug fixes around puppeting, but includes a few nice to haves like a /ready endpoint for kube/docker deployments and setting profile information on startup. Please test, and feedback in #matrix_appservice_slack:cadair.com :)
I’ve been working on improving the reliability of my bridges, primarily by making sure that the user knows if something went wrong. All my bridges now support delivery receipts (implemented as bridge bot read receipts) and can send delivery error messages if there was an error bridging a message. The Facebook and Hangouts bridges also now send connection status messages to a bridge notice room like WhatsApp already did before.
Minetrix
Certainly not from this week, but we haven’t featured it before: Minetrix allows you to bridge a Minecraft server with a Matrix room.
A Matrix webclient written in (mostly) Rust using the official Matrix-Rust-SDK and Rusts WASM Support.
Daydream is the Idea of a Rust Matrix Client. It is still in a very early state and at the time of writing this supports basic displaying of text, image and bot messages as well as sending plain text and markdown.
Thanks devinr528 for sharing this
WIP Command line Matrix client using matrix-rust-sdk:
Display read receipts for the last few messages
Display membership status when updated
Join a room you have been invited to
Client sends read receipts to server
Display when messages have been read
Leave a room by pressing Delete key (this should probably be a Ctrl-some key deal…)
Specify homeserver to join on start up (before the login screen)
Simply run rumatui [HOMESERVER], defaults to http://matrix.org
Displays errors, albeit not very helpful or specific
Receive and display messages
formatted messages display as rendered markdown
Send messages
local echo is removed
Send textbox grows as more lines of text are added
Selectable rooms list
change rooms using the arrow keys, making this clickable may be difficult
Login widget is click/arrow key navigable
hides password
A new notification bar under the message window displays notifications such as membership changes, typing, and read notices.
I am hoping to have an actual release on crates.io by the end of the day. If you have any thoughts join #rumatui:matrix.org or check it out on github.
starting work on shifting the UX for the encryption upgrade towards using recovery keys in favor of passphrases.
starting early work on a redesigned matrix.to website
starting looking to integrate riot desktop with the native password manager of your platform of choice through keytar
fixing some issues with the (still experimental) IRC layout
iterating on the (also still experimental) new room list
looking into some issues that arose from the cross-signing release
Riot-iOS
Says Manu:
Riot-iOS (and MatrixSDK and MatrixKit) is now fully compatible with iOS13 SDK. A TestFlight 0.12.0 will be available soon.
The work is still on its branches (xcode11). It comes with the new notification service mechanism and we want to run a lot of tests next week before going to production.
Nheko
Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE (with the notable exception being device verification for now) and intends to be full featured and nice to look at
After explaining cross signing to others multiple times in the past and seeing the question again on mastodon, I decided to write a short blog post on the topic, explaining how the keys interact with each other and how Alice’s devices then end up trusting Bob’s devices. You can read it over on https://jcg.re/blog/quick-overview-matrix-cross-signing/
Cross-signing implementors guide
This one isn’t quite merged yet as we’re going to give a thorough review, but big thank you to sorunome for taking the time to put this together:
While implementing cross-signing for fluffychat soru decided to write a guide that would help other client developers to implement that, too. So far it is still WIP and doesn’t cover too much, yet, but soru might have typed up more once this TWIM goes live. The PR (and thus the markdown of the guide) can be found here: https://github.com/matrix-org/matrix.org/pull/740
It’s a bunch of people who are passively learning design for their matrix projects. You might pick up a few things if you join :p
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. Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
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.