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).
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 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 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
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.
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!
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.
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.
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.
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 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.
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 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.
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.
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 🙂
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.
We had our first Spec Core Team retro in a very long time this week, with a new regular schedule of every month. It ran about an hour overtime - there was a lot to talk about. We'll post the conclusion in a separate blog post soon.
This week I spent some time improving Riot support. Now there should be a lot less warnings and some new features: typing events, read receipts, better room directory, invites, user search.
The only bigger bug that exists currently is that the message history is not automatically loaded when you join a room. Sometimes reloading the page helps, but not always. The reason for that is that Riot calls the deprecated /initialSync endpoint, which I do not support (I hope someone works on Riot to fix that).
In the next few weeks I plan to improve the single-homeserver experience further and add permission management, while also working on federation.
I also want to thank my supporters on Liberapay for their kindness 😊.
I tested the performance of Conduit yesterday by running a ruma client that sends a /send request in a for loop 10k times, which took ~46.8 seconds (all locally on my pc). This means the server can handle ~210 /sends per second under these circumstances.
The flamegraph shows what the cpu is spending most of its time doing. Plateaus are things that take time. You can see most of the time is used for a function in sled::io (I spoke with one of the devs and they said this is expected, but will be improved in the next release)
We continue to focus on performance and spent a good chunk of time improving worker replication test coverage to build confidence that our upcoming changes will work as expected. Erik has been working on how to how to factor out cache invalidation which is now starting to take good shape. Once we have that, factoring out things like event persistence are next on the horizon.
Aside from that we’ve been working with the Riot client teams as they near release for cross signing, fixing bugs and improving performance on key actions.
SSO support continues to improve, and more fixes for user inactive auth for worker'd installs will land next week. Poor old Rich has been banging his head against a sync bug blocking develop, but hopefully he has broken its back now, and we'll get that merged asap.
Finally we experienced some operational issues with push over the weekend, so we spent some time cleaning up and figuring out how to make things more resilient.
The Construct server made significant progress this week with end-to-end encryption, client compatibility, application services support, and build-related enhancements. I'd like to thank Yan Minari for contributing spec-compliant code paths for application services in the user registration system. Special thanks this week to Tony O. for continued work on the NixOS (#nix:matrix.org) derivation for reproducible builds, in addition to contributing fixes to Nio for optimal compatibility with Construct. I'd also like to thank Wessel for contributing a much needed reorganization of the Dockerfiles in preparation for Construct operating on many more platforms. Many thanks to Nico for working with the team this week in #test:zemos.net on various compatibility fixes to mtxclient and Nheko; the responsiveness when using Nheko with Construct is mind-blowing. I'd also like to thank David Vo (a.k.a. auscompgeek) for also contributing to Nio toward Construct compatibility.
Finally, I owe much appreciation to tulir, jochen, qy and others for setting up brand new installations this week and providing feedback in #test:zemos.net. Construct is the first and only federating alternative to Synapse. It is written in C++ for maximum performance, the lowest possible TCO, and designed for horizontal scaling with Construct Cluster. If you are interested in starting a low-cost Matrix hosting service, Construct may be your ideal choice. To stay informed and show your support please visit us in #test:zemos.net today!
Which includes a bunch of small fixes, including a performance improvement to StateLookup hits. Apparently it's bad to hit the homeserver with 1000s of concurrent /state requests on startup. Most importantly it also includes a critical fix to the addAppServicePath function, which previously did not authenticate requests, see the CHANGELOG for more information on that.
We're still working on the RCs for this release, having discovered and fixed a bunch of failures that can happen around getting connected to IRC. Be aware that the above security fix is applied in this release, which means provisioning requests will now be authenticated.
This is another big load of bug fixes, with many thanks to our new bridge crew member, Christian!. This release includes the above security fixes, as well as some metrics improvements to track activity on the bridge.
A clickable command-line client Matrix written in Rust. Although, still in the early stages, enough has been implemented to show a working demo. rumatui uses tui to power the UI and matrix-rust-sdk for all communication with the server. So far the message formatting has been the most visually satisfying feature, although implementing it was not much fun. The goal of the project is to have a UI driven command-line client, useable from either keyboard and/or mouse.
Big thanks to @poljar for allowing me to work on matrix-rust-sdk, @jplatte for the opportunity to work with the ruma crates and everyone in the Matrix community for being so helpful!
Check it out https://github.com/DevinR528/RumaTui! Help is welcome, although as matrix-rust-sdk develops the design and structure of rumatui will evolve quickly.
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
0.7.0 will contain a lot of work, including replies, e2ee attachments and a completely rewritten timeline (the full changelog is too big for TWIM, but you can find it in the github releases). It also fixes a lot of issues. We should probably released it a lot earlier, but we always had one more feature we wanted to finish... For the future we plan to do smaller, more regular releases!
If you are a packager, it would be awesome if you can check, that you don't have any build issues. If you need support, just message us in #nheko-reborn:matrix.org !
Cross-signing and E2EE by default for private rooms is nearly here! 🎉 It would be great to have more people testing this, as we're very close to release, and extra testing will help reveal those last issues. Please help test cross-signing on https://riot.im/develop (suggesting develop since there's already some fixes there beyond the RC on staging) and the latest RiotX build. It would also be great to test E2EE search in Riot Desktop Nightly.
We are finalizing cross-signing, QuadS and bootstrap. We will release a new version next week. We are still working on migration of the database from Realm to sqldelight solution.
Let me copy Riot-Web and RiotX-Android: Cross-signing and E2EE by default for private rooms is nearly here! 🎉.
A TestFlight will be available over the weekend. Here is the link if you want to join the program. This release candidate still needs some polish but a new release will be definitely available on the AppStore next week.
In parallel of that, the maintenance work is going well. We are erasing our technical debt as much as possible. The new Apple Push API raises some privacy concerns. We may no longer be able to offer CallKit as it requires events to go in clear between servers.
Many of you will probably have heard already, but Ruma is now officially dead. The homeserver, that is. Outside of that, the API definitions in ruma-client-api have seen some work and our first two endpoints in ruma-federation-api have been written! ruma-api and ruma-identifiers are also being worked on, with the following new releases being published in the past week:
ruma-identifiers 0.15.0 was released with loads of changes; this might be the last 0.x release!
identifiers are now stored as strings (with minimal additional data)
before, we would parse the server name into a url::Host
this means that parsing now doesn't allocate at all under some circumstances, and obtaining the string representation of one of our identifier types is essentially a no-op
there no longer is a single non-optional dependency, everything that requires them is now behind a feature flag
some new helper functions have been made available, mostly around user IDs
We've been doing Matrix editions of Emily Cook's Doctor Who watchalongs since confinement started around Europe. The concept is pretty simple: on a given day, at a given time, everyone presses play on the same episode. Folks are then free to then watch it on their own, or discuss the episode as they watch it in the Matrix room and/or in the Jitsi call. We're also bridging tweets sent from directors, writers, comedians, etc. watching the episode at the same time to Matrix.
The next watchalong is planned for next Sunday (Apr 19th) at 7PM BST; and we'll be watching the epic two-episode long season finale "The Stolen Earth" & "Journey's End", with Russell T Davies (writer), Graeme Harper (director), David Tennant (The Doctor) and Catherine Tate (Donna Noble) tweeting along (and possibly more to come) 😀
To relay the tweets from guests during Doctor Who watchalongs, I've written a simple bot that reads the timeline of a Twitter list, optionally filters it by a hashtag, and posts the tweet to a Matrix 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.
While discussing the use of QML in Nheko, aa13q became extremely energised, so I'm including this piece:
Qt/QML fanboy here, feel free to skip, just a love letter to the framework :D
Qt/QML is super-awesome, it's hard to describe how pretty declarative syntax is and how beautiful MVC approach with native Qt C++ side integration %) It is very hard to contribute to HTML/CSS/JS projects when you have seen QML once.
Talking about resources, there are even projects for very low-level embedded boards with arm cortex m7 core [1,2]
I'm actually thinking Qt is the bright future of very wide development areas. I'm both frightened and intrigued looking at relatively low popularity of the project. Since I want it to live and prosper even more but afraid of the possible mistakes for even harder tasks. The better popularity of the project will be harder to coordinate and the future tasks will be even harder. Similar to other cool projects (like matrix! :) I guess it's very challenging to balance between running as hard as you can and not to "die" from exhaustion %)
I don't even know is there something similar comparing to the Qt project, that's also why I'm worried about the future of the project %)
So-called software crisis (the late 60s – mid-80s [3,4]) was successfully overcome by introducing Object-Oriented Programming (it's always funny to see some people who are more into functional programming hates OOP in that context [5]) And notably Alan Kay is not only OOP pioneer (Smalltalk language) but also a first GUI applications developer. While the current OOP languages like Java and C++ are quite imperative, OOP is not only about the objects but also about the messages between them (Smalltalk is probably a nice example here too).
Qt in that context restores interesting balance to quite imperative C++ introducing the so-called meta-object system (for the messaging between objects). After that in ~Qt5, the declarative QML approach was introduced to develop these ideas even more. Not only GUI subject matter could be expressed with QML (like Qt Quick), but the others too (for example, QBS build system).
Sorry for typos and poor style, not a native speaker :) And I could be wrong in my views.
This week we held the first in a series of virtual meetup events, Open Tech Will Save Us.
We were really excited to make this event feel like a real meetup - with a live chat, and interactivity from the chance to ask questions of the speakers. There was a great response, with participants in a 100+ user room chatting about the talks and generally adding to the atmosphere.
Lineup included:
Saúl Ibarra Corretgé from Jitsi on the rapid growth they've experienced since the start of the 2020 crisis
This week the Spec Core Team will be focusing on MSC2457 (password invalidation), MSC2454 (SSO UI Auth), and MSC2472 (Symmetric SSSS), which each have proposed FCPs in flight.
Before next TWIM we'll be carrying out a long-overdue retro to go over how we've been doing in the last few months. We'll then continue to do those regularly once a month and post conclusions from those meetings here.
This week was really successful for the homeserver project. Not only does event sending and syncing work properly, but creating/joining rooms, state events and the public room directory works as well. But the biggest archievement I made this week is Riot support.
Big thanks to MTRNord for fixing bugs in Riot web and deploying an instance of Riot with all patches applied and to jplatte and @iinuwa for improving the ruma libraries.
Today we did the first actual test of the new homeserver. We had ~5 people sending and syncing messages in a room and all of them were able to send messages almost instantly. We'll see how well that scales when we implement federation in the future.
The main focus continues to be performance and we are starting to make good progress in figuring out how to split out and shard the event streams. This is a project where most of the bang will come all at once, rather than there being multiple small incremental improvements.
Aside from that we continue to improve the SSO experience, landing UIA support for CAS providers. We also made a small change to the default behaviour so that only room admins can enable e2ee (applies to new rooms only).
Next week, is more of the same. Expect a few short term performance improvements (specifically to help with cross signing UX) and more SSO support.
As of this PR Gitea has the ability to directly send webhooks to Matrix. Currently it's only in the master branch, but should be in Gitea 1.12.0 which is due by May.
🔗script for forwarding unread Wilma messages to Matrix
I wrote a script for forwarding unread Wilma messages to Matrix. Wilma is a website and mobile app for teacher-parent communication. Download the script from https://k2c42.dy.fi/git/wilmatrix.git and give feedback at #wilmatrix:ellipsis.fi
mijutu seems to lament:
Recently Wilma usage increased from occasional messages to everyday messages, so I had to do something.
Wilma has been widely used and well-known in Finland for over a decade, but not sure how well-known it is elsewhere?
There was just an article (not in English) about the origins of Wilma, that was interesting
So someone got an Amiga in the 80s and decided to make a scheduling program for their local school, and add a bit of time and now there is a web interface, login for students, teachers, and parents with messaging, homework, grades and everything
As promised last week, mautrix-facebook and mautrix-hangouts now support end-to-bridge encryption. It works the same way in all bridges, so the instructions from the mautrix-telegram wiki work for all of them.
Hello everyone. The IRC bridge has hit 0.17.0-rc1. This release is lighter than past releases, but fixes a few nasty bugs. Please test and report back :)
Highlights include:
Disconnect a PM room from IRC when another user is invited, and disallow invites to PM rooms.
On name change, inform Matrix users, if their preferred IRC name is taken.
Add ability to deactivate users permanently via the DebugAPI.
Two bugfixes on the !storepass feature, both bugs would cause the user to be unable to use the 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
Soo.....mx-puppet-bridge also supports plumbed rooms now. That means that this one little library supports all types of bridges mentioned in https://matrix.org/bridges/ Yay!
Somehow it seems we never previously featured untidylamp's ofono SMS/MMS bridge. This is a Python3 project to bridge Matrix and SMS/MMS messages via ofono.
They say:
I'm running this with ubuntu touch on my nexus 5. The goal is to have this hosted on my PinePhone.
We continued to improve the implementation of cross-signing. One of added features is the gossip of the private key of the key backup: when you complete the security on a new sign-in, this new device automatically retrieves all message keys from your key backup. All your e2ee history is available with no additional effort.
Endpoints are continually being updated, and instead of just repeating this vague statement again and again, here is a number: at least 60% of our endpoint definitions are up-to-date with r0.6.0.
We're also getting lots of feedback from conduit's development. Some of things we're now planning to change based on that will require large-scale refactorings that haven't yet started, but will hopefully happen in the coming months.
The matrix-rust-sdk is steadily progressing, improvements have been made on many fronts thanks to devinr528 (better event emitting, easier tests, room name calculation...).
The encryption side of things has been going on as well and a sneak peek can be found here https://streamable.com/xjb83d#
matrix-docker-ansible-deploy's Jitsi setup has seen lots of improvements around authentication, thanks to teutat3s. Refer to our Jitsi docs page for getting started or to learn how to rebuild your existing Jitsi installation in a more secure manner.
If you want your Sentry issues to a Matrix room, there is now a new bot for that: https://github.com/matrix-org/matrix-sentry-webhooks . Currently it supports a simple "projects to rooms" mapping and should work with both legacy webhook integrations and integration platform webhooks.
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.
Over the last few weeks there's been huge increase in interest from folks
wanting the security and autonomy of running their remote collaboration
services, rather than being at the mercy of traditional proprietary
centralised apps. Meanwhile, the Matrix.org homeserver has been very
overloaded (although we're at last making excellent progress in radically
improving Synapse's performance) - so it's particularly important right now to
help folks run their own servers.
Therefore we're very happy to announce that it's easier than ever before now to
self-host your own video conferencing alongside Riot & Synapse: as of Riot/Web
1.5.15 (released last week), it's now a single config option to point Riot at
a specific Jitsi rather than needing to hook up to an integration manager!
Meanwhile, over the last 18 months, it's got easier and easier to run your
own Matrix deployments: the Debian packages are unrecognisably better now, and
with .well-known URL support it's trivial to set up federation without
needing to worry about complicated DNS, TLS or load balancer configurations.
So, to try to show off just how smooth this has become, we thought we'd do a
run-through video showing installing Synapse, Riot & Jitsi on a completely
fresh Debian install. It's (almost) filmed in a single shot, and takes about
20 minutes from beginning to end.
Please note that this does assume you're pretty familiar with Linux system
administration. If you're not, then we'd recommend using a Matrix hosting
provider such as Modular.im (which directly supports development of the core team),
Ungleich.ch, or StartupStack.
Finally, while the video shows how to install on Debian via Debian packages,
there are many many other environments and architectures (e.g. installing
under Docker) - this is just one relatively easy way to skin the cat. Perhaps
there will be other 'speed-run' videos in future :)
If you want to follow along at home without listening to the video (and I can't blame you if you do ;) the high level steps are as follows:
Point the DNS for your domain to it. You should use separate subdomains for the various services as a hygiene measure to make cross-site scripting attacks less effective. In this example, we set up DNS for:
dangerousdemos.net (general website, and for hosting a .well-known path to advertise the Matrix service)
matrix.dangerousdemos.net (Synapse)
riot.dangerousdemos.net (Riot/Web)
jitsi.dangerousdemos.net (Jitsi video conferencing)
In practice, we used a *.dangerousdemos.net wildcard DNS record for the three subdomains in this instance.
Install nginx as a webserver: apt-get update && apt -y install nginx
Go to /etc/nginx/sites-enabled and copy the vhost configuration block from the bottom of default to new files called dangerousdemos.net, matrix.dangerousdemos.net, and riot.dangerousdemos.net. We don't set up jitsi.dangerousdemos.net at this point as the jitsi installer handles it for us.
Rename the server_name field in the new files to match the hostname of each host, and point root to an appropriate location per domain (e.g. /var/www/dangerousdemos.net for the main domain, or /var/www/riot.dangerousdemos.net/riot for riot)
For the Synapse domain (matrix.dangerousdemos.net here), you should replace the contents of the location block with proxy_pass http://localhost:8008; - telling nginx to pass the traffic through to synapse, which listens by default for plaintext HTTP traffic on port 8008. (N.B. do not put a trailing slash on the URL here, otherwise nginx will mangle the forwarded URLs.)
Enable TLS via LetsEncrypt on nginx, by: apt install -y python3-certbot-nginx && certbot --nginx -d dangerousdemos.net -d riot.dangerousdemos.net -d matrix.dangerousdemos.net (or whatever your domains are).
You should be able to go to https://dangerousdemos.net at this point and see a page with valid HTTPS.
Then, install Synapse via Debian packages using the instructions at https://github.com/matrix-org/synapse/blob/master/INSTALL.md#debianubuntu (see below). If you're not on Debian, keep an eye out for all the other OSes we support too!
You should specify the server name to be the domain you want in your matrix IDs - i.e. dangerousdemos.net in this example.
Please report anonymous aggregate stats to us so we can gauge uptake and help justify funding for Matrix!
You should now be able to go to https://matrix.dangerousdemos.net and see a valid "It works! Synapse is running" page.
Then, you should enable registration on your synapse by switching enable_registration: true in /etc/matrix-synapse/homeserver.yaml and restarting synapse via systemctl restart matrix-synapse.
Now you need to tell the rest of Matrix how to find your server. The easiest way to do this is to publish a file at https://dangerousdemos.net/.well-known/matrix/server which tells everyone the hostname and port where they can find the synapse for dangerousdemos.net - in this instance, it's matrix.dangerousdemos.net:443:
mkdir -p /var/www/dangerousdemos.net/.well-known/matrix
cd /var/www/dangerousdemos.net/.well-known/matrix
echo '{ "m.server": "matrix.dangerousdemos.net:443" }' > server
Alternatively, you could advertise the server via DNS, if you don't have write access to /.well-known on your main domain. However, to prove you are allowed to host the Matrix traffic for dangerousdemos.net, you would have to configure nginx to use the dangerousdemos.net TLS certificate for the matrix.dangerousdemos.net vhost (i.e. the "wrong" one), and in general we think that /.well-known is much easier to reason about. In this case you would advertise the server with an SRV record like this:
_matrix._tcp.dangerousdemos.net. 300 IN SRV 10 5 443 matrix.dangerousdemos.net.
Then, install Riot/Web. Grab the latest .tgz release from https://github.com/vector-im/riot-web/releases. You should check its GnuPG signature too:
mkdir /var/www/riot.dangerousdemos.net
cd /var/www/riot.dangerousdemos.net
wget https://github.com/vector-im/riot-web/releases/download/v1.5.15/riot-v1.5.15.tar.gz
# check its GnuPG signature (particularly advisable, given Riot is what stores
# your end-to-end encryption keys)
apt install -y gnupg
wget https://github.com/vector-im/riot-web/releases/download/v1.5.15/riot-v1.5.15.tar.gz.asc
# grab the signing key for the riot releases repository, ideally from a keyserver...
gpg --keyserver keyserver.ubuntu.com --search-keys [email protected]# ...and/or you can grab or cross-check the signing key from packages.riot.im
wget https://packages.riot.im/riot-release-key.asc
gpg --import riot-release-key.asc
gpg --verify riot-v1.5.15.tar.gz.asc
# hopefully this will report "Good signature", even though it won't know to trust the riot release key.
# you could also choose to explicitly trust the key by editing it, entering 'trust' and then '5' for ultimate trust.
gpg --edit-key 74692659bda3d940
tar -xzvf riot-v1.5.15.tar.gz
ln -s riot-v1.5.15 riot
chown www-data:www-data -R riot
cd riot
cp config.sample.json config.json
You then tweak the config.json to change the base_url of the homeserver to be https://matrix.dangerousdemos.net (i.e. where to find the Client Server API for your server), and change the server_name to be dangerousdemos.net (i.e. the name of your server).
You should then be able to go to https://riot.dangerousdemos.net, register for an account, sign in, and talk to the rest of Matrix!
We give the installer the hostname jitsi.dangerousdemos.net. Make sure this DNS is already set up, otherwise the installer will fail!
The installer magically detects you have nginx installed and adds in an appropriate vhost!
We select a self-signed certificate for now, and then upgrade it to LetsEncrypt after the fact with /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh.
Alternatively, you could have specified manual certificates, and then used certbot alongside the rest of nginx to create a certificate for jitsi.dangerousdemos.net - both work.
You should now be able to go to https://jitsi.dangerousdemos.net and use the Jitsi directly.
Finally, and this is the cool new bit: you can now point Riot to use the new Jitsi by going to its config.json at /var/www/riot.dangerousdemos.net/riot/config.json and changing the preferredDomain of the jitsi block from https://jitsi.riot.im to your own self-hosted https://jitsi.dangerousdemos.net.
You then refresh your Riot/Web, and you should be all set to use Jitsi from within your new Riot - as Riot/Web 1.5.15 and later has the ability to natively embed Jitsi straight into the app without needing to use an integration manager.
Matrix nowadays provides an excellent alternative to the centralised solutions. It gives:
Full autonomy over how to host and store your own conversations
Full freedom to talk to anyone else on the wider global Matrix network (or indeed anyone else bridged into Matrix)
Full privacy via full end-to-end-encryption for chats, file transfer and 1:1 voice/video calls (when enabled)
Full transparency by being 100% open source (as well as benefiting from the overall open source community)
Hopefully this gives some confidence that it's pretty easy to run your own fully functional Matrix instance these days.
If not, then hopefully someone will do a similar one to show off Docker!
And if that's still too scary, please take a look at a hosting services like Modular.im.
Open Tech Will Save Us is a virtual meetup, taking the form of a monthly live video stream broadcasting on the second Wednesday of every month at 5pm UTC.
The first event will have speakers from Jitsi, IPFS and Matrix.
We'll cover the importance of preserving privacy and ways to keep your communications under control. Read more at https://matrix.org/open-tech-meetup/
Google closed the door to applications on Tuesday, and we have an absolute bounty of proposals. More information will be shared when the announcements are made in a few weeks.
Next week the Spec Core Team is focusing on the same as last week: MSC2457 (password invalidation), MSC2454 (SSO UI Auth), and MSC2472 (Symmetric SSSS).
Dendrite now has support for sending v2 invites, and partial support for receiving them
The typing server in Dendrite has now been renamed to a more general-purpose EDU server and support for sending/receiving typing notifications has been fixed
Room version v3 and v4 support in Dendrite is mostly finished, hopefully will be merged soon
A new version of the P2P demo was released yesterday with some fixes (more information and discussion in #p2p:matrix.org)
gomatrixserverlib now has new types and support for the new invite format, as used in the v2 endpoint
gomatrixserverlib has received some bugfixes, including with event ID generation and avoiding null in marshalled JSON for auth_events and prev_events
End-to-end encryption support has landed in Construct. The server now supports cross-signing, secret storage, and key backups for clients. I'm pleased with how this all came together on schedule for the upcoming transition to e2ee by default for Matrix. If you haven't been paying attention in #construct:zemos.net last week full support for push-rules including efficient highlight-counting also landed. Next week Application Service support is scheduled.
Construct is quickly nearing complete coverage over the full breadth of the Matrix protocol, and the transition into release packaging is fast approaching. Construct is the C++ homeserver built for maximum performance with the lowest possible cost of ownership. If you're in need of a faster homeserver please show your support in #construct:zemos.net and tell all your friends to lend a hand today!
Hello! This week I worked on a Matrix homeserver written in Rust. Registering and logging in works already and I am currently adding support for sending events and inserting them into the event graph. I spent most of my time reading the Matrix specification to understand how this process works, because with federation (which I plan to add to my homeserver in the future) servers might disagree on which event was created first and there are strictly defined rules to resolve this. The Matrix homeserver uses the Ruma libraries as it's base and handles requests and responses using the Rocket crate. I use sled to store information as (key, value) pairs in a database. Most of these libraries are still experimental and I take this attitude myself by straying off from the reference implementations and changing algorithms in hopes of better performance. If you want to help, check out #rustmatrix:koesters.xyz.
mautrix-asmux wasn't made this week, but I haven't mentioned it on TWIM before. Basically, it acts as a proxy between appservices and the homeserver. The primary point is to make it possible to dynamically provision appservices.
The dynamically provisioned appservices connect to mautrix-asmux with individual access tokens, which asmux checks and then proxies the requests to Synapse with its own global access token. Synapse is only aware of one appservice, which will have a large user ID and alias namespace (e.g. everything starting with _). In the other direction, mautrix-asmux maintains a room ID -> appservice mapping, which it uses to send incoming events to the correct appservice. As a side effect, mautrix-asmux implements MSC2190, which is needed for end-to-bridge encryption.
We continue on our performance drive. We’ll get Redis into production early next week replacing our home grown TCP based replication system. We also landed some SSO fixes for user interactive auth. Additionally we shipped a bug fix release in 1.12.3.
mautrix-telegram now has experimental support for end-to-bridge encryption. It's intended for cases where you don't want the homeserver to have access to messages, e.g. user-hostable appservices. It's currently on the e2be branch and should be merged to master soon. You can find setup instructions on the wiki: https://github.com/tulir/mautrix-telegram/wiki/End‐to‐bridge-encryption
The same feature will make its way to mautrix-facebook and mautrix-hangouts in the near future. After that, I'm going to start working on porting matrix-nio's crypto code to Go to bring end-to-bridge encryption to mautrix-whatsapp and possibly also general e2ee support for gomuks.
I got annoyed by how difficult plumbing IRC rooms is and wrote a simple Python script to do it more easily from command line. Also cleaning old rooms and chats in Riot is quite tedious so I added support for easily leaving rooms to the script. I decided to creatively call it matrixtools and created a github repo for it for others to enjoy. It's still in infancy but more features are already planned such as more IRC management stuff and creating tombstone events to point rooms to other rooms. The tool uses Python and matrix-nio library. Contributions welcome! https://github.com/vranki/matrixtools
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
The bridge bot now sends read indicators for messages successfully delivered to the remote network - only supported on protocol implementations with event synchronising. 🦊
Advanced relay support! Similar to the discord bridge, you can now make an advanced relay, where, if in relay mode, the messages from matrix users appear correctly with username+avatar on the slack side. This works for both classic slack apps and new slack apps, via the events API.
For that the underlying slack client connection had to be significantly re-written, which became its own repository.
Hey folks! I've not posted a proper bridge update in a while, so let's go into another project that isn't a bridge. I've started working on a new project called node-jitsi, which will allow people to connect their services to Jitsi Meet conferences. It's designed to allow bridges to start bridging across actual calls into Matrix via Jitsi, but could really be used by any project which is Node.JS based and wants Jitsi call functionality. The goal is to keep the interface clean and simple, and do all of the heavy lifting (WebRTC negotiations, XMPP handling) itself.
Currently the project has just started, although progress should hopefully be swift! Come check us out in #node-jitsi:half-shot.uk and get chatting
Nio for iOS has been getting some attention this week. Message display is now much better (visually grouped by sender) and I added some preliminary support for contextual event actions. For the time being emoji reactions and redactions have been implemented. (The context menu does trigger the best result of the visual flipping workaround in SwiftUI though 😅)
Loading dialog when sending files is displayed too long
Fixed device settings list
Fix a lazy loading bug
Improve app icon
The current version in the PlayStore is outdated. I need to write a privacy policy first and this can take some time. A TestFlight version for iOS is planned too but not yet ready. Here is a screenshot of the new voice messages feature:
The Quotient project has made two "sustaining" releases this week, and then three^Wfour more to fix foolish mistakes - right on the Fools' Day! Long story short - if you're on Quaternion 0.0.9.4* (with any trailing letter) and, respectively, libQMatrixClient 0.5.x, make sure to upgrade to Quaternion 0.0.9.4e and libQMatrixClient 0.5.3.2 because, as of this writing, these are the latest and fixedest in the breed. Aside from many backend bugfixes (mostly described in release notes from 0.5.3), this refreshed pair can handle SSO and no more interferes with Pantalaimon in encrypted rooms. Further plans include scrapping the whole Quotient thing and switch to Python because it's so much easier. Just kidding :) the plans didn't change, Quotient 0.6 is the next milestone, and the backend for the next Quaternion release. And you won't need to wait another year for them, I promise.
Riot Web 1.5.14 and 1.5.15 were released this week with a simpler Jitsi integration, new keyboard shortcuts (along with shortcut help via Cmd / Ctrl+/), and layout performance fixes. 1.5.14 has a security issue with the Jitsi widget wrapper, so please remove any copies of 1.5.14 if you installed it. Lots of cross-signing polish work continues as we get closer to release.
We made a hot fix release (0.10.5) this week. Cross-signing work is still progressing well. We will run much more tests next week with other Riots to finish the feature.
Ismail, who joined the team mid-week 🥳🎉, has started to do some maintenance work required by iOS 13 SDK.
Through a steady increase in demand thanks to GSoC, matrix-rust-sdk and timokoesters' homeserver, our foundational crates are receiving more attention than ever before, resulting in the following releases last week:
Hello! I'm working on a PHP library (GPL v3.0+) that allows to communicate with a Matrix instance. Currently the library allows to create users, rooms, login to the Matrix server and send messages, although more work needs to be done: https://github.com/artyom-poptsov/matrix-php
I created the library due to my own needs, but probably it will be of some interest for others.
Apparently the author has a need for Matrix-Moodle integration, sounds interesting! An update! Late breaking:
I've updated Matrix-PHP, now there's documentation in README.md on how to use the library. If anyone wants to use it/contribute, this should make the things easier.
There's no release yet though. But for now, the library is capable of:
creating users with on the servers where registration is disabled;
changing users passwords (by users themselves or by admins);
logging in to the server using m.login.password method;
sending text messages to rooms;
checking if a username is available for registration on a server (only for admins.)
I've just released v1.0 of my Matrix helm chart, to help deploy a complete homeserver stack in Kubernetes. Partially inspired by spantaleev's wonderful ansible playbook, dacruz21/matrix-chart aims to be an all-in-one installation of Synapse, Riot, bridges, and other services. It includes a number of Kubernetes security and scalability features, and is ideal for anyone running a large homeserver, or a homeserver in a corporate environment where security is paramount.
Lives in the cloud now so should be more reliable.
Fairly sure Peter is referring to his tracking bot being on new hosting. He could mean that he has ascended to the clouds, and is therefore more reliable, but perhaps he wouldn't have posted to TWIM in that case.
In addition to some performance fixes, the chat bot integration in Rust for openSUSEs Open Build Service can now listen also to openQA events.
openQA is an operating system level integration testing framework that makes it possible to test the installation process, GUIs and TUIs by simulating user interaction on different hardware or virtualization technologies.
OBS is used for development of the openSUSE distribution and can build packages from the same sources for Fedora, Debian, Ubuntu, SUSE Linux Enterprise and other distributions.
Mozilla is hosting a Fix-the-Internet Lab from April 15th - June 15th that specifically calls out decentralization and messaging.
Mozilla’s Fix-The-Internet MVP Lab is an 8 week-long incubator-style program this Spring to mobilize & fund around products and technologies that enable everyone to connect and build a better society.
Sounds like it could be a good fit for a Matrix community project. Each participant would get a $2500 stipend and access to mentorship. There are also significant prizes.
Applications are due Monday April 6 at 11:59PM ET.
Maybe more tangentically relevant, but the Swedish government is launching a three-day remote hackathon starting tomorrow (3rd-6th of April) focusing on saving lives, communities, and businesses. A Matrix solution may very well be interesting to develop for this, perhaps something taking another look at the CoAP/CBOR work.
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.
Fix starting workers when federation sending not split out. (#7133). Introduced in v1.12.0.
Avoid importing sqlite3 when using the postgres backend. Contributed by David Vo. (#7155). Introduced in v1.12.0rc1.
Fix a bug which could cause outbound federation traffic to stop working if a client uploaded an incorrect e2e device signature. (#7177). Introduced in v1.11.0.
