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://spec.matrix.org/proposals.
In this new segment, we aim to give a bit more context as to why an MSC was opened, beyond what is available in the MSC's introduction.
MSC4056 stems from a conversation held back at IETF 117, where members of the Spec Core Team (SCT) were attempting to make RBAC work in Matrix. Thankfully, there was prior art in the form of MSC2812, but a problem with decentralization (and specifically state resolution) was discovered. Thoughts were had about how to fix it, and MSC4056 is the result of those thoughts. Implementation work is eventually planned for this MSC, but in the meantime it should see forwards movement with the SCT's involvement in the MIMI working group at the IETF.
If you have thoughts or suggestions about the very Discord-centric approach, please leave them on the MSC :)
We’d like to thank everyone for their patience as we continue to work toward restoring the Libera.Chat bridge, and apologize for the continued inconvenience. We’ve heard from many people and communities who are impacted, who have confirmed that operating this bridge is an important service and we remain committed to getting it back online.
It’s been a month since our last update and folks have been reaching out, so we wanted to take this opportunity to provide a brief update.
The bridge team at Element is still actively working on the issues that led to the bridge being disabled in the first place. You can see some of the work that’s in flight through GitHub PRs: #1757, #1766, #1764, #1734.
We’re also looking into a way to transition responsibility for the bridge from Element to being directly run by The Matrix.org Foundation over the coming months - more details as we have them.
Unfortunately, we do not yet have a clear timeline for bringing the bridge back online. We’ll continue providing regular updates and will share more information as soon as we can. Thank you again for your patience! Please do not hesitate to reach out at #libera-matrix:libera.chat if you have any questions or concerns.
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://spec.matrix.org/proposals.
We've been quite busy at IETF 117 this last week discussing MLS and MIMI in several contexts, meetings, and sessions. Overall things have moved pretty fast in the last week, but the short summary is we're working with MIMI to get (Linearized) Matrix used as the new-found "signalling layer". This layer delegates membership of the room to the crypto layer when the crypto layer (namely MLS) supports being used as such, and is responsible for enforcing all policies. Policies in the context of MIMI are things like join rules, history visibility, and power levels, but with an added twist: we're looking at supporting Role-Based Access Control (RBAC) in combination with power levels in MIMI, which should also bring RBAC to Matrix in the form of a currently-unwritten MSC.
All told, we've got several new documents to write and MSCs to draft, but we'll get there in time. The MIMI working group is expecting solutions in place by about September, so watch this space for more news as we progress. An architecture draft is also in progress on the MIMI side to further explain what all of these new layers mean. In the meantime, if you have questions then please visit the matrix-spec room on Matrix!
We're also looking for more Matrix 1.9 candidates. Currently we have just custom emoji and anything to do with MIMI on the agenda - if you'd like to add more, let us know in the Office of the Matrix Spec Core Team room on Matrix.
This MSC describes a method for verifying (cross-signing) the devices of a bot user, and how verification of that sort could be done. Obviously it wouldn't make much sense to verify emoji with a bot. Instead, this MSC suggests that the bot provide a URL to present to the user. If the URL appears trustworthy (those who would control this URL should also be in charge of this bot), then the user can choose to continue the verification.
The user's Matrix client would then make a request to the URL with details of the verification. If the server responds successfully, some cryptographic magic happens, and your client will consider the bot verified!
This is essentially tying a bot's verification with control of a domain's DNS, which I think is a smart way to do things. But you do need to watch out for those pesky UTF-8 control characters when asking the user to verify the URL!
Some stability issues on the bridge have prevented people from turning their portalled rooms into plumbed ones. We have been actively working on resolving those issues since the first reports and the situation is gradually improving. However, at this point, we do not believe the plumbed mode can be considered sufficiently stable yet.
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://spec.matrix.org/proposals.
Work to use Matrix as the standard for interoperable messaging at the IETF is continuing in full stride. At IETF 117 (July 22nd - 28th, 2023) we'll be talking about the precise requirements of an interoperable protocol, and encouraging Matrix be that protocol. Linearized Matrix is our proposal for the room model, with more updates expected in the coming days ahead of the submission deadline, meanwhile yours truly is working on using MSC1767 Extensible Events for a content format. Watch this space for updates leading up to IETF 117 🙂
We're also well on track to test interoperability of different Linearized Matrix implementations at the Hackathon - get in touch with us via the #sct-office:matrix.org if you're working on such an implementation so we can coordinate details. It's not too late to get started either; Linearized Matrix itself is relatively simple to implement compared to the full capability of Matrix, by design.
This MSC provides a means of establishing a trusted, secure communications channel across a potentially untrusted network. Subsequent MSCs could then use this channel to transfer details such as login tokens or key backup credentials in the context of setting up a new Matrix device. MSC3906 is one proposal that takes advantage of this.
This is just one piece of work building on the tree of MSCs supporting the shift of authentication in Matrix from home-brewed to OIDC. See https://areweoidcyet.com/ for more details on that effort.
Libera Chat recently announced their decision to opt-out of portalled rooms
from the Libera.Chat bridge instance hosted by the Matrix.org Foundation
(a decision we regret but respect).
This means that for the bridge to keep working, all of your portalled rooms
need to be turned into plumbed rooms before July 31st. All of this might be a
bit obscure, so let’s walk together through these concepts and give you the
tools to make sure the bridge keeps working for you.
We launched the Matrix Public Archive publicly on June 2nd, 2023.
We decided to take it down on Sunday, June 25th out of precaution after a
member of OFTC staff warned us that the archive made the content of two OFTC IRC
channels bridged to Matrix available on the Internet.
After investigating the issue, we determined that the Matrix Public Archive's
behaviour was expected for these channels, given an IRC chanop had
explicitly configured the Matrix side of the rooms to be world-readable.
Let's talk about how room visibility works in vanilla Matrix, how it works with
bridges, and what are the next steps.
You might have seen the news already, but the Matrix.org Foundation is pleased to welcome the first public sector organisation as part of its membership: Gematik joined us as a Silver member!
Whether you're an individual, a business, a non-profit, a public sector organisation, you can join the Matrix.org Foundation as a member to support us in our mission and help us steer Matrix in the right direction!
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://spec.matrix.org/proposals.
Room version 11 has been accepted! A gentle reminder for Matrix client and homeserver implementations to update and incorporate the new changes. The full list can be found in the MSC itself (mainly changes to redaction semantics and related fields).
While this means that room version 11 is now considered stable, it's not recommended that homeserver implementations set their default room version for newly created rooms to 11 yet. We recommend waiting a few months for client and other homeserver implementations to gain support first.
Matrix has a concept of shared moderation policy lists - where you can create a room containing moderation actions that followers can apply to their own rooms, such as banning a particular known bad actor.
This MSC proposes to expand the list of possible types of recommendations with that of muting a user (removing a user's ability to send messages in a room). This could be especially useful if you moderate many, many rooms and have automation to apply moderation actions based off of a policy list room.
If such a policy change sounds useful to you, why not give the MSC a review and leave some feedback!
I've updated the Dash/Zeal Docset which you can use to read the Matrix Spec offline.
If you use Dash and installed it through the application's settings, an update should be available now. If you use Zeal, check out the update procedure on gitlab.com.
This week we released 1.87.0rc1. Please note that this will be the last release of Synapse that is compatible with Python3.7
and earlier. Now on to the highlights:
Add spam checker module API for logins
Fix forgotten rooms missing from initial sync after rejoining them
Remove experimental MSC2716 implementation to incrementally import history into existing rooms.
Fix a bug introduced in 1.57.0 where the wrong table would be locked on updating database rows when using SQLite as the database backend
and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at https://github.com/matrix-org/synapse/issues/new/choose.
Huge refactoring of Dendrite and gomatrixserverlib to pave the way for easier experimentation
A potential state reset when joining the same room multiple times in short sequence has been fixed
Several "membership" (e.g /kick, /ban) endpoints are using less heavy database queries to check if the user is allowed to perform this action
/3pid endpoints are now available on /v3 instead of the /unstable prefix
Support for connecting to appservices listening on unix sockets has been added (contributed by cyberb)
Admin APIs for token authenticated registration have been added (contributed by santhoshivan23)
...and a whole lot more. Check out the release notes for the full set of changes!
As always, feel free to stop by #dendrite:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.
After long time of inactivity in chooj's repo because I was busy with other stuff, we now have many improvements. Two most important changes are not user facing yet very important for development of chooj in the long term. First, the UI stuff have their own repository and are a separate NPM library. Second, I have almost converted the codebase from Javascript to Typescript. There are other small changes. Many bugs have been fixed. If you had problem logging in with chooj on your feature phone, give the build specified in this issue a try. It should have solved the bug. And please let me know if it fixes the problem, or if you have any other issue.
Element X Android is making big progress to become the fastest Element application ever developed! The application is now using the new Room List API from the Matrix SDK.
The application is getting lots of UI / UX polishment, as we are integrating the latest design.
Last but not least, the app has been renamed to “Element X” (with a space) and got a brand new icon!
We've made further steps towards fixing stuck notifications on nightly. The unread dot is now more reliable -- especially when used with the "mark room as read" functionality. We've also fixed reactions gone missing when the reacted to event isn't yet synced. Our plan ahead consists of re-triaging existing issues to surface cases we haven't yet accounted for. Afterwards we'll push ahead with MSC3981 which is already implemented both client- and server-side but needs testing. For further details, please see the tracking issue.
Our work on improving the notification settings is being finalised. We've conducted user testing this week and are preparing for a labs'ed launch.
As part of our integration with Compound, our new design system, the first pieces of typography and colour updates are landing on nightly. More news in this area soon.
Finally, we've also progressed on integrating OIDC and managed to get the login flow working in a POC manner.
Element Android 1.6.3 is now available for 20% of the users in the PlayStore. We are confident that we will reach 100% deployment by the end of next week, and then we will release the app on F-Droid. The roll out is slower than usual since this version is integrating the Crypto Rust SDK (the new Matrix SDK developed in Rust and also used by Element X iOS) and the migration of user private data is quite a sensitive area.
@sctlib/rtc now has support for Matrix /sendToDevice signaling.
It's a web-component that tries to offer a user interface for peers to connect via WebRTC
There are different "manual" signaling methods (such as copy/pasting the WebRTC connection data by hand, from one peer to the other), and the Matrix API /sendToDevice endpoint is the new addition.
It works with authenticated matrix users, as well as with guest user/device.
All this is a prototype and experimentation with client side browser based apps (with js/html/css/web-components/npm-packages), using @sctlib/matrix-room-element and its new api.js.sendToDevice method.
One of the thing I enjoy with this project, is that it is web-component based; meaning the new HTML custom DOM element, has a "clear API" through it's attribute api, methods, events (just like an <img/> or <video/>, or <form/> etc.).
allow to forget rooms (delete room specific content from database and cache) -> rewrite of the cache to allow indexes
PowerLevelsEventContent with type safe "events"-field (e. g. allow content.events.get<MessageEventContent>() additionally to the old way content.events["m.room.message"])
Introduce module trixnity-crypto-core and replace native crypto algorithms using native APIs (CoreCrypto on apple and OpenSSL on linux/mingw targets)
The library is fast approaching the 0.8 with the process being much steadier than before, now that we actually practice smaller, more frequent releases - thanks in no small amount to NeoChat people, nicely prodding the author of these lines on a regular basis. The release notes (very short, apparently we've got the beta right) are, as usual, at the project's Releases page and the final release can be expected some time next week, if we don't have unexpected showstoppers.
And just in case someone doesn’t know where to find us - you’re welcome in #quotient:matrix.org!
Have you ever had the need to set the same power levels for the same users in the a lot of rooms?
It's fairly tedious.
That's what room-architect tries to solve. You create groups of users and groups of rooms and set power levels to room-group<->user-group pairs, and this bot will keep the power levels there (as long as the Bot has the necessary power levels itself of course).
I have more planned, and a few more ideas beyond those, if you want to help, open a pull request on the project's Codeberg repository or open an issue if you find a bug. There is no Matrix-Room for this project yet, but I might create one if there seems to be interest.
Introducing Gate Bot, a Matrix bot that empowers Matrix room owners to create a safety gate between incoming users and their community. Through the use of verification checkpoints, including CAPTCHAs (with ongoing exploration of alternative methods), Gate Bot can effectively thwart automated spam bots while ensuring the protection of communities and their members.
Invite Gate Bot to a room to get started, then follow our setup guide on Github.
Last weekend, I made a few small changes that fixed or worked around minor bugs and usability issues that were brought to my attention by community members. This should make interactions with the bot match expectations more closely. Hooray for collaboration and iteration!
DevConf.CZ, an annual, Red Hat sponsored, open source community conference in Brno, CZ, was held on June 16 - 18.
This year, the conference was piloting Matrix as a primary communication platform and this is a short summary of how it went.
In the end, we went the self-hosting way!
Our hero @duck:milkypond.org from Red Hat's open source program office team did all the heavy lifting by setting up the Synapse and all the necessary services around it, incl. Mjolnir.
We've tried to use conference-bot with schedule in compatible json, but DevConf not using Pentabarf turned out to be too limiting, at least for our use-case.
Taking advantage of the Spaces feature, we created #2023:devconf.cz with three sub-spaces: 'General', 'Sessions', and 'Workshop & Meetups'. Attendees were suggested to join the 2023 space and go from there, as opposed to sharing invites to specific rooms or sub-spaces.
@inknos:snag.social and myself, @mhoyer:snag.social wrote a simple bot that was creating Q&A threads for each talk. It also pinned this message/thread. Online and in-person attendees were suggested to use the Q&A threads to ask questions and session chairs asked them to the speaker(s) in the time dedicated to questions and answers.
'Sessions' space was a home for rooms, which were an extensions of the real-life auditoriums. These rooms had a widget with a Youtube live stream and Q&A threads.
All rooms had a widget with a schedule for said room. The widget was pointing to a website designed to be used as digital signage, so it reflected any schedule changes immediately.
Compared to FOSDEM, and given the size of the conference, we decided to have only one general-purpose public room, which I think worked well. This way, organizers are able to do @ room pings there instead of creating a dedicated "Announcements" room for example.
I should also mention we've put together a Matrix section at devconf.cz web FAQ section: https://www.devconf.info/cz/faq/#matrix
The organization team did a great job communicating everything to the attendees, even the fact that it is a "pilot" and things might break (they didn't, yay!).
I don't have the exact numbers, but I believe there were 300+ users in the Main Chat room, which as far as I can tell is comparable to any chat platforms used in previous years. Not bad for a first year, especially since we only had a very limited time-frame to make it happen.
@dvolavko:matrix.org, the organizer of DevConf.CZ, shared this:
"""
Overall positive feedback. I think we should fully transition to Matrix after this experience. We were collecting attendees to telegram chat for the past 5 years and we reached a similar number on Matrix in 3 days.
""
TRBot is software written in C# and .NET 7 for playing video games collaboratively through an easy to learn, hard to master text format - think Twitch Plays Pokémon to the next level and with any game. This week we released version 2.8.0, which adds support for reading inputs in unencrypted Matrix rooms! On top of TRBot's built-in Twitch, IRC, XMPP and now Matrix support, Matrix bridges will unlock a multitude of other services to run TRBot on for more players to join in on the fun.
Join our room at https://matrix.to/#/#TRBot-Dev:matrix.org for development discussion and updates! We also use TRBot to host collaborative play streams through a community called https://matrix.to/#/#type2play:matrix.org.
Did you ever have a list of email addresses and Matrix rooms (or spaces) which you wish to invite them to? And you don't know their Matrix usernames or if they even have a Matrix account yet? Then this is going to be for you. ✨
For this year's edition of the Berlin University of the Arts open house day presentation (come visit July 21st - 23rd if you are around!) students and others are going to make use of Matrix once again to digitally present and announce their art pieces, installations, performances, events -- just like they did for the last two years. As part of the digital programme we kept running into the same issue: we have a big Matrix space structure representing an existing hierarchy of faculties, institutes, campus buildings, rooms, study programs, classes, seminars and so on. And with each of them we have a list of maintainers as in people who are responsible.
While we're still mostly working on other projects, we wrote the matrix-email-onboarding microservice to invite users to Matrix rooms (or spaces) via their email addresses, even before we know if they actually have a Matrix account or not.
It comes with a CLI tool to send out emails 📨 with a link (containing a secret token) for your users to click on (screenshot 1), and
A Node.js server-side application to handle web requests to
(1) check a given secret onboarding token 🔍 and list the linked Matrix rooms or spaces (screenshot 2)
(2) let the user sign in ☑️ with their Matrix account and automatically join the given rooms or spaces
(3) (optionally) promote those newly joined users to become moderators or administrators 🧑⚖️
We've decided to CC0 it. So go crazy, make use of it in your public institution, use it for your company, tinker around for yourself, create Issues or send Pull Requests on GitHub and do let us know what you think! Looking forward to all of it. 🥰
We were already proud to announce
that the national agency for the digitalisation of the healthcare system in
Germany (gematik) had selected Matrix as the open standard
on which to base all its interoperable instant messaging standard, back in 2021.
We are now delighted to let the world know that they are doubling down on
sovereignty and sustainability: gematik is the first organisation of the public
sector to join the Matrix.org Foundation as a Silver member.
Collaboration in the public sector
Our friends at the FSFE have been calling for software used
in public services to be free software in their
Public Money Public Code campaign. As
advocates of open standards and an open source project ourselves, this is
something we can get behind.
Software development can be an impenetrable world for people who don’t work in
the field. It can sometimes be difficult for people outside of our industry to
understand the importance of bitrotting and refactoring. One very unfortunate
effect of this is that new features are easy to fund because they feel very
tangible, but the most critical housekeeping work is not as appealing.
Yet, without regular refactoring to clean things up, it gets increasingly costly
and difficult to add new features. Counterintuitively, spending money on “the
boring tasks” is the most efficient use of money: without it the technical
stack would become either obsolete, bloated, or both, and it would be much more
costly to move to something else or maintain an in-house fork.
We’re very happy gematik is doing the right thing by supporting the technical
stack it builds TI-Messenger on. By supporting the Matrix.org Foundation,
gematik contributes to the sustainability of the protocol powering the
communications of the German healthcare system… but not exclusively.
Sharing costs across public services, and with the private sector
Matrix is an open standard, which means not only everyone can use it: when
someone contributes to Matrix, everyone benefits from it. This makes Matrix
particularly interesting for the public sector: if the German healthcare
contributes to Matrix, the German Armed Forces
benefit from it, and the other way around. It allows both to contribute less
of their budget, instead of contributing each to an entirely different
product. The German Federal Ministry of Defence already actively contributes
to Matrix development and funding via its public IT services provider BWI GmbH,
who relies on Element’s consulting services to develop their own Matrix-based
messenger.
But Matrix being open source, it also allows the public and private sector to
share the costs of maintenance by design. The public sector benefits from
the contributions of the private sector to Matrix, and the opposite is true as
well.
The Foundation plays a critical technical and social role in this system: it
centralises and curates contributions to the protocol so it remains unbiased,
coherent, and efficient.
This is just a beginning
We’re extremely happy to welcome the first public sector organisation in the
Matrix.org Foundation! Given how popular Matrix is among governments and the
public sector in general, we know this is just a beginning: it would be
illogical to deploy any solution at a large scale without contributing to its
sustainability.
Whether you’re an organisation from the public or the private sector, looking to
cut costs down by building on a common, standard and reliable foundation, you
can support Matrix and
join the Foundation today.
