Andrew Morgan (anoa) says
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.
- MSC3919: Matrix Message Format (IETF/MIMI)
- MSC3918: Matrix Message Transport (IETF/MIMI)
- MSC3917: Cryptographically Constrained Room Membership
- MSC3916: Authentication for media
- MSC3915: Owner power level
MSCs in Final Comment Period:
- MSC2821: Testing Pushers
- MSC3510: Let users kick/ban/demote each other
- Superseded by MSC3915: Owner power level
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.
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 🙂
The random MSC of the week is... MSC3032: Thoughts on updating presence!
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
Jordan Bancino says
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.
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.
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.
Conduit is a simple, fast and reliable chat server powered by Matrix
Timo on Conduit ⚡️ announces
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.
Synapse is a Matrix homeserver implementation developed by the matrix.org core team
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:
- better support for threads,
- full support for Matrix 1.3 and 1.4, and
- small fixes to the experimental faster joins work.
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;
And another little update on my Helm Charts; matrix-synapse 1.70.1 is now available as well
Desktop client for Matrix using Qt and C++17.
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!
Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!
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.
Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!
- 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!
Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!
- 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.
A KRunner plugin to list joined rooms and possibly other things from nheko.
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.
E2E encrypted social networking built on Matrix. Safe, private sharing for your friends, family, and community.
Happy Friday all! Once again we have a new build of the Circles Android app for your beta testing enjoyment.
- 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.
Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM
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 uprgading 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 wantedtagged issues and join our matrix channel at Matrix Rust SDK.
A Qt5 library to write cross-platform clients for Matrix
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
Next Matrix user meetup 2.11.2022, 8 pm @ c-base
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).
Matrix room: #mumb:c-base.org
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.
Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
See you next week, and be sure to stop by #twim:matrix.org with your updates!