We’re very excited indeed to announce that Automattic, the creators of WordPress.com, are jumping head first into the Matrix ecosystem with a strategic investment of almost $5M into New Vector (the company which makes Riot and Modular.im, founded by the core Matrix team in 2017). More importantly, Matt Mullenweg (co-founder of WordPress and founder of Automattic) and the Automattic gang are committing to make the most of Matrix in their work going forwards!
This is huge news, not least because WordPress literally runs over 36% of the websites on today’s web - and the potential of bringing Matrix to all those users is incredible. Imagine if every WP site automatically came with its own Matrix room or community? Imagine if all content in WP automatically was published into Matrix as well as the Web? (This isn’t so far fetched an idea - turns out that Automattic already runs a XMPP bridge for wordpress.com over at im.wordpress.com!). Imagine there was an excellent Matrix client available as a WordPress plugin for embedding realtime chat into your site? Imagine if Tumblr (which is part of Automattic these days) became decentralised!?
In fact, if you’re a developer in either the Matrix or WordPress communities, now might be a good time to think about how to cross the streams.... not least because Automattic just opened up a role for a Matrix.org/WordPress Integrations Engineer! Quite aside from the investment, this shows Automattic is serious about Matrix - and we’d like to thank them for opening up jobs in these challenging times to further accelerate Matrix. Perhaps some day Matrix Engineer will be as common a career choice as Web Developer ;)
That said, it’s super early days for integration work, and there isn’t a concrete project to announce yet beyond the investment in New Vector (which is effectively an extension of the funding NV raised in October) and Automattic’s Job opening - but these are the sort of ideas we’ve been kicking around. And at the very least, we should expect to see Automattic’s communities migrating over to Matrix in the coming months.
It’s been loads of fun working with Matt and the team on this: we see a huge overlap in terms of a genuine love for the open web, open source and open standards. It’s also no coincidence that Matt (independently of Automattic) donated substantially to Matrix via Patreon back in 2017 when we needed it the most. We’re also looking forward to benefiting from Automattic’s experience in sustainably and responsibly funding and growing open source projects in general - WordPress.com is an excellent example of how one can support development of a project like WordPress without compromising its open source nature.
So, we’d like to formally welcome WordPress and the rest of the Automattic family into Matrix. It’s incredibly exciting times, and we can’t wait to see what will come of the partnership! And meanwhile, if any other massive open source organisations want to join Automattic and Mozilla in leaping into Matrix, you know where to find us… :D
Huge thanks go to Matt for believing in Matrix - watch this space for updates.
Highlights include new support for User Interactive Authentication (UIA) for Single Sign-on (SSO) installations. This means that for the first time features that require the user to re-authenticate are available for servers that authenticate by SSO. Notably this means that these servers now support cross signing!
SSO admins should take a look at the SSO notes in the changelog.
We have been working hard on performance for large scale installations. Anyone supporting more than a few thousand users is probably running Synapse in worker mode. This means splitting out functionality from the master process and making use of multiple cores (or machines) to spread the load. Cross process communication was previously handled by a home grown TCP based replication protocol. As part of our ongoing efforts to improve performance we have replaced this replication system with Redis and have been running Redis in production on matrix.org for the past 2 weeks.
Redis itself does not provide a significant performance win directly but it means that it is much less expensive to add new workers to a cluster. The topology of the old system meant that every additional worker carried a small but not insignificant overhead to the master process. Since moving to Redis we have doubled the number of workers backing matrix.org.
We still consider Redis to be experimental and admins should not feel obliged to upgrade. However it looks very promising and we are likely to deprecate the old replication system in future. So watch this space - Redis is the future.
Finally we've seen lots of improvements to our documentation and many thanks for those in the community making contributions in this area.
It is also worth noting for those of you contributing to Synapse that the develop branch is now the default. More details in the changelog, so take a look.
Get 1.13.0 from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.
Changelog since v1.12.4
Synapse 1.13.0 (2020-05-19)
This release brings some potential changes necessary for certain configurations of Synapse:
If your Synapse is configured to use SSO and have a custom sso_redirect_confirm_template_dir configuration option set, you will need to duplicate the new sso_auth_confirm.html, sso_auth_success.html and sso_account_deactivated.html templates into that directory.
Synapse plugins using the complete_sso_login method of synapse.module_api.ModuleApi should instead switch to the async/await version, complete_sso_login_async, which includes additional checks. The former version is now deprecated.
A bug was introduced in Synapse 1.4.0 which could cause the room directory to be incomplete or empty if Synapse was upgraded directly from v1.2.1 or earlier, to versions between v1.4.0 and v1.12.x.
Please review UPGRADE.rst for more details on these changes and for general upgrade guidance.
Notice of change to the default git branch for Synapse
With the release of Synapse 1.13.0, the default git branch for Synapse has changed to develop, which is the development tip. This is more consistent with common practice and modern git usage.
The master branch, which tracks the latest release, is still available. It is recommended that developers and distributors who have scripts which run builds using the default branch of Synapse should therefore consider pinning their scripts to master.
Features
Extend the web_client_location option to accept an absolute URL to use as a redirect. Adds a warning when running the web client on the same hostname as homeserver. Contributed by Martin Milata. (#7006)
Set Referrer-Policy header to no-referrer on media downloads. (#7009)
Admin API POST /_synapse/admin/v1/join/<roomIdOrAlias> to join users to a room like auto_join_rooms for creation of users. (#7051)
Add options to prevent users from changing their profile or associated 3PIDs. (#7096)
Support SSO in the user interactive authentication workflow. (#7102, #7186, #7279, #7343)
Allow server admins to define and enforce a password policy (MSC2000). (#7118)
Improve the support for SSO authentication on the login fallback page. (#7152, #7235)
Always whitelist the login fallback in the SSO configuration if public_baseurl is set. (#7153)
Admin users are no longer required to be in a room to create an alias for it. (#7191)
Require admin privileges to enable room encryption by default. This does not affect existing rooms. (#7230)
Add a config option for specifying the value of the Accept-Language HTTP header when generating URL previews. (#7265)
Allow /requestToken endpoints to hide the existence (or lack thereof) of 3PID associations on the homeserver. (#7315)
Add a configuration setting to tweak the threshold for dummy events. (#7422)
Bugfixes
Don't attempt to use an invalid sqlite config if no database configuration is provided. Contributed by @nekatak. (#6573)
Fix single-sign on with CAS systems: pass the same service URL when requesting the CAS ticket and when calling the proxyValidate URL. Contributed by @Naugrimm. (#6634)
Fix missing field default when fetching user-defined push rules. (#6639)
Improve error responses when accessing remote public room lists. (#6899, #7368)
Ensure that a user interactive authentication session is tied to a single request. (#7068, #7455)
Fix a bug in the federation API which could cause occasional "Failed to get PDU" errors. (#7089)
Return the proper error (M_BAD_ALIAS) when a non-existent canonical alias is provided. (#7109)
Fix a bug which meant that groups updates were not correctly replicated between workers. (#7117)
Fix starting workers when federation sending not split out. (#7133)
Ensure is_verified is a boolean in responses to GET /_matrix/client/r0/room_keys/keys. Also warn the user if they forgot the version query param. (#7150)
Fix error page being shown when a custom SAML handler attempted to redirect when processing an auth response. (#7151)
Avoid importing sqlite3 when using the postgres backend. Contributed by David Vo. (#7155)
Fix excessive CPU usage by prune_old_outbound_device_pokes job. (#7159)
Fix a bug which could cause outbound federation traffic to stop working if a client uploaded an incorrect e2e device signature. (#7177)
Fix a bug which could cause incorrect 'cyclic dependency' error. (#7178)
Fix a bug that could cause a user to be invited to a server notices (aka System Alerts) room without any notice being sent. (#7199)
Fix some worker-mode replication handling not being correctly recorded in CPU usage stats. (#7203)
Do not allow a deactivated user to login via SSO. (#7240, #7259)
Fix room publish permissions not being checked on room creation. (#7260)
Reject unknown session IDs during user interactive authentication instead of silently creating a new session. (#7268)
Fix a SQL query introduced in Synapse 1.12.0 which could cause large amounts of logging to the postgres slow-query log. (#7274)
Persist user interactive authentication sessions across workers and Synapse restarts. (#7302)
Fixed backwards compatibility logic of the first value of trusted_third_party_id_servers being used for account_threepid_delegates.email, which occurs when the former, deprecated option is set and the latter is not. (#7316)
Fix a bug where event updates might not be sent over replication to worker processes after the stream falls behind. (#7337, #7358)
Fix bad error handling that would cause Synapse to crash if it's provided with a YAML configuration file that's either empty or doesn't parse into a key-value map. (#7341)
Fix incorrect metrics reporting for renew_attestations background task. (#7344)
Prevent non-federating rooms from appearing in responses to federated POST /publicRoom requests when a filter was included. (#7367)
Fix a bug which would cause the room directory to be incorrectly populated if Synapse was upgraded directly from v1.2.1 or earlier to v1.4.0 or later. Note that this fix does not apply retrospectively; see the upgrade notes for more information. (#7387)
Fix a long-standing bug which could cause messages not to be sent over federation, when state events with state keys matching user IDs (such as custom user statuses) were received. (#7376)
Restore compatibility with non-compliant clients during the user interactive authentication process, fixing a problem introduced in v1.13.0rc1. (#7483)
Hash passwords as early as possible during registration. (#7523)
Improved Documentation
Update Debian installation instructions to recommend installing the virtualenv package instead of python3-virtualenv. (#6892)
Improve the documentation for database configuration. (#6988)
Improve the documentation of application service configuration files. (#7091)
Update pre-built package name for FreeBSD. (#7107)
Update postgres docs with login troubleshooting information. (#7119)
About a year after this tweet, four months after deployment of our open source @matrixdotorg instance, community participation in the Mozilla project has increased from 4x to 10x across all the projects that previously relied on IRC.https://t.co/E5HRsfHkzk
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, MSC2526 has entered FCP. We'd like to keep the E2E MSCs in flight in focus, but are also conscious that room v6 is coming up. We're sticking the MSCs for the latter alongside the existing E2E ones in the focus queue, for a total of 5. Those MSCs are: MSC2366 (verification flows), MSC2399 (UISI messaging), MSC2540 (canonical JSON validation), MSC2209 (notifications auth rules), and MSC2240 (room version 6).
Dept of Servers 🏢
Dendrite / gomatrixserverlib
Dendrite is a next-generation homeserver written in Go
This week I worked on presence and end to end encryption, but they are not working yet.
Meanwhile, Valkum got sytest integration working! This means each time a new commit is pushed to a branch, CI automatically picks up on that and lets a lot of tests run on the homeserver - the same tests that synapse uses. Currently we have 8% of all tests positive on Conduit.
Synapse v1.13.0rc2 shipped this week with the following notable improvements:
SSO support in User-Interactive Authentication sessions
Cross-signing device list bug fixes
The ability to run in worker mode using redis as a backend (which will soon be considered the default transport for Synapse workers)
Some admin api improvements and additions
...as well as all the usual bug fixes and especially performance improvements. See the changelog for the full details and please test if you can! A full release is expected early next week.
Speaking of next week: work will involve getting room version 6 ready to ship, alongside even more performance work - especially moving event processing off the master process (the code for which is already running successfully on Half-Shot's own homeserver)!
I've been working on a new puppet bridge for steam chat mx-puppet-steam, while I would still consider it to be in alpha state, most of the things needed for day to day chatting are functional.
It bridges both one on one and group messages, shows the proper name, avatar and online status of your frends and handles embedded images in one on one chats.
As promised last week, mautrix-whatsapp now has end-to-bridge encryption (currently on the e2be branch, will be merged to master soon™). It works mostly the same way as the other bridges.
Dept of Clients 📱
It's a big, big week for client news! We must take a deeper look at some of these projects soon!
I got really bored in lockdown, as we all have. I stared at my TV, and it stared back at me. While it's definitely a privacy nightmare to start developing apps for these things, I couldn't help myself. I got stuck in, and secured myself a LG Developer Account.
The LG set of smart TVs use WebOS, as like the name suggests, runs apps in it's special variant of Chromium. I was lucky to be running a recent OS and had access to Chromium 53! And NodeJS 0.12!! Sarcasm aside, there are some very troubling versions of WebOS with much older versions of the browser, so I was happy to be developing against something with strong ES6 support. Despite the absolutely awful onboarding experience, the WebOS SDK itself was pretty good. matrix-tv was written to be a general large screen matrix client, so it talks to the TV's own libraries through an abstraction layer :)
Anyway, this client is the culmination of a lazy Sunday afternoon's work. It features very basic support for viewing a room, but I hope to expand it at some point. It supports running in a web browser and the aforementioned OS, but support for more variants is easy to add. I'm looking into how to design for the large screen beyond making fonts bigger, because the unique constraints on memory and UI are fun challenge.
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
Nheko now supports SSO. If your server uses SSO, you may want to test that, if it works for you, but I did successfully sign into the Mozilla homeserver.
We improved hinting on the login and registration pages, so it should be easier to enter correct credentials.
Replies now have a max height by default. If you want to see the full reply, you need to click on it to navigate to the reply.
Nheko now has a red unlocked padlock, when an unencrypted message is sent in an encrypted room.
red_sky has been hacking along on reactions. Displaying them is now in master, for sending he is currently reworking the emoji picker, so that it can be attached to the timeline more easily and it is easier to search, etc.
We are making progress on Identity server feature implementation (PR in review). Also we are working to integrated call with WebRTC, integration manager (widget, Jitsi, sticker) and we are stabilizing the application, especially on the cross-signing part.
Expect a new corrective release at the end of the day!
I was able to solve a few annoying bugs like message history disappearing and switching rooms taking time (it turned out that read receipts were being sent synchronously), so I decided to release gomuks v0.1.0.
Riot-Android: Version 0.9.11 (with Matrix SDK 0.9.34) has been released on the PlayStore, and should be available for all during the week-end. It contains fixes on the identity server feature (the "missing token" thing), and also support Jitsi call with configured domain.
This SDK is now on maven central. I also introduced support for implementing Application Services. The project can be found here: https://github.com/benkuly/matrix-spring-boot-sdk . It will be used by Matrix-SMS-Bridge, which only needs one telephone number. The latter will be released next week, when everything works fine (https://github.com/benkuly/matrix-sms-bridge).
Add the ability to defer all processing to a different isolate
When you use isolated: true on Homeserver.login or MyUser.fromStore, everything will be handled for you and the SDK works the same.
This only works on platforms with the Dart VM (not web).
Updaters are now globally registered per MyUserid.
This means for now only one Updater per MyUser is allowed. Updaters are created when a MyUser instance is retrieved via Homeserver.login or MyUser.fromStore
Add ability to specify what rooms to load from store when retrieving user
The previousBatch param from Room.copyWith is removed (wasn't used)
Add ability to override context in MyUser.copyWith and MyUser.merge
Updater and Homeserver are less coupled now
When a Context is changed with copyWith, all child objects' contexts are also changed
Fix bug in read receipt parsing (thanks to MatMaul!)
Sync errors are now pushed to the updates stream
Fix access token not being passed to logout API
Add type to RequestUpdate, so you can see which type of call
The purpose of the bot is to provide a link with Jupyter kernels running either on your local computer or somewhere else on a server. You can access your kernels through the bot with the chat interface. The kernels will answer to your commands through the same interface.
Since this is still a proof of concepts, the number of features is limited (command line text, string and pictures are the only output formats supported. No widget, no funny javascript) and they are few safeguards against infinite loops and other entertaining bugs.
TODO
This is right now just a proof of concept. We want to see if such a bot can be useful for people and how. What features would be interesting, what can be integrated in the present clients,... Therefore, in the short term, we want to focus on the possibility of easy testing for users and easy contributions for people who want to add their ideas. On the mid- and long term, a lot of ideas can be realized; it will depend on the feedback. These are just some examples. Short term:
proper error catching
fallback for non supported Jupyter formats on riot.im (i.e. a lot)
testing on termux on a tablet or smartphone
solve the problem with nio-matrix and upload in chunks of images.
Dockerized version
Middle term:
use of opsdroid as a framework
Longer term:
local server integrated to locally command the bot service.
make full use of jupyter capabilities with a client suited for it (for instance a Jupyterlab plugin)
I made a little bot that scrapes https://news.blizzard.com/en-us , because they've disabled their RSS feeds for some time now. It regularly scrapes all posts of a configured category and sends messages for new articles to all rooms the bot is a member of. It works like a RSS bot, except the source is a website instead of a RSS feed.
In the readme there are also some public instances, which you can just invite instead of hosting your own bot.
I've added matrix support into a chat bot, you can see the chat bot in action at #midori-dev:hackerspaces.be and it's project page is here https://github.com/midoricorp/jabbot.
it's main highlight is anybody can add new commands to it in chat using its scripting language
any any existing bot command can be used as a function in new scripts you write
The scripting language to add new commands can be found here https://github.com/midoricorp/script
you can do things like !script print "HELLO world";
or make a new command !script sub hello { print "HELLO World"; }
that would result in a new command !hello being made
print also has 2 output stream, one for rich format and one for basic formatting !script print "Hello World!"; print HTML "Hello <b>World</b>";
The goal is to improve cohesion and collaboration for all things design (UI, UX, interaction...)
Over time, it should become a place for people to
ask design-specific questions
share cool stuff and be praised for all the good work you're doing
develop and document a common understanding of the semantics of matrix
make sure the user experience is amazing, even as we all figure out how to federate.
Probably most designers work on single clients right now, but there are important UX questions that can only be answered ecosystem-wide. Maybe we'll end up with a design guide for people to use alongside the spec.
Final Thoughts 💭
Let's test homeservers against sytest, then unfairly pit them against one another! This week we're comparing Conduit and Dendrite - let's see the results!
Name
Conduit
Dendrite
Federation APIs
1% (1/103 tests)
27% (28/103 tests)
State APIs
0% (0/13 tests)
46% (6/13 tests)
Key API
17% (1/6 tests)
33% (2/6 tests)
Query API
0% (0/5 tests)
80% (4/5 tests)
send_join API
0% (0/8 tests)
38% (3/8 tests)
make_join API
0% (0/2 tests)
50% (1/2 tests)
Auth
0% (0/19 tests)
5% (1/19 tests)
room versions
0% (0/7 tests)
29% (2/7 tests)
Federation API
0% (0/14 tests)
36% (5/14 tests)
get_missing_events API
0% (0/6 tests)
33% (2/6 tests)
Backfill API
0% (0/4 tests)
0% (0/4 tests)
Invite API
0% (0/10 tests)
10% (1/10 tests)
send_leave API
0% (0/1 tests)
0% (0/1 tests)
Public Room API
0% (0/1 tests)
100% (1/1 tests)
Device Key APIs
0% (0/7 tests)
0% (0/7 tests)
Non-Spec API
0% (0/50 tests)
0% (0/50 tests)
Client-Server APIs
8% (56/667 tests)
33% (225/672 tests)
Registration
53% (17/32 tests)
62% (20/32 tests)
Login
26% (5/19 tests)
32% (6/19 tests)
V1 CS APIs
10% (3/30 tests)
10% (3/30 tests)
Misc CS APIs
100% (1/1 tests)
100% (1/1 tests)
Profile
33% (2/6 tests)
100% (6/6 tests)
Devices
17% (2/12 tests)
17% (2/12 tests)
Presence
0% (0/10 tests)
0% (0/10 tests)
Create Room
31% (4/13 tests)
92% (12/13 tests)
Sync API
1% (1/85 tests)
40% (34/85 tests)
Room Membership
0% (0/15 tests)
47% (7/15 tests)
Room State APIs
0% (0/14 tests)
36% (5/14 tests)
Public Room APIs
0% (0/7 tests)
14% (1/7 tests)
Room Aliases
0% (0/15 tests)
67% (10/15 tests)
Joining Rooms
0% (0/8 tests)
75% (6/8 tests)
Leaving Rooms
0% (0/1 tests)
100% (1/1 tests)
Inviting users to Rooms
0% (0/14 tests)
7% (1/14 tests)
Banning users
0% (0/5 tests)
20% (1/5 tests)
Sending events
0% (0/3 tests)
100% (3/3 tests)
Getting events for Rooms
0% (0/10 tests)
60% (6/10 tests)
Typing API
0% (0/5 tests)
0% (0/5 tests)
Receipts
0% (0/4 tests)
0% (0/4 tests)
Read markers
0% (0/1 tests)
100% (1/1 tests)
Media APIs
10% (2/21 tests)
24% (5/21 tests)
Capabilities API
0% (0/2 tests)
50% (1/2 tests)
Logout
0% (0/4 tests)
75% (3/4 tests)
Push APIs
21% (12/58 tests)
8% (5/59 tests)
Account APIs
20% (2/10 tests)
40% (4/10 tests)
Ephemeral Events
0% (0/1 tests)
0% (0/1 tests)
Power Levels
0% (0/2 tests)
83% (5/6 tests)
Redaction
0% (0/5 tests)
0% (0/5 tests)
Third-Party ID APIs
16% (3/19 tests)
16% (3/19 tests)
Guest APIs
0% (0/35 tests)
49% (17/35 tests)
Room Auth
0% (0/25 tests)
52% (13/25 tests)
Forget APIs
0% (0/4 tests)
25% (1/4 tests)
Context APIs
0% (0/4 tests)
0% (0/4 tests)
Room Upgrade APIs
0% (0/21 tests)
0% (0/21 tests)
Room Versions
0% (0/40 tests)
75% (30/40 tests)
Device Keys
3% (1/37 tests)
3% (1/37 tests)
Tagging APIs
0% (0/8 tests)
75% (6/8 tests)
Search APIs
0% (0/6 tests)
0% (0/6 tests)
OpenID API
0% (0/3 tests)
0% (0/3 tests)
Send-to-Device APIs
0% (0/12 tests)
0% (0/12 tests)
Server Admin API
0% (0/1 tests)
0% (0/1 tests)
Ignore Users
0% (0/3 tests)
0% (0/3 tests)
User Directory APIs
0% (0/11 tests)
0% (0/11 tests)
Application Services API
4% (1/25 tests)
20% (5/25 tests)
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
This is the most students we've have taken on in a single year, made possible by Matrix now acting as an umbrella organisation for multiple projects - this year that's Ruma, Nheko and OpsDroid. There are also students working on projects from the core team: go-neb, matrix-js-sdk and matrix-ircd.
We received dozens of applications this year, which made narrowing our focus to six students difficult, but we are proud to announce:
Matthew and Amandine discuss the week, including E2EE by default!
Dept of Status of Matrix 🌡
What a week!!
Lots happening this week! Cross-signing landed - this is a massive achievement for the team, and will go a long way to helping the user experience for new users especially. Read more in the major Riot blog post here. Time to start getting less-technical friends on Matrix!
Google announced their Summer of Code programme acceptees: Matrix have six students this year, our most ever! We'll make a new blog post next week welcoming the students!
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, MSC2474 has entered FCP. Keeping with the E2EE theme, we've switched focus to MSC2526. So the new list of MSCs for next week is: MSC2366 (verification flows), MSC2399 (UISI messaging), and MSC2526 (deleting key backups).
Dept of Servers 🏢
Dendrite / gomatrixserverlib
Dendrite is a next-generation homeserver written in Go
Some of the work for /get_missing_events has been done now for filling gaps in the room DAG
Federation sender performance and parallelisation have been dramatically improved, which helps a lot in big rooms
Retries, backoff and blacklisting have also been implemented in the federation sender to handle cases where remote homeservers are unavailable much more gracefully
Retrieving missing state when receiving incoming events over federation is a bit more robust now
Creating direct chats now works
Invites are mostly working now overall, both locally and over federation
RespState and RespStateJoin have been fixed in gomatrixserverlib
Room joins and leaves are now handled by new code across the roomserver and federation server perform APIs, which reduces complexity significantly
Redis live in production for m.org! We did not expect this to translate into a significant improvement in performance directly, but it means that we can add new workers without any extra overhead on the master process which has been very useful in supporting cross signing.
Fixing bugs leading to messages getting stuck at the bottom of the timeline as well as messages not making it to sync at all.
Lots of improvements to deal with the extra load generated by cross signing.
All of these changes will be available in v1.13.0 which should have a release candidate ready rsn.
Next week, we continue to work on sharding changes, further SSO support and ensuring that cross signing adoption is as smooth as possible.
Architect is a homeserver project written in Common Lisp. We intend to create a high performance homeserver using the meta-programming features of Common Lisp to reduce the amount of redundant and timely code that needs to be written and maintained.
architect events
I created a json-schema library, to generate class definitions directly from the Matrix specification. These classes also have information attached to them to allow for serialisation, using a metaclass from json-clos.
This is done entirely dynamically without writing to source files. The invocation of json-schema that creates classes for the client-server, server-server and application-service protocols is only about 20 lines.
I definitely approve of separating out the event library and generating it from the spec - Ruma also has this approach.
This week I refactored most of the data handling code to make it both more efficient and easier to read. I started by splitting a file called "data.rs" into multiple smaller files that handle just one part of the database, like "users.rs", "rooms.rs" or "edus.rs". I continued improving the code by making methods return iterators instead of vectors and propagating errors instead of crashing directly. Lastly, I added a few comments here and there and made sure everything works.
Meanwhile, @Valkum experimented with CI and @MTRNord is working on FluffyChat Flutter support.
Finally, I want to thank my supporters on Liberapay.
After a few weeks of work the matrix-signal bridge is now functional again. In the process I also added the possibility to send audio and video files among other things.
mx-puppet-bridge is a general bridging library that supports (double)bridging and relays. The goal is to make it as easy as possible for others to bridge new third-party protocols to matrix. Support roomDonate
mx-puppet-bridge now supports emote synchronising using revolution's custom emotes! The discord protocol implementation (mx-puppet-discord) already utilizes this
Easybridge is a multi-user bridge for small Matrix servers
Easybridge is a multi-user bridge for small Matrix servers, with the idea of making it easy for non-technical users to bridge their external accounts into Matrix. Once configured next to a server, users can just go to a dedicated web page and add their accounts with a simple form. Currently supported protocols include IRC (buggy), XMPP (basic feature only), Mattermost (quite in good shape) and Facebook Messenger (has issues with disconnections). Available at the following link: https://git.deuxfleurs.fr/lx/easybridge
Hello one and all. Today we're releasing the 1.2.0 of the slack bridge. No notable changes from the last RC this time, but another release should follow this one soon to make changes to the provisioning system :)
gomuks's e2ee support is now on the master branch. The basic olm/megolm things like key distribution work fine, but no advanced stuff like key import/export or device verification yet.
I'll probably add e2be to mautrix-whatsapp next and then add some of the advanced e2ee stuff to gomuks. I'll also make a v0.1.0 release in gomuks after I figure out some bugs in message history loading.
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
Apart from some further speedups, we've been working on reactions. Nheko can now display them and sending them should be done soon too. We also fixed a few bugs, when people reported them and you can now select, who you want to reply to by using a keyboard shortcut (Alt+Arrow keys for now). We will probably release a new version once reactions are done.
We have released RiotX v0.19.0 on the PlayStore on Tuesday! This is a pretty huge release, including all the work on cross-signing, but also other features like changing account password, deactivating account, saving media to Gallery, etc., without forgetting a lot of bug fixes. More detailed change log can be found here: https://github.com/vector-im/riotX-android/releases/tag/v0.19.0.
We are now working to implement the main missing features compare to Riot-Android, with the target to upgrade Riot-Android with RiotX codebase in a few weeks.
This week has mostly been another cross-signing week to improve it and to fix bugs. We released 0.11.2 on Monday. We are going to release 0.11.3 with the work we made this week. It should be available in the App Store tomorrow.
We also released MatrixSDK 0.16.4 with the last version of AFNetworking. That means apps using the MatrixSDK should be able to publish to the App Store again. There is no more usage of UIWebView.
git clone <https://gitlab.com/ponies-im/matrix-js-sdk.git>
cd matrix-js-sdk
yarn install
yarn build
yarn link
cd ..
git clone <https://gitlab.com/ponies-im/matrix-react-sdk.git>
cd matrix-react-sdk
yarn link matrix-js-sdk
yarn install
yarn build
yarn link
cd ..
git clone <https://gitlab.com/ponies-im/riot-web.git>
cd riot-web
yarn link matrix-js-sdk
yarn link matrix-react-sdk
yarn install
yarn build
yarn electron # this also launches the app
Dept of SDKs and Frameworks 🧰
Ruma
Ruma is a Rust project to create a comprehensive set of APIs for Matrix. Previously there was a Ruma homeserver project.
With this release, it is now easier than ever to work with malformed and / or custom events. Some big changes are already being planned for the next release.
We basically just deleted lots of code that is no longer needed with ruma-events 0.21.0. We also got rid of the dependency on the url crate, which really didn't have a very good reasont o be there.
With this release, ruma-client-api is basically up-to-date with r0.6.0 of the matrix specification. Special thanks to @iinuwa for updating a bunch of those endpoints, and for adding support for the user-interactive authentication API!
The Matrix community editions of the Doctor Who watchalongs continue! Next up on our line-up is another two-parter on Sunday (May 10th), we'll be pressing play on The Zygon Invasion at 7PM BST, then on The Zygon Inversion at 8PM BST! Joining us on Twitter will be Peter Harness (writer) & Ingrid Oliver (Petronella Osgood aka The Osgoods™︎), and maybe more 🙂
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
352.5
2
phys.ethz.ch
394
3
maunium.net
458.5
4
envs.net
560
5
fab.network
601.5
6
asra.gr
659
7
2gather.community
675
8
matrix.vgorcum.com
701.5
9
gottliebtfreitag.de
726
10
danielvinci.com
749
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
As of today, Matrix is end-to-end encrypted by default for private conversations.
Three years have passed since we first announced End-to-end Encryption in
Matrix
and started to beta test it in Riot - and after an enormous amount of
polishing and refinement on its user experience, we are finally declaring it
out of beta and enabling it by default for all new private conversations in
Riot. As Riot is currently the most common Matrix client, this means that
Matrix as a whole should now be considered end-to-end encrypted by default for
DMs and invite-only rooms.
Work on E2EE in Matrix has progressed in waves since we first shipped it - including:
adding keysharing (letting you share encryption keys between your devices to improve reliability)
making Riot Web's encryption resilient to running concurrently in multiple tabs
adding online key backup (so you don't lose all your history if you lose all your devices)
making encryption resilient to restoring the app from a backup
adding interactive key verification via emoji to make the verification process easier.
However, our goal was always to enable E2EE by default for all private rooms,
which means having feature parity between unencrypted and E2EE Matrix so that
we can enable encryption without any negative impact on usability. The
high-level remaining items were significant:
Cross-signing: verifying your own logins so others don’t have to.
Adding QR codes for even better verification UX, to make cross-signing as painless as possible.
Replacing the old prototype UI for E2EE with final polished UI/UX.
Ability to support non-E2EE clients.
Ability to search encrypted rooms.
Ability to view file indexes in encrypted rooms.
Fixing the remaining “Unable to decrypt” errors.
Over the last few months the Riot team has been almost entirely focused on
implementing solutions to these items - and we're finally at the point where
the switch can be flipped and as of Riot Web/Desktop 1.6, Riot iOS 0.11.1 and
RiotX Android 0.19, all new private rooms will be encrypted by default;
completing the transition we began at FOSDEM
2020 when we landed
cross-signing E2E-by-default in the development branches of Riot.
Heads up that encrypted traffic is slightly heavier on the server than
unencrypted (due to exchanging keys, verification traffic, and keybackup
traffic), and so there is a risk that the already-over-popular Matrix.org
server instance may feel a little hugged to death. However, unprecedented
Synapse performance breakthroughs are on the horizon in the coming weeks which
will fix this - and, of course, you can (and should!) be using your own
instance anyway.
Thanks everyone for helping us test encryption over the years and getting us
to this point: cross-signing provides a more secure way of tracking device
trust than almost any other comms system out there, and we hope that you'll
agree the improved UX has been worth the wait.
Next stop: Synapse performance, and rebuilding Riot's first time user experience!
Over 3 million people from Telegram and Discord have now been brought into the Matrix universe through t2bot.io. Of those people, around 230 thousand are active each month and 15 thousand are dedicated users of the bridges daily.
While this is a huge milestone for t2bot.io,it underlines the importance of self-hosting: having a couple giant bridges is great for accessibility, though where possible it’s heavily encouraged that people self-host. Hosting the bridges yourself on your own homeserver gives you better control of what passes through your server, reduces your dependence on third parties like t2bot.io, and gives you better performance.
During peak periods, t2bot.io sees about 10 messages per second passing through it. Half of those messages are generated by the Telegram bridge alone. The other half is dealing with federation and the various other bridges and bots on t2bot.io. In terms of media, a new image is uploaded every 2 seconds, leading to 5.8 TB of media being stored. The database is 3 TB and holds 236 Million events - roughly 131 Million of which are sent by t2bot.io.
Thank you to everyone who has used t2bot.io in the past 3 years - it’s been more successful than ever imagined. Here’s to another year and a bunch of self-hosting. :)
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, MSC2454 has entered FCP, and as such we've decided to instead focus on MSC2399. So the new list of MSCs for next week is: MSC2366 (verification flows), MSC2399 (UISI messaging), and MSC2472 (Symmetric SSSS).
Dept of Servers 🏢
Dendrite / gomatrixserverlib
Dendrite is a next-generation homeserver written in Go
We’ve spent time this week working with the Riot teams to tweak matrix.org performance for cross signing. We’ve also fixed a few performance regressions ahead of next week's 1.13.0 release (which will be a big one, more details when it lands).
With any luck we’ll have Redis in production on matrix.org next week, we don’t think this will give us a huge performance win, but there is certainly overhead in having so many workers using the previous replication streaming method.
Our sharding project continues, and Erik has been trying to move the event stream entirely away from the master process which in itself could be significant for overall perf once ready for production.
Aside from that we continue to improve SSO support and we have a really great community PR from sandhose that implements OpenID Connect support. We are really looking forward to getting that merged. The admin API is also getting plenty of community love with awesome-manual and dklimpel leading the charge.
Next week, look out for 1.13.0 and hopefully some more good news on sharding.
Version 0.0.6 has been released on https://p2p.riot.im which has the following changes:
Room version 5 is supported by default.
Backfill is much more reliable.
Backfill now does all PDU checks required of it
You might get kicked out a few times whilst the service worker shifts around, you can force things by going to chrome:serviceworker-internals or about:debugging#/runtime/this-firefox to unregister the worker manually. Logs will state version 0.0.6 on update.
All the benefits from Dendrite (above) will feed into this.
Hey all, the IRC bridge has reached another milestone, 0.17.0. This is a medium sized release, containing a few nice to have features like predicting nickname conflicts and some work around user deactivation. Importantly, this release authenticates the provisioning endpoint so if you run an integration manager or script that makes use of it, ensure that it handles requests appropriately. You can see the changelog in https://github.com/matrix-org/matrix-appservice-irc/releases/tag/0.17.0
mx-puppet-bridge
mx-puppet-bridge is a general bridging library that supports (double)bridging and relays. The goal is to make it as easy as possible for others to bridge new third-party protocols to matrix. Support roomDonate
gomuks now has experimental support for end-to-end encryption on the e2ee branch. It supports both text messages and media downloads. The majority of the work happened in mautrix-go (also on the e2ee branch). This also means that mautrix-whatsapp will get support for end-to-bridge encryption in the near future.
New Dutch and Chinese (simplified) translations (besides English & German)!
Edited messages are now displayed correctly.
An edit action has been added to the event context menu, long press a sent message to go into edit mode (looks cool as well!).
When entering a full MXID into the username field on logging in, Nio will automagically prefill the homeserver URL (if a well-known config is present server-side).
Rich text markdown message display including clickable links detection is now in the works!
Best part about all of these changes: They were contributed by others, I did nothing but merge the PRs! Open-Source ❤️ Shout out to @stefan:stefanhofman.nl, @thomas:mustelo.de, @captain-yukinoshita-hachiaman:matrix.org and @regexident:matrix.org.
RiotX will finally be an update of Riot-Android on the PlayStore and RiotX beta will then be removed from the PlayStore. We will implement everything to let users upgrade their application without being forced to log in again.
While we are finalizing cross-signing, quadS, bootstrap, etc. on RiotX, we have started studying and implementing the main missing features: identity server and related functionality (terms of service consent, invite by email, search in contact list, bind emails and phone numbers, etc.), integration manager (terms of service consent,widgets, send stickers), WebRTC audio and video calls, Jitsi conference integration, and other important missing features like UI and UX to invite people to a room, etc. We are also fighting an annoying bug related to the navigation inside a timeline.
It's also now possible to deactivate your account using RiotX.
It's worth noting that people can contribute to translate RiotX by using new dedicated Weblate projects. Thanks!
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
fernie contributed a smoother scroll behaviour and a loading indicator for individual rooms
We fixed some readability and styling issues
We fixed a major bug in 0.7.1, where you couldn't accept invites
We fixed a bug, where nheko would pin a core to 100% CPU on highdpi screens, because it tried to resize avatars all the time...
We also reduced CPU usage by a lot. Nheko now only uses 0.7% CPU on my system again and that's just the presence updates I get every 100ms or so...
There will probably be a release in the near future to get those fixes to people not running master.
The reduced CPU usage is mostly not resorting the whole room list all the time, but keeping the partially sorted room list around and not storing pending read receipts in the database but just applying them all the time without checking, if we are waiting on a receipt :D
Riot Web
A glossy Matrix collaboration client for the web. https://riot.im
Several more RCs this week have brought us ever closer to the release of cross-signing! A variety of verification, login, and toast issues related to cross-signing have been fixed in the RCs this week. Please do test https://riot.im/staging over the weekend, as we're planning to release early next week if no issues are found.
Nomadic Labs have built an open-source embeddable chatbox using Matrix for the OCRCC (Ontario Coalition of Rape Crisis Centres) to allow survivors of sexual violence to communicate and seek help safely with OCRCC facilitators. This chatbox lives at https://github.com/nomadic-labs/ocrcc-chatbox - and it has a pretty nice feature set, including end-to-end encryption support.
All data objects such as MyUser, Room, etc. are now immutable
Add MoorStore, which uses moor
(thanks to MatMaul for the idea and initial implementation!)
The SqfliteStore (was in a separate package) is now deprecated
LocalUser has been renamed to MyUser
And a lot of other changes!
How it works
The user has a stream of Updates, user.updates. An Update contains the latest 'snapshot' of data associated with the user. It also contains a deltaMyUser, where all properties are null, except those that are changed. For example, if a user started typing in a certain room, and we're syncing, there will be an Update in user.updates, where delta has 1 Room in delta.rooms, with only the room where the user started typing, reflected in room.typingUserIds. All other properties of the Room will be null. This is all assuming that this is the only change in the sync. If more happened, it will be reflected in delta.
To better serve the wizarding community's transformation needs, I have released v0.2.2 of Polyjuice Client, a Matrix library for Elixir. This release adds support for some more Matrix endpoints, and allows paginating through room history using Elixir's streams.
v1.1.1 of dacruz21/matrix-chart is out and now supports the matrix.org IRC bridge! dacruz21/matrix-chart is a secure, scalable way to deploy a complete Matrix homeserver stack, complete with bridges and useful services, into Kubernetes. As always, come visit #matrix-chart:typokign.com if you have any questions or need support!
Opsdroid has released v0.18 this week, which contains a load of stuff. The main matrix related changes are:
A generic event type for all unsupported matrix events, so you can now react to and send any custom events.
Implementation of the join room event in the matrix connector so you can react to users joining a matrix room.
A fix for mxc urls in messages, so inline images etc work.
A fix for the opsdroid memory to allow per-room matrix room state databases. This will hopefully be merged into core for the next release.
Picard Opsdroid Skill
Related to this release the picard skill for bridged slack/matrix community management has been updated, and now (for the first time) works with a release version of opsdroid rather than some random branch 🤣. This involved adding support for lots of different events to the slack connector in opsdroid.
See Matrix Live this week for a neat introduction to OpsDroid
I wrote a bot to share Jitsi call URLs. The main objective is to allow people on the other side of bridges to get the URL for a jitsi call. When a jitsi widget is added to a room (v2 widget from riot-web) it will post a message with the plain jitsi URL. It also provides a !jitsi command which allows people to create a jitsi call with a custom URL, and if the bot has permission it will be added as a widget in the matrix room. It has a bunch of other config options you can tweak it with. The main thing you might find it useful for if you are not in a bridged room is you can use it to quickly add a jitsi widget for any conference URL. The bot can be found here: https://github.com/Cadair/skill-jitsi/ and it uses the opsdroid framework. I have also hosted a version @jitsibot:cadair.com
We're still having a great time watching Doctor Who with folks from the wider Matrix community. The next one scheduled is happening on Wednesday (May 6th) at 7PM, and we'll gather to watch The Girl in the Fireplace (series 2 episode 4) together, with tweets from Steven Moffat (writer) and Sophia Myles (Madame de Pompadour) bridged to the room 🙂
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
333
2
lo.hn
567.5
3
maescool.be
655.5
4
sibnsk.net
790.5
5
nct08.de
817.5
6
matrix.un-hack-bar.de
952
7
mtx.liftm.de
1073.5
8
federator.dev
1268
9
matrix.vgorcum.com
1510
10
shortestpath.dev
1571.5
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
On April 14th, the Spec Core Team conducted a long-overdue retrospective
about the things that were working in the
Matrix Spec Proposal process,
and those that were not.
The most glaring item on the list was the sluggish pace that many Matrix
Spec Changes (MSCs) take throughout the proposal process, as well as the
general lack of activity from the Spec Core Team members on proposals that
have not yet started a Final Comment Period.
We deeply apologize for the frustration this has likely caused many MSC
authors, and want to shed some light on the reasoning behind it, and what we
plan to do to prevent leaving authors in the dark about why there may be no
Spec Core Team activity on their proposal.
Proposal Triaging
There are currently 136 open MSCs that have yet to undergo Final Comment
Period (FCP), 75 of which are marked as proposal-in-review, and 20 that have
a FCP proposed. Relative to the 65 MSCs that have ever been closed, this is a
lot of outstanding ideas, features and maintenance changes.
The Spec Core Team itself is made up of 8 members, each of which have
separate full-time jobs. All team members are well-placed to be on the team
given their wide breadth of knowledge across the Matrix ecosystem,
however the majority are some of the most busy pushing forward Matrix's
reference implementations - without which, Matrix will unquestionably fail.
This limits the amount of MSCs that the team can effectively work on at a
given time.
But there is also a large backlog of MSCs that provide even more fundamental
fixes and additions to the protocol that the team needs to prioritise. These
include things like
cross-signing devices,
the communities rewrite and
finally merging
reactions and edits into the spec.
While we announce what MSCs we're focusing on during a given week during
TWIM, it's not as clear which items we're looking
to pull from the backlog next. To help tackle this, and to help keep us
honest, we've begun putting each MSC into either "feature", "maintenance", or
"core" buckets. This materialises in the form of github tags, which can be
used to filter the list of MSCs like so:
feature,
maintenance,
core.
For a given timespan, we’ll pick a track and pull MSCs out of that category
when possible. More information about MSC categories are now detailed on
the proposals page.
As for the next 6 to 12 months, we plan to work on items from the “core”
category. We need to get Matrix to a point where it can compete with other,
proprietary chat protocols and items in "core" are decidedly the proposals
that will take us the furthest in that direction. This doesn't mean we won't
occasionally look at an MSC in a different category, but it will heavily
influence our prioritisation.
Future
We'll try this approach out over the next few months and see how it goes. The
next Spec Core Team retro will occur in the middle of May, where we will
review the process once again.
For now, if you have any feedback please come and chat with us in
#matrix-spec:matrix.org :)
Some snapshots of what the team has been working on. Look out for a clear explanation from Erik about Synapse performance (and what will be done about it!), and lots of other goodies
Rescue18 (a French non-governmental news website for emergency services) echoed this announcement earlier this month, praising the security aspect of the platform and the possibility it offers to improve social and professional exchanges throughout the hierarchy as well as the rest of the government and public services.
Article is all in some other language - thanks Brendan for providing this summary.
We've switched up our focus to the following MSCs: MSC2366 (verification flows), MSC2454 (SSO UI Auth), and MSC2472 (Symmetric SSSS). Expect a blog post next week describing the new MSC categories.
Shipped 1.12.4 a patch release to fix some cross signing related bugs.
Redis support to replace our existing cross replication system, merged to develop. This is a precursor to the sharding project. We have a PR to support cache invalidation across workers which, once merged should make it relatively easy to pull off event persistence from the master process. Just removing event persistence could give some decent perf wins, but the prize is then splitting persistence to run across across multiple workers.
A final PR to support SSO for user interactive auth will merge imminently, thereby freeing up full cross signing support for worker installs.
Aside from that we’ve been working on fixing a weird bug where rooms can end up with zero forward extremities and generally showing Sygnal some love.
Upcoming
Put Redis into production
Ship 1.13.0 which will contain Redis support as well as a host of SSO bug fixes.
Merge our new caching config logic to give finer granularity on cache settings.
Merge cache invalidation and try to get events persistence running in its own worker.
Ben added:
Cross signing, oh cross signing! Can you believe it‽ Cross signing!!!
Matrix Corporal
matrix-corporal manages your Matrix server according to a configuration policy
matrix-corporal v1.9.0 has been released. It adds support for preventing certain users from creating rooms (that is, from using the /createRoom API). I've been thinking about developing this feature for a while now, as people have been requesting it frequently.
matrix-media-repo
matrix-media-repo is a highly customizable multi-domain media repository for Matrix
This week I worked a lot on getting the first bit of federation working. My goal was to query the public room list of another server and forward it to a client.
This involved setting up a keypair to sign the json I send to the server and putting authorization headers into my requests. Most of the work is already done and https://federationtester.matrix.org/ reports it's all good.
Sadly there seems to be a problem with the signing, because other homeservers reject requests: Unable to verify signature: <class 'nacl.exceptions.BadSignatureError'> Signature was forged or corrupt. I'll continue to work on this in the next week(s).
Dendrite now supports perspective key fetching as a configurable option, and will automatically attempt to use the perspective key servers for keys that couldn't be fetched directly
Dendrite now uses a newer version of the Sarama library
Some caching has been added to the roomserver API for room versions, which should help quite a bit with performance over federation and handling transactions
Auth checks for /send_join are now quite a bit more robust
A bug has been fixed where the default state filter limited the amount of room state that was visible after a join
gomatrixserverlib has quite a bit of new support for backfilling now, which will be wired into Dendrite soon
gomatrixserverlib has new primitives for v2 invite responses and /get_missing_events requests
Invite support is being worked on currently, which should also enable support for creating DMs in Riot
Matrix native integration for the Sailfish OS, KDE and other linux systems called telepathy-tank got attertion from the community this week and @aa13q updated it a bit thanks to @Kaffeine. Writing the post for the TWIM has grown into the small blog post, so @aa13q shared it sepatetely: https://hackmd.io/@aa13q/telepathy-tank
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
Nheko released two new version, 0.7.0 and 0.7.1. The second one mostly fixes some minor issues in the 0.7.0 release, which we got from all the people trying it out. Thanks for reporting them!
We hope you will try it out and have a good experience! If you don't, you can complain to us in #nheko-reborn:matrix.org or open an issue in our bugtracker.
gomuks got a fancy initial sync loading bar so it no longer looks like it's broken after you log in. Implementing end-to-end encryption in mautrix-go has also been slowly progressing, might have something working in a few weeks.
Riot Web
A glossy Matrix collaboration client for the web. https://riot.im
This week we released a fourth RC for Riot Web 1.6, the upcoming release with cross-signing, addressing a few issues found through everyone's testing and feedback. Please do continue to test https://riot.im/develop, the latest RiotX build, and also E2EE search in Riot Desktop Nightly.
I created an client-sdk to interact with matrix in Spring Boot. It is written in kotlin and should also work with Java. You can find the repo here: https://github.com/benkuly/matrix-spring-boot-sdk
It contains also a bot-sdk to write bots by adding a dependency and a few lines of code only.
It is tested with unit-tests, but integration-tests against a real matrix-server are currently missing. A simple ping bot works and is also integrated in the repo as example.
Currently I'm working on getting this to Maven Central.
Dept of Ops 🛠
matrix-docker-ansible-deploy
This Ansible playbook is meant to easily let you run your own Matrix homeserver.
As per the previous edition of TWIM, we had a blast on Sunday watching and reacting to Doctor Who episodes The Stolen Earth and Journey's End.
The next watchalong will be this Friday (Apr 24th), and we'll be watching another two-parter together, Human Nature & The Family of Blood, starting from 7PM BST! Guests such as Paul Cornell (writer), Charles Palmer (director) & Lor Wilson (Lucy Cartwright aka Daughter of Mine) will also be discussing the episode along for even more fun and behind the scenes!
This means that if you're reading this when this edition of TWIM goes out, and you fancy watching some Doctor Who this evening, join the fun at #doctor-who-watchalong:abolivier.bzh 😀
And if not, feel free to join the room anyway to find out when the next watchalong is happening 🙂
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
321
2
envs.net
363
3
maunium.net
420
4
nerdsin.space
421
5
maescool.be
470
6
lyseo.edu.ouka.fi
773
7
mjdsystems.ca
820
8
fab.network
832.5
9
eisfunke.com
1048
10
matrix.nilux.be
1275
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
.png)
