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 terms of Spec Core Team MSC focus for this week, we've been aiming to get the requirements for MSC3952: Intentional Mentions landed as well as discussing MSC3952 itself, in addition to planning out what the next few spec releases are expected to look like.
Watch this space for progress on the Matrix 2.0 MSCs and other critical path items :)
Curated MSC of the week
This week's random chosen MSC is MSC3575: Sliding Sync! It's one of the largest (or is the largest?) MSCs we've ever had, and dramatically changes how clients actually get updates from the server. It's worth the read if you're a client developer, though the team working on it is ironing out some bugs. Let us know what you think on the MSC :)
The Chart
It seemingly was okay with being generated this week again, so here it is:
If you didn't already catch it this week, Gitter has fully migrated to Matrix! 😎
We brought over all of the historical Gitter content to the gitter.im homeserver and gave everyone free rein over it via app.gitter.im, a Gitter branded Element instance.
Of course, since it's Matrix, you can use whatever client you want to access your public, private and one to one (now DM) conversations!
You can read about the full details in the blog post: https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/
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
With the Extensible Events Core (MSC1767) being accepted last week, the focus now turns to all the other extensible event MSCs for images, files, etc. How does extensible events relate to IETF/MIMI/DMA, you ask? In our mission for having Matrix be the standard for interoperability, we need a content format that works for everyone. Events prior to MSC1767 could work with enough effort, though MSC1767's system makes things a lot easier when representing arbitrarily complex messaging features.
Stay tuned to TWIM for progress in this area. It's a relatively slow process, but we're working through it.
Random MSC of the week
This week's random MSC is MSC2785: Event notification attributes and actions! This is effectively a replacement for the push rules system we have today, and a super interesting one (how do you even design a notifications system?). Focus has shifted a little bit since this MSC was first opened, though its ideas still comes up frequently when aiming to make smaller changes to push rules today.
The Chart
The chart has been giving us a bit of grief when trying to be generated, but today it seems agreeable enough to include - enjoy :)
In keeping with our (roughly) quarterly release schedule of the Matrix Spec, v1.6 is due to be released on February 14th. That's only four days from now! The headline features are a new Jump-to-Date Client-Server API (MSC3030) and initial work on speeding up room joins (MSC3706), along with many other fixes and clarifications to the spec text itself.
If you haven't yet seen it, Matthew's Matrix 2.0 talk at FOSDEM walks through some of the upcoming features in the spec. Each will land in subsequent, future releases of the spec. Once all have landed, we'll call that Matrix 2.0 (in name and in actual version number).
Extensible events is one such upcoming feature. While the core proposal outlining the feature (MSC1767) will land in v1.6, the smattering of MSCs which describe how various event types will work under extensible events will span multiple upcoming spec versions. Watch this space!
This MSC is relatively simple; proposing a method for widgets to ask the client for additional capabilities after it has already been initialised. Doing so allows for increased security and privacy workflows, as the widget need only ask for access to certain pieces of data at the point that it needs it (rather than all up front).
A similar transition of permission granting happened in mobile devices and apps. Initially mobile apps would ask for all permissions they would need up front - which users would blindly accept. These days, mobile OS's have shifted to a model where individual permissions are requested upon attempting to complete an action in an app. This way, users have better context on the reason for the permissions request. (Oddly, browsers have yet to reach this stage with extensions - those still ask for all permissions up front.)
Do check out the proposal and its technical details if widgets are your thing!
The Matrix Foundation is a candidate this year again to the GSoC programme. If you intend to mentor a student around your Matrix project, please ping me (@thib:ergaster.org) in the #gsoc:matrix.org room. Your project doesn't have to be set in stone yet: we need to have a good estimate of the number of mentors and projects applying before FOSDEM (by the end of next week).
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.
This week and the week afterwards, the Spec Core Team are mostly focused on improvements to Matrix that we'd like to show off at FOSDEM 2023 this year! That consists of MSCs related to Faster Room Joins (MSC3943 among others) and Extensible Events (MSC1767).
This defines an algorithm and a data structure that can be used to order one's top-level list of Spaces and have that order sync across all of their clients. Rooms and spaces within a Space continue to have their order defined by an order key (and failing that, the origin_server_ts field) in the corresponding m.space.child event of their parent's Space's state.
I won't get into the details of the algorithm here (or its criticisms), but feel free to jump into the MSC and take a look!
Back in July I started a discussion on wikidata for adding a matrix space property, after much discussion in the wikidata community (lead mostly by tgr) we instead landed on a Matrix room property. This now enables slightly more accurate semantics when describing matrix rooms belonging to organizations, projects, and people on wikidata.
Wikidata is a knowledge base available under a free license and using standard machine-parsable data to add information to what is known as the "semantic web", this allows querying for information like for example: Organizations with matrix rooms
As the rest of wikimedia's projects it's open for contributions!
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.
As you can tell from the above MSC list, Extensible Events continues to charge forwards, with Travis working busily away at replicating all of the existing event functionality (plus new functionality - image albums anyone?) in a world containing Extensible Events. As always, take a look at the core MSC (MSC1767) for a background on what Extensible Events is, and why it's so exciting.
This week has also seen room version 10 become the default recommended room version in the spec! As a reminder, v10 brings the ability to have a room that's both knockable and restricted at once, as well as more strictly enforces the types of power level values.
Otherwise we've seen lots of movement in other areas of the spec. Expect to see some work done around push rules (which have historically been rather complicated and fiddly...) and notifications in the days to come.
I remember this MSC fondly. It was originally born out of MSC3489's need to allow any user in the room to send m.beacon_info state events. This can easily be achieved today by lowering the required power level of m.beacon_info to the default user level. However, you then run into the issue of any user being able to edit any other user's m.beacon_info event!
Thus this MSC attempts to modify the state events permission model so that users can "own" certain state events that they send. We already somewhat have this functionality - if you put your Matrix ID as the state ID for any state event, only you or users with a power level higher than you can edit it.
Sadly this little trick (which we use for m.room.member events) doesn't work in the case of live location sharing, as the feature demands the ability to share location from multiple devices at once. Hence, trying to send two m.beacon_info events with the same state key would overwrite each other.
This MSC attempts to expand the functionality by modifying the definition so that a user "owns" a state event if the state key starts with their Matrix ID. Problem solved... for the most part!
Do check out the MSC if you have some use cases in mind that would benefit from something like this.
Since the last few official Matrix holiday updates didn't mention as many of the cool community projects as I would have liked, I tried to work with the community to publish a community side review of 2022 as well as possibly some small teasers of what 2023 will bring. There are a lot of very varied updates, since everyone seems to have tackled the challenge differently, but I hope you you enjoy the result as much as I did: https://blog.neko.dev/posts/matrix-year-in-review-2022.html
A few days later we also published the same blog post on matrix.org, with a few typo fixes and cleanups: https://matrix.org/blog/2023/01/03/matrix-community-year-in-review-2022
This was a bit shot notice, so I would like to extend my gratitude to everyone who contributed and took some time in probably one of the busiest periods in a year! For the same reason, I hope you can excuse if one of your favourite projects is missing. If you have anything that is sorely missing, feel free to reach out in #year-in-2022:neko.dev and maybe I can amend the blog post.
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.
After a lull from the holiday period, work has continued on different parts of the spec. MSC3706 has merged, which furthers the spec side of the work to make joining rooms faster in Matrix (see MSC3902 for the overview).
MSC3938 has also been merged to the spec. The proposal removes a deprecated keyId field and cleans up the endpoint by disallowing trailing slashes.
Sliding Sync (MSC3575) is the next generation of sync - how Matrix clients receive new data from their homeserver. The spec side of the feature has been designed to be modular, with different extensions of spec provided different functionality. MSC3885 is one of those extensions, and defines how To-Device Messages (how different user devices talk directly to each other) would be requested by a Matrix client from the homeserver.
This proposal doesn't appear to have had too much review from the community yet - so feel free to check it out if faster Matrix clients appeal to you!
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.
Some of the spec core team have been on holidays this week, but we still finished FCP on one MSC, and merged another to the spec. As mentioned in last week's update, progress will be slower over the holiday season, but we'll be back in the new year, working to make Matrix better.
Random MSC of the Week
The random MSC of the week is... MSC2783: Homeserver Migration Data Format! If you're running a homeserver using one implementation, it's currently impossible to switch to a different implementation without losing data. This MSC proposes a file format for exporting data from one implementation and importing it into another.
Conduit is getting a lot more usable with this release, the main missing feature is backfill over federation (loading room messages from before your server joined a room).
To update conduit, simply stop it, replace the binary and start it again.
Also feel free to join #conduit:fachschaften.org and ask questions there
It's that time of year again, and we have a special gift for all of you just in time for the holidays: Neochat now supports end-to-end encryption! This is made possible thanks to the release of libQuotient 0.7.
While this feature is still somewhat experimental, it's a big step forward in ensuring the privacy and security of your conversations. Just keep in mind that if your only logged-in client is Neochat and something goes wrong, you might lose your messages.
If you're feeling adventurous and want to try out the new end-to-end encryption feature, you can already get it from Flathub and some distros. We're also working on supporting it in our Windows, Android, and macOS builds, so stay tuned for updates.
And in the spirit of the season, here's a Christmas joke: Why was the JavaScript developer's house cold? Because he left his closure open!
Happy Holidays from us at Element! This is our last update for 2022, and it’s a good ‘un.
We’re still working on Notifications, reviewing how they work across platforms for new users, and planning the improvements we’re looking to make in the new year. While we look at this user experience holistically, we’re making some subtle changes to the product including removing the bold dot and ordering rooms by activity by default for new users.
We’re also continuing to improve the password reset flow so that user’s who can’t remember their passwords have a smoother experience regaining access to their account.
And, thanks to a contribution we now have the ability to multi-select members when changing users’ permissions in a room! Head to Room Settings > Roles & Permissions.
In labs (you can enable labs features in settings on develop.element.io or on Nightly):
Rich text editor improvements are still coming so be sure to check them out, including updates to emoji handling and inline code formatting.
Threads! Threads notifications and performance improvements are landing thick and fast. We’re nearly ready to enable the feature by default and we’ll be excited to do that in the new year.
Be sure to check that you’re still in the threads beta for this release as in fixing some bugs your setting may have been changed.
There’s been some bugs and crashes keeping us hard at work this week. Along with some exciting improvements to both Element and Element X. On Element:
There are updates to voice broadcast features and users can sign out of other sessions.
The colours for pills have been updated and work better in both light and dark mode.
Threads improvements have been made and we’re looking forward to enabling this feature by default for all users in the new year.
On ElementX we’re moving ahead fast and this week focused our efforts on the Settings pages and the bug reporting functionality (including rageshake detection and screenshot management)
It took us (yes, us - there's more than one person actively working on the project!) a very long time but libQuotient 0.7.0 is out, with a huge wall of release notes. Big, big, BIG thanks to Carl Schwan and Tobias Fella for their contributions and early adoption of this release in NeoChat (NeoChat maintained compatibility with libQuotient's development branch, along with the stable branch, for quite some time by now). A short summary of most significant things:
Requirements: C++20, Qt 5.15 or 6.x
E2EE code is now in beta quality, features:
sending/receiving new messages
getting historical messages where Megolm keys are already loaded
encrypting/decrypting attachments
device verification (to-device flow only, no in-room verification yet)
Individual APIs for m.fully_read and m.read markers
Client-Server API backend uses Matrix 1.5 API definitions
A complete rewrite of the event types framework to make it truly extensible; you can now add both base classes and specific event types on the client side without touching the library code (the library still provides standard ones)
Account registry for multi-account usage; account access tokens and pickling keys are stored with Qt Keychain
Sticker events support
Pinned messages support
First-class support in Network Access Manager for mxc: URLs, to enable showing inline images in messages
A lot of code tightening, bug fixing, performance improvements
Merry Christmas and Happy New Year to those who observe those - and hopefully I'll get to my senses and release 0.8 sooner than in another year 🙂
As part of the efforts for working on detecting spam using ML I started to write a moderation bot.
This bot is written from scratch with some design decisions that hopefully will improve usability for both newcomers and seasoned admins.
These decisions are:
If an action can be done using a reaction, then it will be done using a reaction.
There is a private admin room and a public room for warnings, where admins issue actions. This is meant to serve as a human-readable ban list if admins want to provide this to their users.
The bot will at a later point be able to issue reports to server admins via email and matrix easily by allowing admins to just react after doing a ban. The bot will initially ask how to contact a server if it didn't issue a report to the server before. The bot will remember the setting supplied last time for a server and allows updating the settings if they change. These reports will contain a warning that it was issued from the bot and that replies are necessary for it to be properly relayed back to the admins for further questions. These replies will end up as threads in the admin room. Also, as part of the report, the event JSON for the report will be sent with the report to allow server admins to review the case themselves. (This is still WIP)
The warnings also contain a "false positive" action. This is meant to be used to feed back into the used model for further training and improving it.
All in all, I hope to simplify the process of moderation based on what I experienced as an admin. Feel free to chime in at #matrix-spam-ml:midnightthoughts.space to suggest ideas for the bot. At the time of writing, it is still very much a prototype/demo.
The code can be found at https://github.com/MTRNord/matrix-spam-ml/tree/main/bot
Documentation can be found at: https://mtrnord.github.io/matrix-spam-ml/bot
Dept of Ping
Dept of Ping will be back next week.
That's all I know
There will be no TWIM next week, but we'll be back in the new year. Be sure to stop by #twim:matrix.org with your updates!
BwMessenger (the German Armed Forces' branded version of Element) is expanding to cover the whole of Germany, as BundesMessenger: https://element.io/blog/bundesmessenger-is-a-milestone-in-germanys-ground-breaking-vision. Super exciting to see Matrix spreading throughout the German public sector (as well as Sweden! https://element.io/blog/dsam-och-esam-forordar-matrix-for-saker-och-federerad-kommunikation-inom-sveriges-offentliga-sektor/)
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.
With the year wrapping up, the Spec Core Team has been looking at getting some of the outstanding MSCs landed and ready for spec writing, as well as writing more spec itself. There's also plenty of work behind the scenes on Extensible Events: a mission to redefine how events work within the Matrix ecosystem. Check out MSC1767 and friends for an overview of what this actually entails.
SCT Holiday
We're coming up to some holiday time for the SCT: the spec progress might naturally slow as we all close our laptops, but we'll be back in our full capacity in the new year, working out the next version of Matrix in time for FOSDEM (hopefully) :)
Telodendriav0.1.0 was released earlier this week. This is the very first tagged release, and it is a mostly symbolic release intended to signal that most of the elementary components necessary to construct a Matrix homeserver are now in place, and I'm ready to actually start implementing Matrix API endpoints. In fact, I've already started on the user-interactive authentication API and the registration endpoints, and am making good progress on them.
As always, I could use your help. If you like what's happening, then feel free to spread awareness about the project, come say hi in the Matrix rooms, or send a donation. Again, #telodendria-newsletter:bancino.net has the latest, and now that I'm actually versioning the project, you might be interested in #telodendria-releases:bancino.net, which is a low-traffic room that simply notifies of new releases.
How is it Friday already (and the end of the year)?? While the holidays are almost upon us, the
team behind Synapse has been hard at work and has released v1.74.0rc1 for your consideration.
Some notable features and bugfixes include:
Improved user search for international display names
The addition of a new push.enabled config option to allow opting out of push notification calculation
Fixes for a long-standing bug where a device list update might not be sent to clients in certain circumstances
The addition of Single-Sign On setup instructions for Mastodon-based instances
and much, much more! You can take a look here: https://github.com/matrix-org/synapse/releases.
A note about the end of the year: With the holiday season coming up we plan to release Synapse v1.74.0 as normal next Tuesday, December 20th, 2022 and then skip releases for the next two weeks, before resuming with v1.75.0rc1 on Tuesday, January 10th, 2023.
The bridge now avoids double bridging even with multiple users running the bridge client side. It also prevents historical messages from showing up in Valheim, so that starting the game is less confusing. Last but not least, red_sky (nheko.im) ported the user color algorithm from Nheko, so the colors should now look more familiar instead of being a generic blue.
Nheko now prompts you to join the upgraded room, deletes image files you haven't accessed in a month (which freed over 1GB of data on my system) and tries to focus the chat, when you start typing.
LorenDB also added support for confetti messages, although those seem to work only on systems, that are not mine! You can of course turn them off in the settings. :D
What’s this then? The last release of Element in 2022, that’s what! And to round out the year, we’re enabling Threads for everyone in the release planned for the 20th of December!
Threads: Enabled by default for everyone. Please let us know if you discover any issues as we get ready to make them permanently enabled.
Notifications: The Spaces button now shows a badge to indicate the number of unread conversations in other spaces so you won’t miss those important messages or invites anymore.
Things are quickly moving along on the ElementX side too
the new split iPad and macOS layout has been merged
the timeline has been refactored and scrolling is now smoother than ever
we have brought our code coverage to 45% and actively working on making it even better
and we’re also working on improved room list loading, a new room details screen and improving the developer experience and reliability
Element Android 1.5.12 is currently being released on the stores. It includes threads support, enabled by default.
We are currently working on finalising the session management screens, and we are fixing issues in polls. The composer is also getting some improvements, like support for links, code blocks, quotes, etc.
On ElementX, we are working to setup the project: dependency injection, continuous integration, and other similar tasks.
matrix-social is a new Matrix "Social Media" client made using the Matrix Rust SDK and Yew. With a design inspired by Reddit, matrix-social's purpose is to be a social media client that integrates well with the rest of the Matrix ecosystem. At the moment, it is very early in development, and lacks crucial features such as sending messages, comments, reactions, and categories.
The source code is licensed AGPL and hosted at https://codeberg.org/imbev/matrix-social
If you have experience with Rust, WASM, or are otherwise interested, join us in https://matrix.to/#/#matrix-social:matrix.org
Added: Create and mutate users using the Synapse API.
And, together with the team of the #matrix-berlin:matrix.org, I've added (hidden URLs so far) pages for people to analyse their Matrix usage (How many of my DM contacts are in a given room? How many homeservers are joined to a given room? Which of my DM contacts do I share the most rooms with?). For a preview or to bring in your ideas, please join us in #matrix-dashboard:matrix.org.
Going towards Christmas we from Nordeck can announce that we made another of our widgets Open Source: matrix-barcamp.
The matrix-barcamp widget allows to perform agile Barcamps in Matrix spaces. You can create a space, add the widget to a Lobby room and use it to collaboratively create your Barcamp agenda.
Once you set up your sessions, the widget can take care of creating the individual discussion rooms inside the space.
The widget was created in collaboration with the ZIT SH from the German public sector.
Like the matrix-poll widget, this widget is built using TypeScript, React, our matrix-widget-toolkit, and the matrix-widget-api.
Our remaining widgets will follow soon, we keep you updated here.
With the last fixes ported over from the demo branch and the growing-full-sync-window support added, we turned our head back to debugging a few remaining deserialization and decryption bugs in Sliding Sync when we were hit by a new tokio-thread-panic on Element-X at the end of the week. A quick debugging revealed that it was caused by out of bound indizes supplied by the server. We are still looking into making our code more defensive for these circumstances, too.
Async Uniffi is progressing nicely meanwhile, with now both Swift and Kotlin being able to run and execute a Rust created future. We now have fallible function support implemented on the proc-frontend and further work is coming up to support &str and &[u8].
This week also saw the first experimentation in replacing the default Sled database backend. A first PoC attempt was made with sanakirja (pijul is based on), but after learning that its API is unsound and can lead to UB, the team agreed that this requires quit a bit more work (especially in terms of safety guards) than we have time for in the short term. Thus, offering a sqlite-backend for mobile in the short term at least for the crypto store has been agreed upon.
👉️ Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at Matrix Rust SDK.
Matrix Community Summit Berlin 2022 Podcast (German)
Meet ben, Rust developer and Co-Founder at EFFEKTIO. He and I spoke about Social Organising and how his app tries to enable people to participate more directly in their community, political party or neighbourhood.
Very good news for FOSDEM: we managed to make some room for all of the proposals we got! We thank everyone participating in our CfP for submitting such high quality proposals. Our in-person devroom is going to be on Sunday 5 morning, between 09:00 and 13:00 CET. It was difficult to make a choice, but we had to put some talks in the virtual devroom only in the afternoon. We will follow-up with speakers individually.
We will also have a stand at FOSDEM, and will be happy to see you there, talk about what we're doing, what's next and just generally have a nice chat together.
If you want to learn hands-on how to establish Matrix and Element for your company or team, how to operate it, or how to make small IoT components operatable via Matrix – or know someone who wants to know – and speak German, don't forget to get seats while they're available 🤓!
Forgejo’s code base is of course hosted on Codeberg, and by using Woodpecker CI instead of Drone and Matrix instead of Discord, we exclusively rely on Free Software tools.
Are you a client developer working with custom event types in the Matrix ecosystem? It can be tough to keep track of all the different events that are being used, and even harder to interoperate with other developers' clients and bots. That's why I've built the Matrix Events Directory, a website where you can look up and register custom event types.
Here are just a few ways the Matrix Events Directory can help you:
If you come across an event type that you're not familiar with, you can use the directory to find out more about it and decide if you want to do anything with it.
If you're working on implementing a new feature in your client, you can use the directory to see if anyone else has already done it and potentially interoperate with their work.
I hope that the Matrix Events Directory will improve interoperability and make it easier for the community to define and use their own custom events, while still being able to build on top of the Matrix spec.
Please check out the repository and the website at https://matrix.directory. Contributions are welcome!
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.
