For the past two years, FOSDEM couldn’t happen in-person. Fortunately we could
help, and Matrix hosted the world's largest free & open source software
conference online! This year we were finally back in-person… but not only.
The set-up we have arranged in 2021
and polished in 2022
has proved to be robust and served us well during the pandemic. Returning to an
in-person conference didn’t mean we had to throw it all away… quite the
opposite!
Greetings Matrix fans! We've published Synapse version 1.76
as the new stable release this week. Synapse admins are encouraged to upgrade
to it at their convenience. Please take a look at the upgrade notes
for any important information about upgrading.
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!
We published Synapse version 1.75
as the new stable release this week. Synapse admins are encouraged to upgrade
to it at their convenience. It seems like the blog post for version 1.74
was eaten by Santa's reindeer, so this post will also cover changes from it.
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!
Note: This was originally posted on https://blog.neko.dev/posts/matrix-year-in-review-2022.html , which also includes some small info boxes about each projects, which got lost in the translation.
As we send off 2022 with a bang, it makes sense to look back on what we did this year and where we want to go next year. In its holiday special post, the Matrix Foundation has been focusing on the core team's work. This post is focusing on the achievements of the community outside of the Matrix Foundation.
I tried to reach out to as many people I have seen do "stuff" on Matrix and have them write something they would see fitting for a year in review. Now, most people have better things to do between christmas and new years, so I hope you can excuse if some projects are missing. Also I probably forgot like half of the interesting people... HOWEVER! I hope you still enjoy what everyone wrote up. And don't forget to check out the official Matrix Holiday Update 2022 and of course read you weekly TWIM to keep up to date with any cool projects you find.
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.
MSC3917: Cryptographically Constrained Room Membership is rather interesting. It aims to make room membership in a room cryptographically verifiable via a "Master Signing Key" that's controlled by users. This is in addition to the homeserver signatures typically placed on events in Matrix. The purpose is to prevent a homeserver from being able to lie about your membership in a room. While not the end-all-be-all solution to this particular problem, it's certainly a well-reasoned take.
Matrix @ IETF 115
This last week (well, last few months), the Spec Core Team has been working on defining Matrix as the standard for interoperable messaging at the IETF level, under MIMI. The current drafts can be found in these places:
Matrix as a transport for MIMI: https://turt2live.github.io/ietf-mimi-matrix-transport/draft-ralston-mimi-matrix-transport.html (MSC3918)
Matrix as a message format for MIMI: https://turt2live.github.io/ietf-mimi-matrix-message-format/draft-ralston-mimi-matrix-message-format.html (MSC3919)
We'll be publishing these as proper Internet-Drafts once submissions open back up at IETF in a week or so. In the meantime, if you have any feedback then please let us know on the MSCs 🙂
A loose collection of thoughts on how presence (the ability to see whether people are online/office) may be improved at the Matrix protocol level, and how it could be integrated into a profiles-as-rooms feature (MSC1769). Check it out if presence is something you're interested in!
A soon-to-be working group within the IETF called "More Instant Messaging Interoperability" (MIMI) is aiming to solve, well, messaging interoperability for primarily reasons of the EU Digital Markets Act (DMA). The DMA requires "gatekeepers" to interop with other platforms while maintaining the same level of encryption, and we think Matrix is the perfect fit for this use-case. While we'd likely be saying goodbye to Olm and Megolm in the process, we'd be saying hello to Messaging Layer Security (MLS) and its decentralized counterpart DMLS - a good thing in our books, at the moment.
In terms of what we've done this week in publishing our drafts (and soon to be real Internet-Drafts under the IETF process), we're formally proposing that Matrix's Federation API and event schema be used for messaging interoperability. Our very own Matrix spec process will be impacted by this sort of direction as it makes it (theoretically) "harder" to change details of the spec. To avoid it being extraordinarily difficult, we'll be nailing down some of the edge cases of the Federation API and event format ( 👀 extensible events) naturally as we work closer and closer to an RFC series. We'll also be making some architectural changes to our specification itself to better support half of it being in the IETF domain, like defining room versions more clearly and splitting non-core spec out of the way. It's worth noting that this is a relatively slow process as we work towards the deadline of DMA a few years from now, but the changes might be felt by the ecosystem on a more rapid scale.
At the moment, we're planning to attend IETF 115 to help keep Matrix on the map for MIMI and raise our feedback about the proposed working group charter. Discussions about whether Matrix is the correct fit are already ongoing, but expected to increase as we get closer to IETF 116 next quarter. We were also already at IETF 114 a few months ago where many of these conversations started.
Future work is currently expected to come through under my name, as have the current drafts (both with obvious input from Matthew as project lead). Watching this space and the spec process for updates is best 🙂
The Matrix Spec 1.4 is now available as a Docset for the Dash offline documentation reader.
You can install this docset from Dash's Preferences > Downloads > User Contributed.
This docset will likely be kept up-to-date by me. This is not an official distribution channel of the Matrix Spec team – things may break.
If you're using the open-source reader Zeal, you'll have to install new versions manually:
https://gitlab.com/jaller94/dash-matrix-spec#use-with-zeal
Hi everyone, I'm working on a little Matrix project called Telodendria.
Telodendria is eventually going to be another homeserver implementation. It isn't one yet; I'm still in the very early stages of prototyping it, and writing some boilerplate code, but I've been encouraged to throw the project out there for more exposure, so here we are!
Telodendria is written in ANSI C, will use a custom flat-file database, and relies only on a POSIX system to be built and run. It won't pull in any dependencies; as much as possible will be written from scratch, including the HTTP stack, JSON parser, and any other baseline stuff a Matrix homeserver needs.
Why?
One of the goals is simply to build a useful homeserver, but also just to learn about the inner workings of Matrix and the technology that supports it, as well as to have a bit of fun in the process.
At this point we've got Synapse, Dendrite, Conduit, Construct, and a few other great projects. So you're probably asking, What practical reasons are there to build another homeserver? The best answer to that is in Telodendria's manual, but what it really comes down to is being portable and lightweight. It'd be cool to have a Matrix homeserver server that can run anywhere, but specifically targets the more obscure operating systems like the BSDs. Additionally, it should be light enough to perform well on Raspberry Pis, routers, cheap VPSs, and other low-power and low-storage devices that might not be as capable of running a full database plus a hefty Matrix homeserver.
For me personally, I just want a homeserver that feels like it belongs on OpenBSD and is capable of handling my use case without having to install any third-party packages. I'm a digital minimalist that wants to cut down on his software requirements, and Telodendria is one of the ways I've set out to do that.
Want to get involved?
There's definitely plenty of code and documentation to be written, so if you're looking for a challenge and believe in the project's philosophy, you're highly encouraged to get involved in whatever way you're able.
The development discussion happens entirely on Matrix. If you're unsure where to start, start by joining the project rooms listed in the manual. Do be sure to also check out main project website, which has a list of all the manual pages. The manual should contain much of the information you'll need to get started, but it's far from complete, so if you find the information to be insufficient, don't be afraid to ask questions in the rooms listed above.
Great news! The FUTO organization selected me for a grant to sponsor me working on Conduit. I want to finally work on the big remaining issues like threads, backfilling, spaces and so on. Also keep an eye on the Conduit v0.5 release. It is almost done and contains many bug fixes. You can already try it out by compiling conduit-next.
A lot of the Synapse team are out at the moment; we have mostly been in maintenance mode, both for the project and the Matrix.org deployment. With that said: we released Synapse 1.70.0 on Tuesday followed by a 1.70.1 patch release today. Highlights include:
Thank you as ever to our community of contributors, server operators and users who've been involved in this release. We'll be cutting a release candidate for Synapse 1.71 on the upcoming Tuesday (1st November), aiming to release the week after (8th November).
As for this week: we've been testing Synapse against the recent Python 3.11 release, dealing wit h CI deprecations and working through our backlog of old PRs. Lots of small things to juggle!
Since I happen to have a few free minutes this friday;
My Helm Charts continue to stay up-to-date, with element-web at 1.11.12 and matrix-synapse on 1.70.0 (though refer to #homeowners:matrix.org before updating)
I guess the most exciting news is that the macOS M1 builds are now merged to master and will be available for the next release. Seems like those are even faster on macOS that the intel builds! (Time from launch to be able to send a message is about 1 or 2 seconds.) The builds are using the generous cirrus CI open-source offering, so thank you!
Another good news is that a fox fixed the upload widget sometimes breaking Nheko when trying to upload specific files on some platforms. Apart from that there were also minor fixes to room sorting in communities, performance fixes to the parent community links as well as work on enabling more warnings when developing Nheko (to ensure our code is better quality, more secure and less error prone).
If you want to find out more about Nheko, our official community is currently being set up at #community:nheko.im!
Along with some bug fixes we’ve been adding more updates to some features currently in Labs!
Check out a newly improved Threads; with recent updates deployed, threads notifications should be much more reliable these days. We’ve still got more work to do but the improvements are great.
Video rooms and Element Call in the desktop version now supports screen sharing.
The rich text editor is also getting regular updates and expanded functionality.
In the pipeline for us over the next few weeks are improvements to notifications and matrix.to links.
In order to enhance our ability to test before launch we’ve now got Nightly builds on ElementX iOS. Our internal testers are able to use the app for longer before we prep for release to the App Store and that will increase the quality of our product.
We’ve also made other improvements to our performance testing.
The composer has had a few upgrades recently - keep your eyes open for that and let us know what you think!
Work on voice broadcasting is moving ahead quickly
We’re working on signing in via QR code and other enhancements in this area.
And last but not least, ElementX is very close to getting e2e encryption support!
The new app layout has been out for a few weeks now and we’re keeping an eye on feedback and numbers. So far it seems like most people like it though we’ve heard great ideas about improvements we can make in the future. Keep it coming!
We’re working hard on increasing the test coverage in our app so that we have even more confidence in the app we’re pushing to the Play Store.
Under Labs, there’s some new features. Check out:
The new composer. It’s What You See Is What You Get and hopefully a lot more straight-forward to use!
There’s also a new way to manage your devices and notifications on different clients.
I have updated nheko-krunner to work with the latest D-Bus API from nheko. There is no new release out yet, but expect to see a release (possibly with other cool things) after the next nheko release.
Happy Friday all! Once again we have a new build of the Circles Android app for your beta testing enjoyment.
Updates in this release (v1.0.5)
Renamed the app back to "Circles". Technically the proper name of the app is "FUTO Circles", but it will show up on your home screen as simply "Circles", similar to how Google Photos is "Photos" and Google Maps is "Maps". The Circuli name was too hard for most English speakers to pronounce, and it didn't solve our other issues with the name. "FUTO Circles" should do the trick.
We're keeping the Circuli name for our online service.
Added QR-code-based device verification.
Made registration tokens optional, i.e. it's up to the server whether to require them or not. Currently we do require registration tokens on our servers, and you can sign up with the token 0000-1111-2222-4444.
Long-awaited and with a bunch of final bug-fixes on the server side, this week eventually saw the merging of the sliding sync extensions, enabling e2ee and to-device message support via sliding-sync on main. With that, and some additional APIs on, a new Element-x with e2ee support was made available. A release that also features the latest work on the timeline API, which, too, has seen its fair share of progress this week - mainly internal fixes and debugging helpers.
As a result of the sliding sync work, just earlier today, an important PR was opened for jack-in, the experimental debugging TUI client based on matrix-rust-sdk (which we use for debugging sliding sync): now allowing you send (encrypted) messages, too.
Following last weeks announcement we also made the Rust-Sec public, indicating why we recommend upgrading to 0.6.1, which we released shortly prior.
Other than that, work has been progressed in the background on the pretty complex problem of async in uniffi and system-specific runners, namely libdispatch on ios rather than tokio, as well as work on uniff proc-macros.
️👉 Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at Matrix Rust SDK.
A new beta for libQuotient 0.7 is out, with a few fixes and improvements across the board but especially in E2EE-related code. This one is still a bit too early for Linux packagers but we're steadily approaching the release. The release notes are available at a usual place: https://github.com/quotient-im/libQuotient/releases/tag/0.7-beta2
Meet other matrix users, chat about Matrix, the rest, and everything else, discuss your Matrix ideas, sign each other in persona, and maybe spice the evening with a good mate or beer.
Also when the bbq is lit you may wish you brought your favorite item :)
Every first Wednesday of the month in the c-base at 8pm ('til the next pandemic).
Automattic look to be working on a wordpress plugin called Chatrix, forked from Element’s Chatterbox (in turn built on Hydrogen)… https://github.com/Automattic/chatrix-frontend
We published our example dashboard fullstack app at Github. It uses Matrix as one of the database options to save application's stored state -- and also contains sample configurations for multiple Matrix Home servers. The project is complete full stack sample project which can be used to kick start new projects. It has REST backend written in TypeScript using Spring Boot style API implementation, architecture copied from enterprise Java world to TypeScript. The frontend is implemented with ReactJS. It also has docker-compose configurations and a simple testing framework implemented.
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.
