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, unfortunately our three MSCs from last week ( MSC2366 (verification flows), MSC2403 (knocking), and MSC2630 (SAS security)) are still pre-FCP. Most of the team has been quite busy with implementation for the past few weeks. Instead of advertising those 3 MSCs again, weāre going to switch the focus to āimplementationā for a bit until weāre freed up again.
So the focus for this week is: MSC implementation work. However, this should not discourage any MSC authors from responding to MSC feedback in the meantime š
This week in the ruma/matrix Google Summer of Code project, ruma-events was made ready for use! After adding stripped and sync event generation to the event_enum! macro there were only a few small tweaks needed to try it out in some dependent rust crates. I spent a few days converting matrix-rust-sdk to use the ruma-monorepo. Since ruma is used on both client and server-side, I also opened a PR to update Conduit, a homeserver implementation written in Rust. To test that everything worked together, I updated rumatui, my command-line client written in rust.
Then I could test that Conduit sent, and matrix-rust-sdk received the new ruma events successfully. While updating, I felt the pain of not having accessor methods for the Any*Event enums to get at the event fields held within. I have opened a pull request to add the generation of these methods to the event_enums! macro. Hopefully, the Conduit and matrix-sdk PRās will be merged and the ruma monorepo can be tested in the wild!
Moved matrix protocol, irc protocol, and bridge module to futures 0.3. Converted some utility functions to new futures, and updated the http implementation to use the standardized Hyper library instead of using a custom http implementation.
Created PR for enabling e2ee across all services! This required a few changes to how the bot client is initialised, as well as changes to all services to use the new functionality instead of directly sending messages to a room. https://github.com/matrix-org/go-neb/pull/324
Added code from another of tulirās projects to Mautrix to allow storing the crypto material (olm / megolm sessions, accounts etc.) in a SQL database, adding a second way besides using Gob storage. https://github.com/tulir/mautrix-go/pull/10
Future plans are to work on the library itself to add any features that might be missing.
This week Iāve worked on the following features for the project āHTML embeddable chat roomsā under GSoC ā20:
Added support for signing-in
Via sign-in popup
The user can enter their credentials into the modal dialogue box.
Via postMessage interface
iframe.contentWindow.postMessage({
cmd:'login',
args: {
user:'username',
passwd:'password'
}
}, origin);
Arguments:
args (object):
username (string) - Username
passwd (string) - Password
Response:
{
status: 'success',
message: 'Attempting sign in...'
}
Added support for default avatars
Using the same design as Riot. However, I am just using flexbox and text instead of drawing on an HTML5 canvas. The HSL color is generated by hashing the user ID.
Quoting and replying
Added on-hover buttons and reply popup above message composer similar to Riot web. Quoting prepends the message (quoted) to the message composer similar to Riot web and replying would also work similar to Riot web. It will be fully functional once markdown parsing is added.
Guest access
The client now supports guest access. If no access token or user ID is provided in the configuration file, the client attempts to register a guest account on the home server. Room contents are viewed using peekInRoom.
If the guest attempts to send a message, only then joinRoom is called to avoid spam (each page load would lead to a guest joining the room).
This week has been mainly about testing to ensure that all the progress over the past few months is kept up-to-date and correct. Weāve also added a few features in order to get certain sytests working. To that end:
Invites can now be declined over federation and they will be reflected in /sync responses.
Errors encountered when joining a room over federation are now sent back to the client.
Errors encountered when accepting an invite over federation are now sent back to the client.
Dendrite will now check server names meet the server name grammar in the specification.
A bug which caused client-api-proxy to not actually proxy correctly has been fixed, thanks @fantashley !
/send now abides by the limits in the specification: 50 PDUs / 100 EDUs.
The docker-compose scripts now include appservice_api, thanks @fantashley !
Sending invites over federation will now fall back to v1 if v2 fails with a 404.
Dendrite now implements room.timeline.limit completely (in both in-line and stored filter formats).
Dendrite now sets the limited flag on /sync responses correctly.
In addition, we now have support for collecting code coverage output from SyTest. This indicates we are testing roughly 70% of the Dendrite codebase. The remaining 30% are hard to reach via integration tests (e.g database failures, communication problems between internal APIs).
Spec compliance:
Client-Server APIs: 45%, up from 40% last week
Server-Server APIs: 50%, up from 38% last week
In total, weāve made an additional 45 sytests pass this week.
This week weāve been working on further improvements to event persistence and ironed out a nasty bug where an unusually long state resolution could block the reactor overall and impact send times. We seem to have got to the bottom of this and m.org has improved a lot as of today.
More generally weāve been trying to characterise matrix.org performance so that we can continue to improve over the coming months.
We are going to focus on:-
Client send event
Outbound Federation Latency
Inbound Federation Latency
Room joins
As well as tracking the CS API generally.
We are using apdex with a satisfied limit of 250 ms and a tolerating limit of 1000 ms. By the end of the Summer we will aim to hit an apdex score of 0.9 for each area.
For instance here is Federation Send Event Apdex graphed overtime. You can see that we are averaging about ~0.8 currently, so plenty to keeping us busy!
Next up will be to work on Outbound Federation Latency
Aside from that weāve been working hard on the upcoming Notifications improvements. Mapping the push rules to the demands of the UI has been challenging and weāve been through several iterations. If youād like to learn more take a look at Michael and Richās explanation in this weekās Matrix Live. Richās presentation has Sheltie pictures #justsayinā
The Telegram bridge now supports logging in by scanning a QR code, although it requires using the master branch of Telethon instead of a release. I also fixed bridging captions in file messages, so theyāre now bridged as separate messages like with images
Hey all, Iāve got several releases to talk about this week!
First, matrix-appservice-slack has been updated to 1.4.0 with several quality of life changes such as automatically setting the bot profile on startup, supporting logging out of slack accounts and adding a health checkpoint. There are also quite a few bugfixes so make sure you update.
matrix-appservice-irc was also bumped to 0.18.0 with the headline features being Node 14.x support.
Weāve also shipped 0.19.0-rc1 which has stopped support for Node 10.x. Why? Because weāre adding worker support to the bridge! This release starts to make use of the new(ish) worker_threads feature so that we can dish out processing to separate threads (running their own UV event loops, for node enthusiasts). The first thing to be workerized is metrics, so that metrics may still be reported should the bridge become saturated, but we plan to split out more work as things progress.
Finally matrix-appservice-bridge got a few fixes to support our new worker land, as well as being updated to support matrix-js-sdk 6.0.0. You can checkout the changes for 1.13.1 here.
Fluffychat Version 0.15.0 is released, and should be available in the Play Store, on F-Droid and in IOS Testflight soon! This makes Fluffychat the first non-Riot matrix client that supports Cross-Signing.
Features:
New room list app bar design
Chat app bar transparent
Implement web file picker
Minor design and UX improvements
Implement Cross Signing
Restore keys from online key backup
Added translations: Czech, Spanish, Slovakian
Changes:
Show presences of users sharing a direct chat
Big refactoring
Fixes:
Various fixes, including e2ee fixes and olm session recovery
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
Most of our time this week was spent trying out device verification with Chethan. Itās fun and I could finally file bugs in Nheko against someone else!
We fixed some issues that should hopefully make text in the timeline less blurry again.
Fixed a bug which cause some clients like fluffychat to break in E2EE rooms (we accidentally sent a null relation when not replyingā¦)
Fixed an issue, where Nheko didnāt verify the format of html formatted messages correctly, causing it to render messages in a way which wasnāt compliant to the spec.
Thanks to the work of a Pirate and his friends, current versions of Nheko should be available in backports for Debian Buster once again!
Riot Chat for Nextcloud 0.5.0 The new version updated the Riot.im version to 1.6.6 and added the ability for admins to set their own custom config for Riot rather then using the settings interface in addition to a few bug fixes.
Riot Chat for Nextcloud allows individuals and organizations with a Nextcloud instance to easily set up and configure their own Riot instance with just a few clicks on a web interface without the need to write a config file.
This week, we completed UX for cross-signing and secure backup. We made associated settings but we still need to polish them.
Sygnal and the new push extension have been updated to match Apple requirement and our privacy concerns. Events content are no more sent anymore.
We started to implement the new room notifications settings UI.
We will publish at the beginning of next week a beta version of the migration to RiotX codebase on the beta channel of the PlayStore, to be able to ensure the migration works fine, before release it to production.
joepie91 discovered this project, presented yesterday at Conference in the Cloud:
Net::Matrix::Webhook implements a webhook, so you can easily post messages to your matrix chat rooms via HTTP requests. It uses IO::Async to start a web server and connect as a client to matrix. It will then forward your messages.
Soru wrote a quick program that scrapes riot-web, riot-x and riot-ios for translations of the emoji names for emoji verification and combines them all into an easily-readable json file, so that other client developers can use it. Since all three riot versions have a different set of translations, it might also be helpful for them. You can find the source code along with the outputted json files here.
Like the other bots, you can self-host it, use my instance (@satw:maunium.net) in your own room or simply join #satwcomic:maunium.net to automatically get the latest comics in Matrix.
A bot that will allow to room administrators and moderators to generate room custom commands (in a similar way how telegram commands are thought).
When they are invoked it will post the message event object data and a predefined context object along with a token to a custom url. More information in: https://gitlab.com/communia/matrix-webhooker
Drupal module to receive links shared from a matrix room. Get links provided by a matrix bot in a room.
With this module one can get media from a matrix own bot to any drupal site. Once installed and bot is created through matrix-webhooker bot.
A blog entry about it (in spanish) in https://planet.communia.org/content/enlaces-desde-matrix
Dept of Interesting Projects š°
Pollvis - new poll visualiser project
We have a couple of conferences coming up who are planning to use Matrix as part of their offering, much as we do with Open Tech Will Save Us. To help add some more features, I created an MVP āpoll visualiserā, which watches a room and works in tandem with the poll-bot from Brendan Abolivier . This project is still at the beginning, but might be interesting to some! Find the code at https://github.com/benparsons/pollvis.
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.
Rank
Hostname
Median MS
1
fairydust.space
331
2
services.pyrahex.com
537
3
heitkoetter.net
604
4
nitro.chat
646.5
5
mchus.pro
660
6
privacytools.io
671
7
matrix.vgorcum.com
727.5
8
eiselecloud.de
740
9
aruiz.io
855
10
neko.dev
923.5
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.
