Today the European Parliament, the European Council and the European Commission will meet again for a discussion about the Digital Markets Act (DMA). This is the second of three of these meetings, appropriately called trilogues, where each party exposes their stance on a proposed law and the group tries to agree on the final version.
The DMA is a groundbreaking step forward in shaking the hold a few gatekeepers have on users and the market, in particular because it looks to (among others):
Require gatekeepers to allow other services to interoperate with their services
Prevent them to treat their own services and products more favourably (for example by ranking)
Require them to allow users to uninstall any pre-installed software or app
The interoperability obligation is obviously the one on which we’ve kept a particularly close eye, as if it lands well it could take the success of Matrix to the next level completely overnight.
However, whilst in our mind interoperability automatically implies “open standard”, there are actually different ways of implementing it, depending on how far one wants to go. Typical debates here have been between whether to force gatekeepers to maintain open and well documented APIs, or whether to go full swing and mandate an open standard, and every shade in between.
We’ve been lucky to have had the opportunity to talk to policy advisors from different European member states, and it has been pretty fascinating to realise that it was always the same arguments which were being presented back at us, straight from the gatekeepers partyline.
We’ve ended up just listing them in a quick, high level, Myth Debunking exercise and thought it would be useful to actually publish them for everyone to access, so here they are!
MYTH #1 - "It is impossible to have a standard that is open, decentralized and secure at the same time"
⇒ false: HTTPS did it, Matrix did it.
**MYTH #3 - **"Interoperability is incompatible with end-to-end encryption"
⇒ false: services just have to speak the same language, email has proved this with S/MIME and PGP - where different vendors can and do interoperate with E2EE. It’s even better when the protocol is E2EE by default.
**MYTH #4 - **"It may work for messaging, but less so for social networks"
⇒ false: it's still about managing content and users. Even though social networks have more varied content, it is already well modelled for their own APIs, ready to be expressed in a common language. The key is in the fallback option on unsupported features, as well as the ability to have moderation tools (more on that later).
**MYTH #5 - **“Interoperability is not compatible with data privacy”
⇒ false: Interoperability gives the ability to users to choose who is hosting their data and as such choose providers they trust. Besides, the DMA doesn’t live in a vacuum: it will exist alongside horizontal regulations like the GDPR and the Data Act, which give people sufficient control over their data to rectify their choices if they are not happy. Because the possibility of interoperability is there, it does not mean it will become mandatory for users to use it: they will still have their own threat models and will make decisions accordingly, just as they do today. But enshrining interoperability in law will at least ensure gatekeepers need to provide recourse for people to have further control over their data, which will be an improvement from the landscape today.
**MYTH #6 - **"There is no user need"
⇒ false: most haven't had a taste of interoperable chat/social media (but they know email), others are demanding bridges between services: 25% users of 2 communication apps lose contact with friends because they are using too many apps. And this figure doubles for people using more than 5 apps. There was no demand for cars when they were created: people only wanted faster horses.
**MYTH #7 - **"There is no demand from European companies"
⇒ false: The fact it is so hard for European companies to remain competitive enough to stay alive means there are few of them to complain about what is killing them! However these companies are gathering to push for interoperability (like the Coalition for Competitive Digital Markets). It will enable them to be more innovative in the product they develop by benefiting from an existing open network rather than being slowed down by having to build one from scratch. Companies will compete on the value they add rather than the size of their network. An open standard also gives an open field for innovation from a business model perspective. The Web is an excellent example of how much an open network fuels innovation and growth.
**MYTH #8 - **"It is better to require providers to have open and stable APIs than define a single open standard"
⇒ false: this is the best way to leave gatekeepers at the center of the ecosystem as it means that each player has to multiply its effort to interface with every single other player, but every player will only have the resources to interface with a few of its counterparts and will logically default to the bigger ones, effectively not solving the problem. In addition, if providers are not aligned on which encryption to use it will just break end-to-end encryption and create risk for the user in every bridge. In practice the DMA is about forcing the gatekeepers to interoperate only, but we strongly believe that everyone should be interoperating if we are about improving the user’s experience and control, and giving more space to companies to innovate. Limiting it to the gatekeepers is a first step, but only a defensive one.
**MYTH #9 - **“An open standard limits innovation if it defines a lowest common denominator”
⇒ false: the lowest common denominator should match what users consider as table stakes in a messaging or social media app. Providers can innovate on top by providing different features which go beyond table stakes, for example by targeting niche use cases, like messaging services focused on elderly and disabled users, or focused on healthcare, warehouse workers, or integrated in a CRM for call centers, or creatives… Providers also can implement a profile of the standard which is a subset of its full scope, ensuring the standard remains a highest common denominator..
**MYTH #10 - **“It will be impossible to moderate social networks built on an open standard”
⇒ false: decentralised networks actually have driven the adoption of much more sophisticated moderation techniques than the coarse approaches of centralised silos. Appropriate moderation means have to be part of the open standard definition, and some are already used in Matrix. It would also empower victims who today have no choice but get in touch with providers one by one. Each provider will also have control over their own users, and users can select providers whose T&Cs are aligned with their ethics. The world is not black and white, unlike what Silicon Valley tries to make us believe.
**MYTH #11 - **“It will take years before being able to define an open standard”
⇒ you don’t have to: You could leverage existing technologies which are being used by the industry. Matrix, XMPP and ActivityPub exist today. For instance, Matrix has been managed by its own standard body (The Matrix Foundation) and could be ratified by a more established one like IETF, ETSI or W3C if needed.
Obviously the devil will be in the details of the way the final text is formulated, as well as the limits, obligations and controls put in place, but overall it should be an improvement for all European users and companies and we’re looking forward to seeing how today’s trilogue goes!
Welcome to the second installment of our quarterly spec releases. If it feels like it hasn’t been long since our last release, you’re not alone! Our last release was just 3 months ago, introducing the new platform and world we build within.
This improvement in speed might seem too fast, but fret not: implementations are not expected to update as soon as the new spec is published. Rather, it is more realistic to expect that the ecosystem gradually update over the course of the following few months/year. Particularly after the massive release that was v1.1.
So, what’s new in v1.2? With 18 MSCs merged there’s a lot to cover - we’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.
Rearchitecting with Spaces
Spaces launched into beta last May, redefining how we can use rooms on Matrix to represent different data structures. Described mostly as MSC1772, Spaces are simply rooms with a specific type in their m.room.create event. With state events being used to define which other rooms (meaning Spaces too) are part of that Space, the possibilities for tree-like structured data become endless.
There’s still quite a lot of work to do in the Spaces space (hah), though we’re excited to see it all land. For instance, MSC3216 and MSC2962 target power level syncing, MSC3219 aims for flair, and MSC3089 looks at file structures using Spaces. We might even be able to replace the public room directory with a server-wide space, making writing clients a little bit easier.
Public, but not too public, join rules
Restricted rooms are new in this release from MSC3083. In these rooms (and therefore Spaces too!), the join rules can be configured such that a member of another room can join without needing an invite. In a typical setup, this means that a Space could be set as invite-only, but all the rooms and Spaces underneath that Space could allow joins for members of the parent Space. When someone wishes to explore the universe you’ve laid out in your Space they can simply join the interesting rooms without having to ask for invites constantly.
This feature changes how membership events are authorized, so is only available in room versions 8 and 9 (both introduced in this release). Room version 9 fixes a relatively rare bug from version 8, so we’d recommend using v9 if you’re planning an upgrade for this functionality.
Further work in this area involves figuring out how to keep membership lists perfectly in sync between the rooms, which is currently done by external tooling. For example, evicting someone from the parent Space could (optionally) evict the user from all the subsequent rooms and Spaces too.
We also need to figure out how to support both knocking and restricted rooms at the same time (oops). MSC3613 and MSC3386 both tackle this problem in different ways and timescales.
Matrix: A URI
A massive shoutout goes to kitsune and the whole community for working on MSC2312, giving us a URI we can pass around outside of Matrix to bring us back in. The early work on this dates all the way back to 2014, the very beginning of Matrix’s development, and has since been marked Provisional by the IANA.
MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).
Client-Server API
Breaking Changes
The prev_content field is now returned inside the unsigned property of events, rather than at the top level, as per MSC3442. (#3524)
The aliases property from the chunks returned by /publicRooms, as per MSC2432. (#3624)
New Endpoints
Add the Space Hierarchy API (GET /_matrix/client/v1/rooms/{roomId}/hierarchy) as per MSC2946. (#3610)
Add /_matrix/client/v1/register/m.login.registration_token/validity as per MSC3231. (#3616)
Backwards Compatible Changes
Extend /_matrix/client/r0/login to accept a m.login.appservice, as per MSC2778. (#3324)
Explicitly mention RFC5870 in the definition of m.location events (#3492)
Add 403 M_FORBIDDEN error code to /profile/{userId} as per MSC3550. (#3530)
Clarify the description of the /sync API, including a fix to an ASCII art diagram. (#3543)
Clarify that base_url in client well_known may or may not include trailing slash. (#3562)
Clarify which signature to check when decrypting m.olm.v1.curve25519-aes-sha2 messages. (#3573)
Clarify what "Stripped State" is and what purpose it serves, as per MSC3173. (#3606)
Clarify how to interpret missing one-time key counts. (#3636)
Correct the schema for the responses for various API endpoints. (#3650)
Clarify that group mentions are no longer in the specification. (#3652)
Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
Fix the rendering of the responses for various API endpoints. (#3674)
Server-Server API
New Endpoints
Add the Space Hierarchy API (GET /_matrix/federation/v1/hierarchy/{roomId}) as per MSC2946. (#3610, #3660)
Fix various typos throughout the specification. (#3527)
Clarify that GET /_matrix/federation/v1/event_auth/{roomId}/{eventId} does not return the auth chain for the full state of the room. (#3583)
Fix the rendering of the responses for various API endpoints. (#3674)
Application Service API
Spec Clarifications
Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
Fix the rendering of the responses for various API endpoints. (#3674)
Correct the documentation for the response value for GET /_matrix/app/v1/thirdparty/protocol/{protocol}. (#3675)
Identity Service API
Backwards Compatible Changes
Add the room_type to stored invites as per MSC3288. (#3610)
Spec Clarifications
Fix the rendering of the responses for various API endpoints. (#3674)
Push Gateway API
Spec Clarifications
Fix the rendering of the responses for various API endpoints. (#3674)
Element Desktop 1.9.6 and earlier depend on a vulnerable version of Electron, leading to a High severity vulnerability in Element Desktop, relating to its functionality for opening downloaded files. If successfully exploited, the vulnerability allows an attacker to open an arbitrary file path on the user's machine using the platform's standard mechanisms, but without the ability to pass additional arguments or data to the program being executed.
However in certain platform configurations, the same vulnerability could allow an attacker to open an arbitrary URL with an arbitrary scheme instead of a file path, again using the platform's standard mechanisms. There has been research demonstrating that the ability to open arbitrary URLs can sometimes lead to arbitrary code execution.
The attack requires user interaction and the exploit is complex. To the best of our knowledge, the vulnerability has never been exploited in the wild.
Patched in 1.9.7 with further hardening done in 1.9.9 to ensure it's harder to exploit even in light of new Electron vulnerabilities. Please upgrade to 1.9.9 as soon as possible. The vulnerability has been assigned CVE-2022-23597.
Kudos to Aaron for adding a GitHub action to matrix.org's repository to check for typos, and taking the time to fix them all! Worry not fellow proofreaders, our post-publication TWIM proofreading tradition is not extinct: some typos are not caught by the CI, such as misspelling of proper nouns (e.g. Devianart) or articles (e.g. "an proofreader" won't make the CI upset)
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.
The release of Matrix v1.2 is right around the corner, and is expected to go out on February 2nd. This is in line with our quarterly release cycle for the spec going forwards.
Please reach out to us in #sct-office:matrix.org if there are any last-minute MSCs that haven't started/finished Final Comment Period that you believe should be included!
A concept similar to robots.txt for the web, but for Matrix! Currently the way to inform room-crawling bots in Matrix today is by banning/kicking them from the room. However, this doesn't allow you to blanket prevent bots from joining - nor does it only inform bots that they should access some of the room's data. It's a binary switch.
Consider if you wanted your room to be crawled, but the room topic to not be indexed. This MSC could help with that! Give it a read/review if you're interested.
Have you ever pinged someone by accident, because you replied to a message with their name in it or maybe even a whole room mention? Or are you avoiding replies for that reason? Did the quote of a messages suddenly vanish when someone edited their message in a client? Or are you just in general unhappy with replies only showing what type of message was replied to, instead of showing the actual image being replied to (on mobile for example)? Were you annoyed, that you could only reply with a text message, but not an emote message, an image, a sticker or even a video?
I spent a bunch of time trying to remove the blocker for that in the Matrix specification, you can find the proposal here: https://github.com/matrix-org/matrix-doc/pull/2781
As it turns out, it is not quite as simple, because notifications for replies to your messages rely on a bunch of implicit interactions, which is why I also wrote another MSC to fix that: https://github.com/matrix-org/matrix-doc/pull/3664
I'm a bit unhappy with replies across the matrix ecosystem at the moment and I hope this is a small step towards improving things. It's certainly not as exciting as spaces, voip, threads or stickers, but it is something which affects me every day and I think those small papercuts need some attention too.
I hope some of you share my love for the less exciting stuff!
To add onto Nico's efforts, I think that mentions today are based on too many "false-positives" (ping on displayname or username mention), and i kinda wish for the "just mention them" UX of discord, telegram, whatsapp, and so many other messengers.
So I've also made a proposal that tries to bring some explicitness in that, a new push rule that'll fire on "mention"; https://github.com/matrix-org/matrix-doc/pull/3517
It'll look for any @-MXID mention in the plaintext, or look for an <a>-mention "pill" in the HTML. It is a hack, but it is the most correct way of determining if you've been pinged in matrix, at the moment.
In terms of reply fallbacks - the Spec Core Team gave an overwhelming thumbs up to removing reply fallbacks via MSC2781... but given practically this causes a cascade of other work (defining and implementing push_rules for replies, and defining and implementing push_rules for threads (MSC TBD)) and so as a temporary transitional measure we've instead made reply fallbacks best effort (MSC3676). This means that clients can now reply using non-textual events, and we can use replies as a fallback for threads for non-thread-capable-clients/ASes once MSC3440 lands. To be clear, the intention is still to incorporate all of Nico's excellent contributions on MSC2781 and MSC3664 however.
Hello TWIM! Last week we released Synapse 1.51. This is a great release which includes lots of performance work around sending aggregations down /sync. It also makes Spaces much more reliable: we tracked down a bug with caching which could cause some sub-spaces to randomly appear empty when queried over federation. We also removed the 50 result limit when listing the contents of a Space.
We're also starting to see some promising results experimenting with ways to make room joins faster (MSC2775). It's not quite ready to demo, but we should have something to show off before too long. 🤞
We know that it has been a while coming but today we have released Dendrite 0.6! This version contains a number of significant changes, including switching away from Kafka to NATS JetStream and refactoring a number of other components. We have been making architectural changes recently to help Dendrite scale better in the future and to fix a number of race conditions that were present before. Federation in particular is much smoother and better behaved in this release, with overall lower CPU and memory usage and less resource spikes.
NATS JetStream support, deprecating Kafka and Naffka
The roomserver now being responsible for fetching missing events and state instead of the federation API, which fixes some race conditions
Strict ordering and asynchronous input support in the roomserver input API, which smooths out incoming federation significantly
Consolidated federation API, including functionality from the now-deprecated federation sender and signing key server components
Database-backed device list synchronisation, which is now more reliable
Correct gap checking when fetching missing events and state
Better behaviour and lower resource usage by the /event_auth endpoint
Spec compliance, as measured by Sytest, currently sits at:
Client-server APIs: 65%
Server-server APIs: 94%
This is a highly recommended update so if you are running a Dendrite server, please upgrade! As always, you can join us in #dendrite:matrix.org for Dendrite discussion and announcements.
Hey folks, no releases this week but a general update on a little project of ours. I've been working through the problem of making bridges easier to use and supplimenting our command interfaces with pretty buttons and forms. To that effect, we've landed out first PR on adding widget communication support to the matrix-appservice-bridge library \o/.
You can see some of the details here https://github.com/matrix-org/matrix-appservice-bridge/pull/365
but that's not all. I'm doing a talk about this whole subject at FOSDEM which you can tune into! See the deets at https://fosdem.org/2022/schedule/event/matrix_next_gen_interfaces/
Next to spec work, progress on porting Nheko to 100% qml continues. This week I ported the login and registration pages. I also did some minor cleanups on them and prep work for future improvements (like buttons for each SSO provider or providing email address and registration token inline instead of in a separate popup, if the server requires it). Logging in or registering is often the first thing a user does on a client or maybe even the first thing they do on Matrix! As such I should really spend more effort optimizing that feature, that usually falls off the priority list because I don't use it often!
Once Nheko is 100% Qml we should also see lower memory usage again, here is a screenshot from a Nheko instance with over 100 rooms, that's been running for a few days of active use on Windows:
We also fixed an issue where Nheko could crash the notification service, because it sent images not following the Freedesktop notification specification and tasty spent some time further improving the man page.
Hello folks, it's been a while since we last spoke! We have been focused on the code, but we're long overdue for an update. A lot has happened since November. Fractal-Next is getting closer to feature parity with current Fractal, and even supports new things:
Timeline
Fractal-Next now allows you to open and save sent files
It also displays images, videos and stickers in the timeline
You can also get a better view of media send to the room thanks to the built-in media viewer
It (finally!) supports reactions (displaying them and sending new ones)
User verification
Fractal-Next now supports verification of other users by scanning their QR code, or via emoji
When a user is verified, an icon is displayed next to their username in the list of room members
Room details
The room details show now the members of the room including the power level
General UX
Fractal-Next is better integrated with GNOME's secret management service Seahorse
It supports room upgrades
It also supports inviting users to a room
Users can change the category of rooms in the sidebar via drag and drop or by using the context menu
Release candidate was late as we have more regressions and release blockers than normal: last minute fixes include a couple of crashes when hanging up a call from the picture-in-picture view and in the appearance tab of settings, plus chasing a crashing bug on Linux.
Metaspaces has landed in the release candidate: it will give you a new way to group your favourites, DMs and rooms outside of spaces. You can switch these on in the Quick Settings menu at the bottom left from Monday.
Bubble layout for messages has landed for the upcoming release!
This release will update to Electron 15 which uses a newer Chromium, so if you host your own Jitsi, please make sure it’s up to date, or you may find calls start breaking.
Nightly testing went well on Tuesday, with 47 test cases showing up 15 new issues
In labs (you can enable labs in settings on develop.element.io or on Nightly)
New thread fallback using the reply chain
Better stability when home server supports threads API defined in MSC3440
We are intending to add the new and improved search to the next release candidate on 8th Feb, community testing planned for next week
Add support for room message search in unencrypted rooms
Support options for Room visibility and Room addresses
Manage room permissions
Enable encryption and manage room history visibility
Custom emoji
Show user and room emoji in auto-complete cmd and emojiboard
Show custom emojis in reactions
Use jumbo emojis for emoji only messages
Add toggle to use browser's preferred theme
Show placeholder profile picture when it fails to load
Show ban, kick, unban options in profile viewer
Ability to change power level in profile viewer
Bugs
Fix loading all twemoji on startup
Fix wrong read receipt count in encrypted rooms
Reset scroll when switching Home/DM
Fix gap under typing indicator in some device
Fix username overflow in timeline change messages
Fix message formatting
Find more about Cinny at https://cinny.in/
Join our channel at: https://matrix.to/#/#cinny:matrix.org
Github: https://github.com/ajbura/cinny
Twitter: https://twitter.com/@cinnyapp
Matrix highlight got experimental support for Firefox! It's still a bit crashy, but it shouldn't be much harder to stabilize it, and get the tool working properly there, too. Firefox is my personal browser of choice, and others have requested it, so it's nice that it's on the horizon :)
Also, after the discussion in Matrix Live and with some minor tweaks, I was able to get the extension to play nice with conduit! So that's now a viable alternative if you want to use Matrix Highlight with your own, self-hosted server.
Circles is a project to build a secure, end-to-end encrypted social network using Matrix technology.
This week the primary focus was on updating Circles to work with the latest Matrix iOS SDK. I also successfully built and packaged the first beta release from an Apple M1 Mac.
The next step is to develop and integrate a new, more secure password-based login based on the BS-SPEKE protocol. This will replace Circles' current approach, which is described in MSC3265. Hopefully the new login flow will also be of interest to the broader Matrix community.
Our search continues for an Android developer to help us bring Circles to the world's largest mobile device platform. If you are excited about working with Matrix, Android Studio, and Jetpack Compose, send a resume and cover letter to [email protected].
Trixnity version 1.1.0 has been released! It adds support for room key backup, which makes developing a matrix client a lot more comfortable.
Here is the changelog:
Added key backup support!
RoomService::getAll() returns a reactive list of reactive rooms instead of a reactive list of rooms. This allows to implement huge room lists without performance losses in the UI.
Some reactive data can be accessed in a non reactive way. Note that you will then only get a snapshot of the data.
Prevent sending room keys as to device messages, when they cannot be encrypted (e.g. due to missing one time keys).
Hello again! Halcyon is a python Matrix bot library created with the intention of being easy to install and use.
With this release, we have reached our second release milestone! Check out the roadmap in notes.md (located in the repository), for what is planned for RC3!
I'm really happy about the performance and functionality gains for this release. If you have any questions or bug reports, come and chat with us over in https://matrix.to/#/#halcyon:blackline.xyz
More info at on the project at https://github.com/WesR/Halcyon
Added
Detailed room info is here! The bot will now cache and provide room info with each message, automatically refreshing in the background. Check out usage.md for info on what is provided
get room admin / moderators, topic, related groups and more
Better polling through long polling (Thanks @forden:matrix.org for pointing out this improvement)
send images with the new send_image() function. It includes simple toggles for blurhash and thumbnail generation
More examples in /examples
General roadmap and documentation updates
Fixed
A fix for the slow polling, which might have also caused issues on systems with frequent network drops (Thanks @octt:matrix.org)
Bubo is a friendly little owl (bot) that helps maintain your community. It's been over a year since cutting the last release, so the changelog contains a bunch of things, namely:
Added command to set power levels in rooms.
Added users command to list and create users in a configured Keycloak. Optionally send invites via keycloak-signup, a web app that allows self-registering with Keycloak via short lived tokens.
Add logging to a Matrix room.
Bubo admins and coordinators can now be set based on room memberships.
Add command to make Bubo unlink and part itself from a room.
Add command to list rooms Bubo maintains but is not admin in.
Add command to recreate a room. This follows the upgrade room functionality, but does it without needing admin permissions (basically almost everything except a tombstone event). Useful if for example you have accidentally lost admin in a hundred or so rooms in your community. Which may have happened 😅
The communities command is now deprecated (support for spaces coming in the next version).
Additionally some other changes and fixes, see changelog for full details.
Plans for next up features include syncing with Discourse to replicate spaces from Discourse groups and populate space members from Discourse group memberships (when Discourse shares the same Keycloak SSO provider with the homeserver).
Reaching another feature Milestone – Submitting images via Matrix Art.
Matrix Art now supports logging in with any account (well-known not supported yet. You need to provide the full server address) and submitting images through the interface.
You can now either just log in (No benefit though at this time as comments and follows are missing) or create a Matrix Art Profile.
An Account can also be created later. An Account would create a Profile room at #<mxid> on your server if it doesn't exist.
This currently is only possible by doing a logout and login in again with the box checked. A better way will be added soon.
Editing the Profile is not yet implemented at this time.
These 2 changes should allow some people to experiment with this. Mobile design is not tested at this time.
Submits should work. If you were previously logged in, you will need to log out and back in for some variables to get set correctly.
Registration is still WIP as there is some more moderation prep needed before the server accepts the registrations.
I hope people cheer in and post their images :)
(Also, please use the nsfw flag if required. This will make them hidden on the front page but shown in your profile page. I will block people that don't use it from the instance otherwise. Please be sensible.)
Other Changes
Form readability increased
Search engine getting filled in the background (Self hosted https://meilisearch.com instance gets used) when submitting
Loading indicator gets correctly positioned
Images without thumbnails or html caption don't break anymore
Directory Database was switched to SQLite
Roboto font was replaced with Inter font
Directory Endpoint got secured using the OpenID module in Matrix
"Devianart" typo got replaced with correct "Deviantart"
Logout state management got improved
Project Information
For more information, feel free to take a look at https://github.com/MTRNord/matrix-art
Or join our room: #matrix-art:nordgedanken.dev
Apparently, a German school forked FluffyChat and is using it for homeschooling: https://www.golem.de/news/matrix-grundschule-forkt-messenger-2201-162562.html
(German only news article)
Sources: https://gitlab.com/hermanncoders/hermannpost
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.
Synapse 1.51 is out! Here's what's new with this week's release.
Deprecation of the webclient listener
A long time ago, Synapse used to serve a very basic web Matrix client (named "console") that could be used to connect to the homeserver. Server administrators could chose to make it available to their users by configuring a webclient listener.
This web client was removed in Synapse 0.34 back in 2018, but the webclient listener stayed, instead allowing server admins to serve the web client of their choice (or redirect to it) through the web_client_location configuration file.
Synapse 1.53 will remove the webclient listener, as well as the ability to set web_client_location to a static directory (instead of a HTTP(S) URL). See the upgrade notes for more information.
Aggregations and sync
The concept of server-side aggregation in Matrix is defined in MSC2675 and is the ability for homeservers to extend the information included in an event using other events that relate to it. This allows, for example, clients to quickly retrieve the reactions associated with a given message, or its latest edit.
This release includes a number of notable performance improvements to calculating aggregations when responding to /sync requests. We continue to measure and investigate potential performance improvements in this area, which should end up greatly benefiting /sync response times.
FOSDEM
FOSDEM, one of the biggest gatherings around free and open-source software in the world, is happening next week! Just like last year, the conference will happen online and will be hosted on Matrix. And just like last year, it will be packed with super interesting Matrix-related (but not only) talks.
One new addition this year is the presence of a whole devroom dedicated to Matrix. It will be hosted on February 6th, and you can already find its whole schedule of talks right here.
This release includes a couple of spaces-related bug fixes, specifically related to the /_matrix/client/v1/room/{roomId}/hierarchy API. One of them in particular targets a bug in spaces that include more than 50 rooms, and should make it much easier to look for a specific room inside a space.
The synapse_review_recent_signups script, which allows homeserver administrators to review recent signups (e.g. in the event of a spam attack), was also improved with an option to exclude virtual users belonging to an application service from the results. See synapse_review_recent_signups --help for more information.
Please see the Synapse release notes for a complete list of changes in this release.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Dirk Klimpel, br4nnigan, Philippe Daouadi, Daniël Sonck and AndrewFerr.
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/unstable/proposals.
Work on preparing the release of Matrix v1.2 is currently underway. As of today, the Spec Core Team is aiming for a release of Matrix v1.2 on February 2nd.
If you know of any MSCs which you believe should be included in Matrix v1.2, but haven't started/finished Final Comment Period yet, please bring them up in the #sct-office:matrix.org, and we'll take a look. Thanks!
When I first came across this MSC, I didn't know what "Early Media" as a concept referred to. Even after skimming the MSC... I still didn't really know. But I'll demystify it here in case it peaks your interest and you would like to learn more.
Early media is essentially any media that is exchanged between the moment you start a call, to the moment the other side picks up (a connection is established). For instance, the ringing you hear while waiting for someone to pick up (called "ringback tones"), or the "busy" tone you hear when the line is busy. Those audio bits are known as "early media". Video can also fall into this category (though that's less common).
This MSC would essentially allow Matrix to introduce these concepts in Matrix-only calls (though these days the client just plays sounds while connecting), but more crucially would allow Matrix to interoperate with other protocols (like SIP) that expect to handle these features.
So yay, more interoperability and bridge compatibility!
After a somewhat bumpy process, we released Synapse 1.50 on Tuesday! The big thing you need to be aware of is that we're turning off support for Python 3.6 and PostgreSQL 9.6, including Linux distributions which ship with those versions by default (like Ubuntu 18.04 LTS). Please make sure your infrastructure is up-to-date.
I'm personally very excited that we tracked down a bug which could cause device list updates to get lost when being sent over federation. When device lists fall out of sync, it can cause failures when attempting to decrypt messages, since the keys may not have been sent to all of the user's devices.
We've also made quite a lot of progress in allowing Application Services to support end-to-end encryption via the still-experimental MSC3202.
For MSCs which have been merged into the Matrix Spec, we now implement MSC3419, allowing guests to send state events into rooms, and we now use stable identifiers for cross-signing and fallback keys per MSC1756 and MSC2732.
Looking to the future: We're aiming to release 1.51 next week so it has plenty of time to burn in before we host FOSDEM 2022. This is a pretty quick turnaround from 1.50, but we'll return to our usual fortnightly release cadence for subsequent releases. To that end, 1.51.0rc1 is out today; give it a shot. 😉
Hello again! In the last week we continued to optimize the rocksdb backend and Conduit in general, trying to get it as memory efficient as possible. Using valgrind we could see that memory was not getting released in some cases.
We found out that switching to the jemalloc allocator completely got rid of this problem and memory usage seems to be a lot more stable now!
All of this is currently available on the next branch. We are preparing to make a v0.3.0 release soon!
And back to regular form, my Helm Charts have gotten some upgrades again; element-web got upgraded to 1.9.9, and matrix-synapse got both 1.50.0 and 1.50.1 (the configuration generated by the chart shouldn't be affected by the .0 bug, but always good to upgrade)
To keep your timeline clean and ordered we’ll soon be introducing threaded messages to Element. Currently the team is working hard on the fallback solution, and polishing up the user interface.
Threads is already in Labs on Web, so go ahead and check it out!
For mobile, we’re hoping to release Threads to Labs in the next few weeks.
Polls
Get ready to start asking more questions… Polls are nearly ready to go! You’ll be able to ask folks things like; their favourite superhero, which day you should grab lunch, or even the best way to make tea (milk first, always). ☕️
If you just can’t wait ‘til we’re ready to launch, you can enable Polls from Labs.
Location Sharing
Location sharing is almost here! You’ll soon find a new setting to turn this on, which will give you the location sharing icon in your composer and can be used to tell people exactly where you are!
The setting will be in the next release on iOS and Android, and will start “off” by default. Once the feature is settled in, we’ll turn it on by default.
We’re moving forwards with our PostHog Analytics implementation and are super excited to start to get to know how our users experience Element. Remember; it’s off by default and you have to opt-in to share.
In labs (you can enable labs in settings on develop.element.io or on Nightly)
With the coolest project name by far, the Bubbles team is working hard to bring you message bubbles ASAP! These should land in the next week or so but are available in Labs today.
The integration of analytics tracking has been included in the most recent version of the app. Using PostHog Analytics we’ll be able to make informed product decisions for our app as we’ll have more visibility into the usefulness of each feature.
Remember; Analytics is opt-in and you don’t have to share any info with us. If you choose to opt-in we’ll start to learn how users use Element and how we can simplify your experiences.
We’ve had some trouble with the stability of our releases this week but the team’s been working hard to get it all ironed out. Our latest update to the app store fixes some bugs and includes the option to enable analytics.
Analytics? Yes! Knowing how our users traverse our app, and understanding this cross-platform, will help us to tailor to your needs and make impactful improvements. If you don’t want to send anonymised event info to Element, no problem! Just say no. If you change your mind, there’s a toggle in Settings.
In development:
Message Bubbles? Yes, please! With a week of successful testing internally we’re nearly ready to release message bubbles into the wild. We’re excited to see what you think.
Element’s first time user experience could use a little help, so the team have been working on improvements to our sign up flow that will hopefully reduce confusion for newbies.
Next up: Bulk editing of rooms for updating room power levels or aliases in masses.
If you're a maintainer of a homeserver, space or bridge, please let me know your use cases.
It's a small cli tool that does exactly what it says - exports matrix messages from a room. As example you can check etke.cc/news - that page and all items on it generated by emm from #news:etke.cc room.
The tool gracefully supports room aliases, message edits, custom templates (check the contrib/ dir for example) and 2 export modes - single (all messages exported to a single file) or multi (each message exported to separate file, that's how etke.cc/news works)
Circles is a project to build a privacy-respecting, end-to-end encrypted social network on top of Matrix. It was originally built out of the desire for a safer way to share baby photos with friends and family, but it can be used by anyone who wants easy sharing combined with strong security.
Recent news:
The Circles iOS app is back in beta on TestFlight. Builds 0.99 (6) and 0.99 (8) are rolling out now.
The latest updates fix some bugs in Circles' use of Matrix's encrypted recovery feature to improve the reliability of E2E encryption.
FUTO, the new company behind Circles, is hiring an Android developer to help us bring Circles to Android. Interested candidates should send a resume and cover letter to [email protected].
The (old) Circles homepage: https://kombuchaprivacy.com/circles
The code on Github: https://github.com/KombuchaPrivacy/circles-ios
long time no see! Today I come with a new internal etke.cc tool that publicly available, because open source matters.
Honoroit is a helpdesk matrix bot with end-to-end encryption support, that utilizes MSC3440 (Threading) to act as a proxy between a customer (any matrix user) and your backoffice (users added in special room), each customer's room = thread in a backoffice room, where multiple operators can send messages to the same customer at once.
Pretty bad description, I know - check the source code to see screenshots.
Updates:
the v0.9.2 release brings the fallback reply-to mode, so even on matrix clients that doesn't support threads yet you can use it with good ol' replies.
the v0.9.3 release fixes commands parsing in the reply-to mode and adds prefixes to the thread topics
Matrix Art received some minor changes since the last twim post:
You can now get a rss feed of the posts at https://art.midnightthoughts.space/posts.rss (This is in the same format as devianart does their feeds)
Mobile should be mostly fixed
The About-info isn't hardcoded anymore but now uses an event type.
The page now uses the Roboto Font instead of the default font, which helps with readability.
Matrix Art cmes with a basic Text Logo now
Links to the profile page are now easier to notice
Blurhashes are now supported for images
The repo now has the Apache-2 License applied
Dependencies have been pinned
Various small design improvements were made
Images now have size hints so the page doesnt jump around as much when loading
Lots and lots of metadata was added to each page for SEO
Check it out at https://art.midnightthoughts.space
Check the Code out at https://github.com/MTRNord/matrix-art
Or join the Chat at #matrix-art:nordgedanken.dev
Planned for this week is to add registration and usage of external profiles. As soon as that works I am also going to make uploading images work. So with a bit of luck in the next TWIM anyone is able to post their images :)
Hi TWIM. I published a long-planned, long-in-the-making, long-winded report of how I containerised my matrix-synapse homeserver and its PostgreSQL database in order to get ahead of the application dependency deprecations. This was something I couldn't find for myself, so I put this together to help anyone else who might need it. (And it does contain a TL;DR section!)
I’ve created [blog post|(https://helderferreira.io/matrix-well-known-with-cloudflare/) explaining the way to host the static well-known files using cloudflare workers gaining speed and stability
During the holidays I recorded a podcast about Matrix and Element with AnDaolVras/La Cantine Brestoise, which is a French non-profit organising tech events and operating a coworking space in Brest, France. The episode (in French, sorry!) came out on Monday and can be found on their website, on YouTube as well as on most podcast platforms 🙂
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.
Welcome all for the first Synapse release of 2022: Synapse 1.50!
Note that, as per our platform dependency deprecation policy, Synapse no longer supports Python 3.6 and PostgreSQL 9.6 as of this version. As a result, we have also stopped shipping Debian packages for Ubuntu 18.04 LTS (Bionic Beaver), as it ships with Python 3.6.
As a reminder, please note that Ubuntu 21.04 (Hirsute Hippo) reaches its own end of life on January 20, 2022. Past this date we will stop producing new packages for Ubuntu 21.04.
Encrypted application services
Application services (sometimes called "appservices"), are privileged processes that can interact with a Matrix homeserver in a way a normal user cannot. This is especially useful for bridges, as it allows them to register and puppet multiple users on the homeserver to replicate activity from other platforms.
One of the main shortcomings of application services currently is that they do not support end-to-end encryption. This means that messages sent through a bridge are never encrypted and always visible by the homeserver.
We've recently started work to tackle this issue in the form of MSC3202. A first part of implementing this MSC (allowing application services to masquerade as specific devices) has landed in this release of Synapse; work is still ongoing towards a full implementation, so watch this space!
Improved reliability on device list updates
While working on this release, we identified a long-standing bug that could prevent Synapse from sending device lists update over federation if the server had a high number of active users and/or users with a lot of devices connected to their account.
This bug was introduced back in Synapse 1.0.0, and meant that the homeserver would miss some device list updates when communicating with other homeservers if the amount of updates to send was too high. In practice, this means users on remote homeservers could see outdated device information for other users (including outdated device verification statuses).
Synapse 1.50 includes a fix to this bug. This should contribute towards making the propagation of device list updates more reliable.
Everything else
This release introduces support for MSC3419, which allows guest users to send arbitrary state events into a room. This will be especially useful to the ongoing work on group VoIP calls, which involves having users send new state events into the room to signal their participation in a call.
We've also stabilised identifiers for cross-signing and fallback keys now that MSC1756 and MSC2732 have been merged into the Matrix spec.
On the documentation side of things, the page on setting up and configuring a TURN server has been updated to feature instructions on how to deal with NATs. This is a much welcome addition as configuring TURN is something a lot of Synapse admins struggle with!
Please see the Synapse release notes for a complete list of changes in this release.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including Dirk Klimpel, Donny Johnson and AndrewFerr.
Note: An issue preventing client logins (#11763) was identified immediately following the release of Synapse 1.50.0. We released Synapse 1.50.1 the same day with a fix for this issue.
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/unstable/proposals.
Hot on the heels (relatively speaking) of v1.1 of the Spec being released in November, v1.2 is now on the horizon! As a reminder, we're working towards quarterly releases of the spec going forwards - no hard dates yet though.
While this is certainly an improvement in speed, when it comes to writing software and updating implementations: quarterly spec updates may actually seem too fast. This is OK; implementations of the spec are not expected to update as soon as a new spec release is published. Rather, it is more realistic to expect that the ecosystem updates gradually over the course of the next few months/year after the release.
Happy Friday everyone! Today the Synapse team has released Synapse 1.50.0rc2. It fixes a particularly nasty federation-breaking regression that crept in during 1.50.0rc1. If you're currently running 1.50.0rc1, we implore you to update to 1.50.0rc2 as soon as possible!
In other news, a reminder that as of Synapse 1.50.0rc1, we have ended support for Python 3.6 and PostgreSQL 9.6 as per our dependency deprecation policy, as upstream has marked them as end-of-life.
We'll let the community test 1.50.0rc2 over the weekend to ensure that no other regressions have emerged (please test if you can)! If not, expect Synapse 1.50 to land sometime early next week.
Support CHGHOST caps (prevents leave+join on host change) ✅
Fix owner auto-registration (regression) 🐛
Upgrade to Mautrix 0.14 ⬆️
Sending RELAYMSGs have been requested for a while so now we do support that if the cap is added to request list. This makes plumbs on networks that support it work nicer. Receiving RELAYMSGs has not been implemented yet so they show up as external like before.
If you prefer keeping your IRC rooms clean without any IRC noise (mode changes etc.) you can now use a new FORWARD command in the network room to make all such events happen in the network room instead. This affects in-room commands as well.
ZNC users can now enjoy messages coming from your own clone in IRC rooms (including PMs!) if you wish so by keeping the znc.in/self-message cap enabled. This isn't extremely well tested yet but feedback welcome.
Not a breaking change but the caps support will cause connections to networks that ignore CAP requests take a few seconds longer unless you remove all the default caps for said network and it will never try requesting them again.
Mautrix 0.14 upgrade bumps the minimum version as well so packages beware.
We rewrote the whole settings page (as a stepping stone to 100% QML). Please test it and complain about everything I broke! We also tried to organize it a bit better so that similar settings are grouped together and tried to use the right controls for the right things. Best case you didn't notice anything. ;-)
And we also now show which profile a notification is for on KDE. I don't think other DEs have such a feature, so those will just show the generic Nheko as always.
We're about to release 0.2.23 after somewhat of a release hiatus. We've been working on two fronts:
Get the SDK out! Hydrogen was always meant to be easy to embedded, reuse in parts, and make customized versions of. But until now, actually doing that was quite challenging. Now that the SDK is out, you can use the hydrogen-view-sdk package in your projects and use parts of Hydrogen in your application. It's still early days, and we're still working out what symbols should be exported (finding a balance between APIs we want to support and utility), etc. Expect updates in the coming weeks. We're also not yet promising API stability for now, some APIs will very likely still change. Once we hit 1.0, we won't change things from underneath you anymore without increasing the major version.
Rich reply previews: as part of providing minimal support for threads (representing them as replies), we're switching from using the embedded reply fallback and actually looking up the replied-to message. One benefit is that reply previews will now updated when they are redacted (and edited, once we support that :).
Also fix some minor other things, like loading images when they are only partially visible, and a very basic location tile.
Issue with thread panel rendering timeline has been fixed
Reviewing plans for backward compatibility with clients that don’t support threaded messages
Polls
iOS and Android starting on the next phase of development, look out for poll editing and other exciting changes! You can enable polls in the Settings, under Labs.
You can now opt in to sending anonymous analytics data in the user settings on all platforms. Please enable it in the “Security & Privacy” menu, under “Analytics” to help us understand better how Element apps are used.
Mobile app users will see an opt-in screen on first startup on Android in 1.3.14 and iOS in 1.6.12
Maximised widgets merged into the release candidate and on track for the next release (see the Beyond Chat section for more info on this feature)
Fix code blocks being wrongly wrapped causing the line numbers to misalign, this was a regression in 1.9.8
Fixed ability to edit horizontal rules in markdown
Fixed some edge cases around Spaces not updating properly causing rooms to show up in the wrong Space
Add ability to cancel an outbound message during its encryption phase
Fix wrongly sending typing indicator when restoring a draft when changing room
Replace kick terminology with remove to be more inclusive
In labs (you can enable labs in Settings on develop.element.io or on Nightly)
Polishing bubbles layout
Upgrade to Electron 16 for Element Nightly - we are expecting this to help resolve some of the issues caused by Electron. Intending to release to production in 1.9.10 (two weeks away)
The maximised widgets feature in Element Web that Timo K. has been working on is now available for everyone on develop, and it's on track for the next web release. 🚀 It's a great match for widget-based collaborative editors, dashboards, games, and more. The widget becomes the focus of the room. You can optionally show chat from the room in a side panel, allowing easy discussion of the document / dashboard / game.
To try it out, add a widget to a room in the usual way, then look for the new "maximise" button in the room info panel's widget section. Please let us know in #beyond-chat:matrix.org or in issues if you have any feedback. 😄
Beeper is a universal chat app built on top of Matrix. We've created 12+ open source Matrix bridges and integrated them into an easy to use all-in-one service which does not require setting up your own homeserver. You can learn more at beeper.com.
Our team is growing! We’re now at 25 people, all remote around the world. Recent additions include hifi (creator of Heisenbridge) and Finn (creator of signald).
We are hiring many full-time remote roles including:
Bridge developers
iOS engineers
Product designers
Learn more here and apply through that site, or message @eric:beeper.com
Beeper Desktop
We recently released a Beeper Desktop update with a new room list and a ton of UI improvements. Check out the video below!
Made it easier to triage your inbox by moving unread dots to left
Made the list of connected bridges more compact
New link previews
Loads of bug fixes including improvements to scrolling
Most importantly, we launched a cloud Mac service that allows you to use iMessage with Beeper if you do not have access to an always-on Mac computer. Included with your Beeper subscription!
Voice messages are bridged in native format in both directions for all Beeper bridges
Signal bridge now supports disappearing messages
All Instagram message types are now bridged
Added support for Telegram message reactions
WhatsApp bridge now backfills 3 months worth of chats
Beeper Android
Coming soon: A recent addition to our Android team has added encrypted search by massaging seshat into the app. Expect an upstream PR for this into Element Android as well!
Trixnity version 1.0.0 is out! I decided to make it 1.0.0 not because it is out of beta, but because it has most features you need to build a usable client.
That means: cross signing has landed into Trixnity! The next big features will be room key backup and push notification.
Here is the changelog:
fully support cross signing
load members of rooms in an async way (you don't need to catch errors anymore)
reactive displayname and avatar url of the logged-in user
reactive avatar url for rooms
reactive is-direct-room state for rooms
better Android support for thumbnails
make part of device keys API public
merge SecureStore into Store (encrypt your database if you want to keep secrets secure)
move trixnity-client-api model-classes into separate module to use them e.g. for a matrix server implementation (thanks to @NicolasJouanin)
fixed long standing bug of wrong room name calculation
account data events are handled as if they have a key (like state events) to bypass inconsistency in the spec (maybe this will lead into a MSC)
Just cut a new release of the Ruby Matrix SDK, with 2.5.0 there's some preliminary support for Matrix 1.1 and the client/v3 API, the information for room knocking is exposed properly, some threading issues have had workarounds applied, and a bunch of fixes have been applied.
Currently running my own ping bot with it, I'm doing the GitHub (and hopefully also GitLab at some point) releasetracker bot, I've got my definitely not suitable for production MatrixFS, there's a notification module for TheForeman which we use at the university. And I've got some MSC hacks as well, like the MSC2108 testbed.
I just open sourced a library called Matrix-CRDT: https://github.com/yousefED/matrix-crdt - feedback very welcome! It allows you to use Matrix as a backend for decentralized, local-first collaborative apps. Above you see a collaborative rich text editor (like Google Docs) powered by Matrix!
You can try the Rich text editor here: https://bup9l.csb.app (see also the links in the repo, e.g. there is also a collaborative todo-list example)
If you have a distributed data structure and an algorithm that ensures all participants end up with the same result when their actions are combined, then that's effectively a CRDT as well. For Matrix, there a few research papers like https://arxiv.org/abs/2011.06488 which examine the CRDT-like properties.
First stable release of the gh-bot which is a simple webhook to Matrix bot made in Python.
As of now, the bot supports webhooks from Github, Gitlab and Gitea (although support for this one is very light).
Some other projects might do that way better than this bot but this is a learning project, to learn step by step how client interact with servers.
The next step would be to add a CRT.sh integration to get notified when a certificate is issued for a certain range of domains (which is something we want since we saw an IRC bot do the same).
Matrix-Art is a new social network prototype on Matrix.
It is a direct Devianart style clone. It currently has a focus on only images but is going to get extended to other media types eventually.
I am doing this as a toy project, so it may sometimes have slow progress. The goal is covering the main functions Devianart provides (Posting, Sharing, Profiles, Following, Collections, Comments) as well as integrations to other social networks on matrix using MSC3639.
A lot of things are currently still missing, but I am trying to get uploading working next :)
An instance is hosted at https://art.midnightthoughts.space/ and the code is at https://github.com/MTRNord/matrix-art
Currently, the interface is limited to viewing basic data from a matrix room. In the future, there are plans to have an open registration as well as login with any account to use it. :)
Note however that I suggest against using your personal account just yet, even though the login works, as it may have unexpected room joins at this time. This is known and expected, but not production ready.
Also, at this time, there are no plans of e2ee support. This may get added after the main features are finished.
I just wrote an article about my experience using Matrix, and the question... is it worth posting in the news? The article is written in Russian and published on Habr... and since it's pretty big I'm not sure about translating it to English 😅
Here is the link: https://habr.com/ru/post/599777/ - it also mentions TWIM.
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.
What a pleasure it is to be back with the community for the new year! This week Erlend is detailing what Commune is, and I'm flabbergasted by how well thought-through the project is.
Dept of we've been away for holidays
This week in Matrix should be called Three Weeks in Matrix, since there hasn't been TWIM updates during the holiday season. Nico has published a first and second communitwim while I was away. All the news reports since the last official TWIM still made it to the post you're currently reading!
Your regular spec person, anoa, is out today so you're stuck with me, not-anoa. This time I got the script to work though 😇
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.
MSC Status
Note: This is for the last 3 weeks given TWIM holiday :)
In terms of Spec Core Team MSC focus for this week the last little bit, we've been working on getting MSCs merged into the formal spec itself in preparation for v1.2 this quarter. We expect the release to happen quite soon and to contain Spaces, room versions 8 and 9, and refresh tokens (no spec PR yet) in addition to all the other wonderful stuff which has landed.
The merged MSCs can be seen over at https://spec.matrix.org/unstable/ where they're queued up for the next release. Look out for Added in v1.2 labels throughout the spec, denoting what is new and exciting.
Random MSC of the week
The random MSC this week is MSC2192: Inline widgets (I promise it was random, after a few re-rolls). Inline widgets are a concept that allows for rich functionality in the timeline without needing to necessarily specify an explicit event type. For example, video embeds, minigames, etc could all be represented by inline widgets instead of dedicated event types.
The MSC needs updating to handle MSC1767: Extensible Events (and friends), but once there it could be a very powerful bit of functionality, with free fallback thanks to Extensible Events.
Sliding sync (aka sync v3) is described in MSC3575 - it's still very early days for the proposal which means a lot can change: and YOU can be a part of that. Please take a look at the MSC and provide any and all feedback, be it on the names of keys, format of JSON objects, or the kinds of operations that can be performed. I'm particularly interested in feedback from client developers who have complex room list sort orders or room list filtering requirements and bot/bridge developers who typically don't have a visible room list UI. Any and all feedback at this stage is welcome, visit #sliding-sync:matrix.org to join the discussion.
We're back! New year, new release candidate: we published Synapse 1.50.0rc1 today, marking the end of life for our Python 3.6 and PostgreSQL 9.6 support. We've also extracted some shared utilities into their own package, matrix-common, which is used by Synapse, Sygnal, and Sydent.
We'll talk more about what's in 1.50 next week when it formally releases.
v1.2.9v1.2.10 got released as a maintenance update. With early support for Matrix 1.1, S3 storage classes, and blurhash fixes it's worth the upgrade though there are other goodies - check out the changelog, and report bugs to the issue tracker 🙂
And as a end-of-year update, my Helm Charts have gotten updated yet again. With element-web ending up on 1.9.8, matrix-synapse on 1.49.2 (and .1 before that), and matrix-media-repo on 1.2.10
The first iteration of a Dendrite Helm Chart has been released under the k8s-at-home charts repository. It currently supports a full monolithic deployment and requires minimal configuration to get up and running (just need to generate a matrix key and mount it as per the instructions).
If polylith is your thing then I recommend the chart by S7evinK for now, although it is likely these charts will merge in the future.
An add-on for the matrix-appservice-webhooks bridge. Webhooks are essentially web interfaces for applications to "push" data to. The bridge can receive messages in a certain format, which is nice if the notifying app can be configured. Often it cannot.
Advanced Templating! It is now possible to set format and msgtype based on arbitrary values from the webhook JSON via Jinja2. Shoutout to qg for suggesting this and giving their feedback!
compatibility with matrix-appservice-webhooks forks that read avatarUrl instead of avatar_url
allow mxc:// URL avatars
improvements to the GUI, including automatically resizing text areas and msc:// avatar URL preview
improvements to templates/examples including making use of above features
Howdy folks, it is the time of the year where everyone scarpers! Anyway, perfect time to announce that matrix-hookshot has gotten it's first major release!. 1.0.0 is here!
For those not in the know, the hookshot bridge is used to bridge GitHub, GitLab, JIRA and Generic Webhooks into Matrix rooms. It doesn't just bridge into existing rooms, but can also spawn dynamic rooms based on aliases, send you your notifications in a DM and do lots of other wonderful things!
The notable changes from the 0.1.0 release are:
The bridge has now been renamed from matrix-github to matrix-hookshot.
Now supports JIRA and Generic Webhooks in addition to GitHub and GitLab.
You can get involved and start playing with it by checking out the release here
And that will be my last TWIM entry of the year. Have a good one and stay safe all 🐶
That was in 2021! Half-Shot is back in 2022 with more news
Hey folks! It was only last year we released the 1.0 release of hookshot, after many years of work to get it that far. I'm happy to announce that this week we've got another release. There are a number of buxfixes and improved documentation pieces landing (special shoutout to HarHarLinks for ensuring the docs are competent). The highlights are as follows:
Added support for Figma webhooks. this also means the archival of my old project matrix-figma
Support GitLab wiki page change events.
Added a new script validate-config which allows you to check your config file for simple errors. Handy for people writing ansible roles!
Add support for a html key on generic webhooks to set the HTML content of a Matrix message.
The project can be found over at https://github.com/Half-Shot/matrix-hookshot/, with pretty pretty docs at https://half-shot.github.io/matrix-hookshot. We're also in #hookshot:half-shot.uk if you prefer using Matrix to learn about these things!
UNPLUMB network command to force unplumbing without being in the room
Proper SASL external with CertFP with mechanism override option (see notes)
Disconnect and cleanup from networks that have no rooms open ♻️
Reply (and reject) DM requests to ghosts with QUERY command ↪️
Try to keep IRC users in the room at all costs if they are on the IRC channel
Fix assumption of all IRC replies to have arguments
Prevent accidental namespace changes to cause mayhem
Finally convert from homegrown Matrix API stuff to Mautrix
Bump Mautrix requirement to 0.12=>0.14
Conduit support was broken in 1.8.x but fixed again in 1.9.0, sorry
Finally there's network level spaces support with a new SPACE command. This creates a new bridge controlled space for the network and automatically manages rooms in and out. There's an issue/feature with Element that all rooms that have been converted to DMs with /converttodm will appear in all bridge spaces. The workaround is to convert them back to regular rooms.
CertFP SASL has been updated to do SASL external flow by default. If you are upgrading and have used CertFP with OFTC you need to run SASL --mechanism=none for it to connect again.
Abandoned networks where the user has left all rooms including the network room will now automatically disconnect and cleanup. This is more in line what people would expect and prevents idle connections from hanging around.
This is a small bug fix release. If you reported an issue, there is a 15% chance it is fixed now! This release also supports pinned messages, although those will only show up after someone changed the pinned messages in a room currently (we didn't want to force a full resync just for such a small feature). The spaces list is also now nested, Nheko offers you quick access to your recently used reactions and Nheko will show you your direct chats in the sidebar. Apart from that there are quite a few bugfixes and smaller improvements, you can find the full changelog and downloads here: https://github.com/Nheko-Reborn/nheko/releases/tag/v0.9.1
Thank you everyone, who helped shape this release!
Nheko now is a lot more efficient. We now use one Threadpool instead of 3, got rid of more than 60% of the allocations when scrolling through messages, layout half as much content when scrolling, blurhashes decode in 10% of the time and jdenticons allocate ~10% as much temporary buffers. We also deleted around 1000 lines of unused code. Tooltips also shouldn't steal the mouse focus when scrolling anymore, which could lead to sudden stalls when scrolling.
Additionally edits now replace existing notifications, tastytea added a manpage and fixed blurry or incorrectly sized custom emoji, you can now send custom emotes via the inline completer using ~ and completers now show a scrollable list with more Elements than before. Advanced users can also now opt into an insecure client side secrets storage via a hidden setting.
We're baaaaack! Anyway, last week Drake just translated all of Nheko into Spanish, you can now zoom in and pan in the image viewer, emojis shouldn't split up into their segments anymore and Nheko should always be sending the qualified version of it (according the to the unicode test files, not by just appending FE0F). Blurhashes should be even faster still and we now have support for running the call event loop on macOS and Windows (although call support is still disabled there for now).
We are also now working to restructure our README. It has a lot of outdated stuff in it and you really want to see screenshots pretty early in the README! You can sneak a peak here: https://nheko.im/nheko-reborn/nheko/-/tree/README_updates
This week the Threads team has focussed their efforts on improving some of the smaller details and pesky bugs we’ve found in our first rounds of testing.
If you’d like to help us test Threads we’ll be asking for help in the Community Testing room over the next few weeks. Join#element-community-testing:matrix.org to stay in the loop.
Polls
Polls is available in Labs on all clients! While we know there are some minor improvements to be made, we’re proud of where we are and would love for you to start using it!
Community Testing
Our next session will be on Wednesday, 12th January at 16:00 UTC (17:00 CET). We will be testing the new release candidates on all three platforms! Join us at#element-community-testing:matrix.org
Work continues on the integration of PostHog analytics. With your explicit permissions we’ll receive anonymous usage data that will allow us to understand the areas of Element that are helpful (or not). This info will help fuel things like our Information Architecture project.
In labs (you can enable labs in settings on develop.element.io or on Nightly)
Information Architecture improvements are still being worked on - try it out by enabling things like the new Spotlight search and Breadcrumbs.
Message Bubbles are improving; We’ve been hard at work preparing them for a release in the coming weeks.
During the Christmas break we increase the speed of the app launch by 7x! Once stabilised this update will land with you.
Analytics changes have been merged into the RC and opt-in will be available soon.
In development:
More Spaces improvements are underway; You’ll soon be able to add rooms to Spaces, update room settings, and have room interactions on the ‘long-press’.
Improved onboarding! We’re hoping to make the first few steps in Element easy by simplifying some of the first tasks users take in the app, including signing up.
We’ve started building Message Bubbles on iOS. This will help to distinguish the messages you send from the messages you receive.
We now implement MSC2574! This MSC proposes a standard format for marking up resources (PDFs, other document formats, audiovisual media, websites, geospatial data...) using Matrix.
Room avatars are now displayed in the welcome view for PDF rooms
There's now a UI for using spaces to manage and share PDF collections
Reactions now work like element-web: click to mirror an existing reaction or redact your previous reaction
Next, I'm aiming to implement MSC3592, which proposes a standard format for basic markup on PDFs. Stay tuned! And if you're interested in learning more, come visit #opentower:matrix.org.
Matrix Wrench is a web client to tweak Matrix rooms. After formerly calling it Matrix Navigator or Matrix Screwdriver, I finally settled on the name Matrix Wrench. ¯\_(ツ)_/¯
Version v0.2.0 comes with a Network Log which displays curl equivalents for all network requests. It also allows to easily add and remove room aliases.
https://gitlab.com/jaller94/matrix-wrench/
Cactus Comments is a comment system for the open web, built on Matrix.
We released version v0.11.0 of the client!
The client has been relicensed to LGPL. This means that you can now use Cactus Comments in non-GPL compatible projects.
But mainly, this release brings a bunch of CSS improvements: introducing automatic dark mode, and making it easier to change colors with CSS variables.
Here's the changelog:
Relicense from GPLv3 to LGPLv3.
Rewrite large parts of the stylesheet to use flexbox.
Introduce CSS variables to the stylesheet.
.dark and .light CSS classes with default values for dark/light mode.
Bugfix: "View More" button no longer blinks when auto-refreshing short comment sections.
matrix-bot-sdk has had a v0.6.0-beta.3 release with beta support for crypto! It even includes documentation!
The crypto is considered beta quality at the moment: good enough to use for somewhat unimportant bots, but not fully recommended for production just yet. With that being said, I'm interested in bugs you run into - please use the issue tracker if you run into crypto not working.
Tutorials for the crypto setup are at https://turt2live.github.io/matrix-bot-sdk/tutorial-encryption.html
Note for appservice support to work then you'll need a Synapse with these PRs enabled (may require manual merge too):
https://github.com/matrix-org/synapse/pull/11538
https://github.com/matrix-org/synapse/pull/11617
https://github.com/matrix-org/synapse/pull/11215
For non-linux platforms, the rust-sdk will try to build itself which means you might need a working Rust stack. The Rust SDK repo itself has more information:
Bots and appservices don't automatically support encryption, but adding encryption should be easy. The Rust SDK dependency is required in either case, sorry.
Complement has seem some updates this week in the test output that is produced onto the CLI. Details on how to add this to your CI process are contained in the README. Here's the difference when viewed using Github Actions:
Polyjuice Newt, the newest addition to the Polyjuice project, is an Elixir binding for vodozemac, the new Olm/Megolm implementation in Rust. At the time of writing, Polyjuice Newt supports encryption and decryption using Olm and Megolm, but by the time you read this next year, it may also support the SAS verification functions and pickling/unpickling.
I don't think we've previously had any Nix/NixOS/nixpkgs related entries in TWIM, so I'll start ^^
The current unstable channel has extended its Matrix ecosystem support to also include Heisenbridge and Conduit packages and modules. This makes it super easy to deploy any of those services: For example, my configuration for Heisenbridge is 21 lines long, and Conduit is only 11 lines. You can browse the available configuration options online: services.matrix-conduit, services.heisenbridge (note that some of them are freeform and simply forward to the upstream configuration).
For those that are not into NixOS, a module is the code that turns the declarative configuration files into your running system setup. As an example, if you enable services.heisenbridge the following things are done for you:
Create a new heisenbridge user and group for the service
Create and manage the registration file for the homeserver (i.e. automatically regenerate it after the configuration changed)
Create a systemd service that runs the heisenbridge command with the requested bridge configuration. The unit also sets a few systemd security hardening options.
Jip J. Dekker did the initial work of adding Dendrite support to the playbook back in January 2021. Lots of work (and time) later, Dendrite support is finally ready for testing.
The playbook was previously quite Synapse-centric, but can now accommodate multiple homeserver implementations, with Synapse still remaining the default.
A new Matrix guide has come into town: https://joinmatrix.org
In the hopes to expand Matrix's reach to the non-technical population, this guide is intended to give quick directions on how to use Matrix, as well as clear comparison between Matrix and other dominant platforms.
The pages are available on GitHub. Open to contributions!
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.
If you’re reading this - congratulations; you made it through another year :) Every winter we sit down and review Matrix’s progress over the last twelve months, and look forward to the next - for it’s all too easy to get lost in the day-to-day development and fail to realise how much the overall project is evolving, especially when it’s one as large and ambitious as Matrix!
Looking back at 2021, it’s unbelievable how much stuff has been going on in the core team (as you can tell by the length of this post - sorry!). There’s been a really interesting mix of activity too - between massive improvements to the core functionality and baseline features that Matrix provides, and also major breakthroughs on next generation work. But first, let’s check out what’s been happening in the wider ecosystem…
The Matrix Ecosystem
Over 2021 the Matrix ecosystem has expanded unrecognisably. This time last year we were aware of 2 governments who were seriously adopting Matrix at scale (France and Germany), with the UK and US starting to roll out initial deployments. 12 months later, and we are now aware of 12 governments who are adopting Matrix in various capacities - and we hope to be able to talk about at least some of them in public in 2022! The UK and US have both progressed significantly too.
Meanwhile, one of the most exciting new public sector stories this year has been gematik: Germany’s national healthcare agency, who announced Matrix as the basis for interoperable secure messaging throughout the whole healthcare sector. This is a genuine step change for Matrix: rather than a government putting out tenders for “a secure messaging solution”, instead we are seeing tenders for Matrix solution providers. The Matrix industry is real; it exists today, and we’re seeing more and more new providers such as Famedly (building on the Flutter/Dart stack which powers FluffyChat) and Folivonet (building on the Trixnity Kotlin Multiplatform stack) stepping up to get involved - as well as many more big incumbents. We created Matrix in order to bootstrap a new decentralised communication industry, and frankly it’s amazing to see it actually taking shape.
Another big step change has been the number of existing chat providers looking to become part of the wider Matrix network. Back in September our friends at Rocket.Chat announced that they’re working on Matrix support for federation, perhaps inspired by our case study in making Gitter speak Matrix - and meanwhile Matrix comes up a lot in the context of Twitter’s Bluesky initiative, and a few big players we can’t yet mention have also been in touch wanting to natively talk Matrix too.
We’ve also seen a huge shift in big enterprises adopting Matrix for self-sovereign secure communication (although we can’t drop any names yet 😔). This may have been spurred on by such misadventures as Electronic Arts being compromised via a leaked Slack access token, but it feels like many of the biggest organisations now realise that unquestioningly handing their data to Slack or Teams is a bad idea, when they could have an end-to-end encrypted deployment of their own instead.
There has also been a turning point in legislation in favour of Matrix - with the EU Digital Markets Act pushing hard for interoperability for ‘big tech’ communication services in the EU (see Amandine’s take here), and meanwhile Eric Migicovsky, CEO at Beeper has been busy testifying to US Congress on the merits of interoperability too. It’s not inconceivable that we will soon live in a world where governments mandate that the walled gardens will finally have to open up, and we may see a whole new level of interest in communication providers wanting to join Matrix!
Communities themselves have also been embracing Matrix more and more over the last year: we were incredibly proud to host FOSDEM 2021, the world’s biggest open source conference via Matrix (all 35K attendees!) - and we’re gearing up to do it again in February for FOSDEM 2022 (this time with our very first FOSDEM Matrix dev room!). We were also really glad that Libera.chat let us point a dedicated homeserver and IRC bridge at their new IRC network (meaning you can join anywhere on Libera from Matrix as #channel:libera.chat, and talk to anyone as @nick:libera.chat). High profile open source projects have been adopting Matrix all over the place - Debian, Fedora, NixOS, Arch, Tor, Ansible, WHATWG and many others (check out this list!) now have their own Matrix servers and spaces. (You know things are busy when we haven’t had time to do a big blog post to announce folk as important as these joining the network!)
Finally, there has been an explosion of new projects and milestones in the wider community - Conduit entered beta as a super exciting lightweight Rust homeserver implementation; FluffyChat hit 1.0 with an impressively polished Flutter-based experience; Beeper pre-launched to huge amounts of mainstream excitement; Cinny exploded out of the blue as an incredibly elegant next-generation web client; Keanu materialised from The Guardian Project as their glossy Matrix client suite; Commune appeared as a hybrid messageboard/chatroom interface; Nheko has matured significantly with huge E2EE improvements and feature and VoIP polish; NeoChat and libQuotient development is progressing solidly; Fractal is busy with the fractal-next rewrite to move everything over to matrix-rust-sdk and GTK 4; Syphon continues to forge ahead as a privacy-focused Flutter-based client, and non-chat clients like The Board, Populus and Matrix Highlight have started to appear in earnest too! We also had a super successful Google Summer of Code this year, with a record number of 7 students participating in both core team and community projects.
Please note this is just a random sample of all the community news over the last year - to get more colour on what’s been going on, we highly recommend flipping through the This Week In Matrix archives!
The Matrix Spec
The Matrix spec is the single source of truth of what Matrix actually is, and this year it got some major improvements thanks to a beautiful new website at https://spec.matrix.org thanks to Will Bamberg, formerly of MDN (and who’s now back fighting the good fight with the MDN team at OWD).
Aside from the new spec site, we also released our first official point release in a while - Matrix 1.1, and we’re going to aim to keep regular releases happening once a quarter from here on in. It’s also worth noting that it’s very much a feature and not a bug that spec releases lag behind the various spec proposals which fly around as the core team and community experiment with new features like spaces, threads, etc. We very deliberately only merge change proposals to the spec which have been proven to work in real life implementations, and which have fully passed the spec review process (along with any dependencies they might have!).
Talking of which, in 2021 we saw a record 109 Matrix Spec Change proposals (MSCs) created. Even better, we closed 62 MSCs - so while the backlog is still growing, we’re still making very concrete progress. Of the 109 new MSCs: 34 were from the wider Matrix community, 34 were from ex-community contributors who are now part of the core team, 13 were from the founding Matrix team, and 28 were from folks hired to work on Matrix by Element on behalf of the Matrix.org Foundation. This feels like a pretty healthy blend of contributions, and while it’s true that spec work could always progress faster, things do seem to be heading in the right direction.
In the new year, the Spec Core Team (responsible for reviewing MSCs and voting on what gets merged to the spec) is going to make a concerted effort to carve out more dedicated time for spec work - thankfully one of the side-effects of Matrix growing is that there are now a lot more people around with whom we can share other work, hopefully meaning that we can put significantly more hours into keeping the spec growing healthily.
Synapse
Synapse is the primary homeserver implementation published by the Matrix core team, and its maturity is unrecognisable from where we were a year ago. One of the big breakthroughs has been stabilising memory usage through caching improvements - the Matrix.org synapse now reliably only uses 2-3GB of RAM on its main process, despite its activity having more than doubled over the last year (up from 513K monthly active users to 1.11M!).
Further signs of maturity include Synapse’s radically improved new documentation and the new module API, the fact that mypy type-safety coverage has improved from ~75% to over 89.7% (across 151,903 lines of code!), and the fact that Open Tracing support has matured to the point that visualising complex cross-worker behaviour is nowadays a genuine pleasure. Frankly, Synapse should be feeling robust and stable these days - if you see folks claiming otherwise, please check they’re not basing that on outdated info (or failing that, get them to file bug reports that we can jump on!).
Meanwhile, on the feature side, we’ve landed a huge spate of long-awaited core functionality. Probably the best way to track it is by the Matrix Spec Change proposals (MSCs) which have been implemented (although I dare you to also go and check out Synapse’s changelog, all 675KB of it, which is frankly a thing of beauty and will take you down a rabbithole all the way back to v0.0.0 in Aug 2014 if you so desire ;P). Major MSCs which we’ve landed include:
Spaces! It’s hard to overstate how positive this has been for Matrix’s usability: at last, we can group our rooms together however we please, both for our own edification and to share with others - and we can view space hierarchies over federation, complete with pagination (MSC2946) as well as specify who can join a room based on whether they’re a member of a given space/room (MSC3083).
Threads! Yes, that’s right - coming any day now to a Matrix client close to you, we have ‘classic’ threaded messaging landing, providing sidebars of conversation through the new m.thread relation type (MSC3440), building on Matrix’s existing aggregation API as used for edits and reactions. We’ve chosen to prioritise single-level-deep-threads rather than arbitrarily-deep-trees (MSC2836) as it maps more easily to a chat UX, although the two approaches are not mutually exclusive.
Aggregations! Everyone’s favourite bête noire in Matrix tends to be that aggregations for edits & reactions predate today’s Matrix Spec Change process and went mainstream without using a vendor prefix before their spec had been stabilised. Better late than never, we’ve taken advantage of Threads to go back and fix what once went wrong - and now MSC2674 and MSC2675 and friends are hopefully on a much better track to provide a basis for how aggregations work - both in the spec and in the reference implementation in Synapse.
Social Login via multiple SSO providers (MSC2858) - almost 50% of new registrations on the Matrix.org homeserver now use social login! Interestingly the split of SSO usage is roughly 70% Google, 12% GitHub, 11% Apple, 6% Facebook and 1% GitLab. Make of that what you will!
Knocking (MSC2403)! Huge thanks to Sorunome and Anoa, we now support the ability to knock to ask to join a room if not yet invited. If this sounds unfamiliar, it may be because it hasn’t landed in Element yet, but expect it to land next year.
Refresh tokens (MSC2918)! At last, we have a standard way for clients to refresh their access tokens, so that if your access token leaks it will not give access to your account indefinitely. (This also has yet to land in Element, but has been proved on a branch on Hydrogen).
Finally, last but not least, Eric from Gitter has been fearlessly hacking his way through some of Matrix’s gnarliest problems in his quest to bring Matrix+Element up to full feature parity with Gitter. In practice, this means adding the ability to incrementally import old history into existing Matrix rooms (MSC2716), so we can expose the vast amounts of knowledge in Gitter’s archives directly into Matrix - and in future provide bridging in general of existing archives (Slack, Discord, mailing lists, newsgroups, forums, etc.) into Matrix.
This is a tough problem, as Matrix rooms are fundamentally immutable - events sent into a room cannot be changed. However, we can bend time a bit and add old chapters of history to the room as if we’d just discovered them down the back of the sofa - and this is what MSC2716 does. The (rewritten!) spec proposal is a thing of beauty and well worth a look, and you can see an early preview in action back on Matrix Live in June. Over the last few months it’s been merging and maturing in Synapse and we should see it in the wild in the near future! And for bonus points Eric’s also just added in Jump-to-date support (MSC3030), letting clients jump around room history by timestamp - another Gitter feature that we sorely need, and will also help us publish excellent Gitter-style online chat archives in future. You can see it in action in last week’s Matrix Live!
Element
Meanwhile, on the client side, Element continues to act as a flagship client to drive the development of the official client SDKs we ship as the Matrix.org Foundation - and our focus more than ever before has been to ensure that Matrix can be used to create mainstream-usable polished glossy apps. After all, Matrix will only succeed if clients emerge which can punch their weight against the enormous incumbents - be they Slack, Teams, WhatsApp or Discord.
This year, improving UX quality has been front and center - and hopefully the shift has been obvious in the app (and huge thanks to everyone who tweeted/tooted/enthused about improvements when they saw them!). Part of this has been ensuring that all new features are built in a design- and product-led fashion by folks who are explicitly focused on product engineering - with product design involved from the outset and with coordination and focus provided by product management folks. This is far from the typical way that FOSS operates, but if we’re to succeed against the incumbents we have to beat them at their own game (just as, for instance, Mozilla wields conventional product management in their browser wars).
More recently, there’s also been a major shift towards structured user testing in order to evaluate new features and analyse how users trip over the app in general, including radically improved analytics (for those who opt in!) to help visualise which bits of the app aren’t working. In the new year, the expectation is to double down on user testing: quite simply, if you can hand Element to a casual mainstream user and they can get the core jobs done (sign up, chat to someone, call someone, etc.) without tripping over, then mission successful :)
The Element blog covers the work this year from the Element side, but from the Matrix side, the key changes include:
finalising Spaces as a way to group together rooms - providing the equivalent of Discord servers or Slack workspaces, or alternatively letting you gather your own rooms together into a private space.
building out Threads (available in labs; launching soon!)
Social Login!
radically improving Element’s Information Architecture (i.e. the layout of the UI, so that the panels and buttons are correctly semantically grouped together in a visual hierarchy)
adding Location Share (available in labs; launching soon!) powered by MSC3488 (and in future MSC3489 for live-location sharing - in dev on iOS right now!)
adding Chat Export, thanks to the amazing GSOC work by Jaiwanth
From a spec perspective, it’s been particularly exciting to be finally using Extensible Events (MSC1767) for many of these new features: voice messages, location sharing and polls are all experimenting with this new idiom for expressing richer structured data over Matrix while presenting a consistent and useful ‘fallback’ representation for clients which don’t know how to natively render the richer data.
We’ve also done a huge amount of work this year in improving 1:1 VoIP - both via MSC2746 and within the JS, iOS & Android Matrix SDKs. If you haven’t tried doing a 1:1 call via Matrix recently we’d highly recommend giving it a go - probably the main remaining bug at this point is that we need to find a better default ringtone for Element(!). Huge thanks go to Šimon Brandner both for his community contributions to VoIP and across all of Element Web - including proper screensharing for 1:1 (and group!) VoIP calls. This has also laid excellent groundwork for native Group VoIP/Video over Matrix - more on that later.
On Element Mobile, work on all the above features has been balanced by fighting against the various platform’s quirks, and lots of under-the-hood work improving performance. iOS has gone through a long journey to get back to stability after iOS’s push notification API changes, while also improving incremental sync performance by rearchitecting the local cache in the client. Android meanwhile has been working away improving the app; reworking Notifications, migrating to Kotlin coroutines and Hilt, and closing over 690 GH issues. Android has also had its fair share of dramas, including some recent long Play Store review times, but we’ve come through the other side intact.
However, we’ve been thinking more and more about the nightmarish pain point that is the amount of time we spend implementing the same features across the three different platforms. This becomes particularly apparent for security-sensitive features such as end-to-end encryption, or major API changes such as aggregations, spaces or sync v3 (more on that later). Or simply rapidly sharing improvements to implementation best practices between platforms.
Historically we consciously built platform-native Matrix SDKs in order to provide entirely idiomatic SDKs for other Matrix developers to use - and also to better dogfood the protocol and ensure that the heterogenous implementations could interoperate successfully. However, in practice, relatively few third party projects other than Element build on top of matrix-ios-sdk and matrix-android-sdk2 - and meanwhile there are more than enough other Matrix clients out there nowadays to dogfood interoperability against (including alternative experimental clients from the core team such as Hydrogen).
So, we’ve been thinking increasingly seriously about how to solve this…
A new hope: matrix-rust-sdk
matrix-rust-sdk is an attempt to build a new reference client SDK for Matrix which can be used by as many platforms as possible - hopefully forever stopping us from reimplementing the wheel more than we need to. Work began towards the end of 2019, building on top of Ruma’s excellent Matrix rust crates, and poljar has been working away solidly at it ever since. We teased matrix-rust-sdk in last year’s update, but as of this year it is properly coming of age and we’ve started using it in earnest - beginning by swapping out Element Android’s encryption implementation for matrix-rust-sdk-crypto (the E2EE cryptography crate provided by the SDK).
If you’re not familiar with Rust, the main benefits we get here are a heavy emphasis on safety and security without compromising performance; while providing a single codebase which can be used equally from iOS, native Desktop apps such as Fractal, Android (with native bindings) and even Web (via WASM, in future). While technically this results in a “non-native” SDK relative to matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk - in practice, it’s become so common to depend on native-code shared libraries (outside the web, at least) that it’s not really a problem.
Initial results look wildly promising here: “Element R” (formerly known as Corroded Element - the codename for the Rust-enhanced version of Element Android) builds are now out there, and out-perform the kotlin E2EE implementation by roughly 10x, thanks to using native code and Rust’s improved parallelisation.
Our next step is to start using it on iOS, and we’ll be experimenting with a next-generation of Element iOS shortly in the new year with the SDK provided exclusively by matrix-rust-sdk. Element will also be funding more people to work fulltime on matrix-rust-sdk itself, and to see what the developer experience is like when you use it seriously on the Web - watch this space!
Bridges, Bots, Widgets and Integration Managers
Elsewhere in Matrix, the Bridge Crew has busy polishing bridges like crazy - working away on encrypted application services (MSC3202), massively improving the IRC bridge (particularly in the fallout of the great Freenode->Libera migration), stabilising and extending matrix-bifrost (our XMPP-and-more bridge), getting libpurple bridging working properly in bifrost, getting matrix-appservice-slack and matrix-appservice-discord stable enough to be hosted by EMS, experimenting with matrix-bot-sdk as an alternative bridging API, and even looking at adding matrix-rust-sdk-crypto into matrix-bot-sdk as an elegant way to power robust encrypted bridges (thus replacing Panatalaimon for that use case).
There’s also a new kid in town: matrix-hookshot (formerly known as matrix-github) is a new all-singing-all-dancing general purpose integration built on matrix-bot-sdk, coming soon to an integration manager near you, which can bridge through to GitHub, GitLab, JIRA and freeform webhooks! Check it out a few weeks ago on Matrix Live. matrix-hookshot is primarily Node, but is also getting in on the Rust action with some functions being implemented in native code.
Meanwhile, change is afoot for integration managers, which have been screaming out for an overhaul for years. There was a cheeky hint in last week’s Matrix Live where Dimension did an unexpected cameo looking particularly swish… All shall be revealed next year!
Dendrite, Low bandwidth Matrix and Peer-to-Peer Matrix
Dendrite is our next-generation homeserver implementation written in Go, and having shipped the first beta in Oct 2020, we’ve cut another 11 releases over the course of this year - adding in features such as E2EE key backups, cross-signing, support for room versions 7, 8 and 9 (knocking and restricted join rules), massive state resolution performance improvements, an entirely new state storage implementation that uses ~15x less disk space, sync filtering, experimental support for peeking-over-federation (MSC2444) - not to mention huge numbers of bug fixes. Even more excitingly, we’re in the process of ditching Kafka in favour of native-Go message queuing in the form of NATS!
However, it’s been a bit of a weird year as the team has been repeatedly pulled onto other projects due to competing priorities - and there’s still a bunch of stuff left which is keeping us in beta. Some of this is plain old missing features (search, push rules/notifications, room upgrades, presence etc) - but we’ve also run up against some problems over the last few months while implementing new room versions and similar thanks to the sheer number of different microservices which Dendrite is made out of. In retrospect, it feels like Dendrite has ended up too granular, and when hacking on it you get slowed down badly by all the boilerplate required to glue the various services together. Therefore, we’ve just started to merge some of the services together - still preserving horizontal scaling of course, but refactoring the architecture a bit while we’re still in beta to help speed up development again. So far things are looking promising! We’re also really looking forwards to s7evinK joining the team to work on Dendrite fulltime in the coming weeks :)
Talking of competing priorities, there have been three other big missions going on at the same time as Dendrite dev: firstly - formalising Low Bandwidth Matrix. LB Matrix is super important for maximising battery life on mobile, as well as (obviously) supporting worse network conditions - and it’s effectively a prerequisite for P2P Matrix. We did a bunch of experiments around it back in 2019, but earlier in the year we needed it for real and MSC3079 was the result. The low bandwidth dialect which we’ve proposed in the MSC is designed for use on the real Internet using standard IETF protocols (CoAP + DTLS + CBOR) and so isn’t quite as exotic as the 2019 version, but still gives a ~10-20x bandwidth improvement over normal HTTP+JSON based Matrix. It hasn’t made it to Element yet, but if you’re interested go check out the blog post!
Secondly, we’ve been sidetracked by the entirety of P2P Matrix. This is our long-term mission to let Matrix run peer-to-peer without the need for any servers (or indeed Internet connectivity, thanks to Bluetooth Low Energy) by embedding servers such as Dendrite into clients such as Element and so let each Matrix Client have its own personal local homeserver. We’ve made massive progress over the course of the year on P2P - the biggest breakthroughs being Pinecone as an entirely new P2P overlay network, with the novel SNEK (sequentially networked edwards key) routing topology. (The animation below shows a P2P network arranging itself into a SNEK!)
You can read all about it in the blog post, but suffice it to say that Pinecone outperformed all the other P2P overlay networks in meshnet-lab’s Mobility2 test:
You can play with P2P Matrix today on iOS and Android (head over to #p2p:matrix.org for builds), but there is some major work still to be done:
We need to bridge to today’s Matrix network. Right now, having a weird experimental test network for P2P means that in practice nobody actually uses it other than for demos - whereas if you could actually talk to everything else in Matrix, it’d be way more compelling and interesting to use and dogfood. We’re currently thinking about how best to do this!
We need to standardise the actual transport to be used over Pinecone. Currently it uses HTTPS over μTP (purely because empirically it handled packet loss and congestion well, and LB Matrix wasn’t ready at the time). We’re currently experimenting with switching to LB Matrix using our own CoAP implementation called PineCoAP (potentially using pCoCoA congestion control, given CoAP doesn’t provide any congestion control out of the box), but this is early days.
We still need to finalise store-and-forward: if your destination is offline, do you buffer your transactions in the network somehow, or do you use another Matrix node to buffer them?
Relatedly, we need to tweak federation so that if events get lost, federation for a room can recover more gracefully than it does today - for instance, by bundling redundant auth events on transactions, or by providing more recovery mechanisms.
We still need to spec and implement multihomed accounts, so that your identity on your phone is not divorced from your identity on your laptop.
…and obviously, we need a robust post-beta Dendrite to act as the local homeserver!
Right now focus is going back to Dendrite for a bit, but P2P work will resume again in the new year :)
Finally, the third big distraction from Dendrite has been… sync v3.
Sync v3
Sync v3 is shaping up to be the single most significant improvement to Matrix since we began.
Syncing data from the homeserver to the client is obviously fundamental to Matrix - and the current behaviour (sync v2) is far from perfect, as it’s designed around the assumption that your client wants to receive information for every room that it’s in. In the early days of Matrix, this was fine: a typical user might be in tens of conversations, and it’s useful to have them all available for offline access. Nowadays, however, it’s a disaster: users can easily accumulate hundreds or thousands of rooms - especially with rooms used to describe spaces or profiles and other structured realtime data. Moreover, the number of rooms you’re in typically increases linearly over time, unbounded, as nobody wants to archive their old conversations.
So, the idea of sync v3 is that you only sync the strict subset of data that your client actually cares about to display in its UI - effectively making both initial and incremental sync instant, incredibly low bandwidth, and completely independent of the number of rooms you’re in (just as filesystem performance should be independent of the number of directories or files present).
For instance, the full initial sync for @matthew:matrix.org in sync v2 is 417MB of JSON uncompressed - or ~100MB if gzipped, and takes about 5 minutes to calculate on matrix.org (during which it murders the sync worker responsible and hammers the database like crazy). By contrast, sync v3’s initial sync is 15KB uncompressed, or 5106 bytes compressed - and synced in 250 microseconds from a local sync-v3 server. Yes folks, that’s somewhere between a 30,000x to 1,200,000x improvement over sync v2, depending on how you count it.
Sync v3 gets this unbelievable performance by the client defining a sliding window into the server’s datasets, sized and ordered as needed for the client’s UI. This effectively performs real-time serverside pagination, so that as the client scrolls around or filters their roomlist or membership list, the client requests new views from the server. Meanwhile the server sends incremental updates to the client if they intersect with the sliding window. This may sound unwieldy, but in practice it works fine (although we’ll have some interesting challenges when we get around to encrypting state events, given serverside ordering and filtering will become distinctly harder). It also doesn’t design out offline access, as the client caches its view of the world so even if you do go offline you can still work with all the data that has sent to your client so far (and the client could even proactively paginate in other content, if it wanted to, similar to an email client synchronising for offline access).
Sync v3 exists today as a proxy called sync-v3 which sits between any existing homeserver and a sync-v3-capable Matrix client. It’s very early days, but Hydrogen has basic v3 support on a branch which we’ve been using to experiment with the API and flesh it out - and you can see a demo and intro talk in last week’s Matrix Live!
The API itself is still in flux, but those interested can see the initial spec design at https://github.com/matrix-org/sync-v3/blob/main/api.md and also an MSC is emerging at MSC3575. Next steps will be to finish hooking up to Hydrogen (including filtering the room list), finish the MSC, and then start thinking about implementing it in other clients and servers!
Fast Joins over Federation
While we’re on the subject of speeding up Matrix… it’s all very well being able to sync your client instantly, but the other big complaint everyone has about Matrix is how long it takes to join rooms - especially big ones. As most people will know, it can easily take 5-10 minutes to join a large room like Matrix HQ on a new homeserver - and given this is the first experience most users have of running their own homeserver, it can prove pretty disastrous and we are determined to fix it. It will become even more relevant when we implement peeking over federation, as the last thing you want is to have to wait 5 minutes to temporarily dip into some random federated room to see if you want to join it or not (or to sniff its room state for things like extensible profiles or MSC2313 reputation rooms).
So, to address this, we’re currently in the middle of experimenting with MSC2775 (Lazyloading over Federation) in Synapse. This MSC lets servers participate in a room before they’ve received the full room state by defining a subset of state which is mandatory for participation, and then letting the rest get added lazily. It’s quite a violent change as it means the assumption that room state is complete (to the best of the server’s knowledge) is no longer true - but given Matrix already has to handle incomplete room state, it’s not necessarily a showstopper.
Watch this space for how well it works in practice, but we’re hoping for a ~20x speed improvement in joining Matrix HQ.
Hydrogen
2021 has been a busy year for Hydrogen - our ultra-lightweight Matrix Client, which provides a small but perfectly formed progressive web app for us to experiment on! There have been no fewer than 56 releases over the course of the year, with loads of contributions from Bruno, Midhun (who joined first as a GSOCcer and then as a fulltime Element employee) and also Danila who interned at Element on Hydrogen over the summer.
People often ask why Hydrogen exists as well as Element Web - and the reason is because Element Web is (for now at least) very far from a progressive web app and is stuffed full of features, whereas Hydrogen is intended to be as lightweight and simple and efficient as possible while also targeting as wide a range of web browsers as possible (even Internet Explorer!). It also provides a simpler platform for experimenting with new approaches such as sync v3 or OIDC without getting entangled in the constant hive of activity around Element Web. Finally, it gives us a playground to experiment with embeddable chat clients thanks to Hydrogen’s strict MVVM component model.
In terms of features, 2021 has seen huge steps forwards as Hydrogen converges on feature parity with Element - proper mentions and replies; rich formatted linkified messages; reactions; redactions; memberlist; member info; webpush notifications; proper image, video & file uploads; SSO login; sync v3(!) and so much more. Can’t wait to see what 2022 will bring!
End-to-End Encryption
2021 saw the long-awaited creation of a dedicated cryptography team to focus exclusively on improving encryption in Matrix: previously encryption expertise was split across various different areas, meaning that it could prove hard to carve out time to tackle the bigger remaining encryption challenges.
So far the team has been busy digging deep into the few remaining causes of UISIs (undecryptable messages), including automated UISI reporting and tracing E2EE flows end-to-end (from client to server to server to client). There’s also been an initial wave of UX work - with much more to come next year as we overhaul cross-signing and device backups to make it way more user friendly.
Meanwhile, on the more foundational side of things, we’re continuing to define Decentralised MLS as a potential next-generation form of end-to-end encryption, building on the IETF’s MLS work - providing much better scalability for large chat rooms and potentially helping with some causes of encryption failures. Hubert (uhoreg) has been leading the charge here, with his latest thoughts emerging here alongside a brand new demo showing his DMLS simulator - which under the hood is actually sending real Matrix events over DMLS!
Otherwise, the team has had three big projects: adding matrix-rust-sdk-crypto into Element Android (which we already covered above), arranging a fresh security audit of Matrix’s end-to-end encryption (due to complete January 2022)… and, most excitingly: vodozemac.
Vodozemac (pronounced roughly vod-oz-eh-matz) is an entirely new implementation of our Olm and Megolm end-to-end encryption system, written from scratch in pure Rust, aiming to replace the original reference C/C++11 implementation in libolm. Originally written as an experiment for matrix-rust-sdk at the beginning of the year, in the last week it’s received a huge explosion of attention from poljar and dkasak to bring it up to production quality… for we decided that if we are doing a full E2EE audit for Matrix, we should target the new and future codebase rather than burn money on re-auditing the legacy libolm library (much as the original 2016 review of libolm happened when the library was fresh and new).
The motivation for vodozemac in general is to benefit from the intrinsic type and memory safety and fearless parallelism provided by Rust - and also maintain full type & memory safety throughout the matrix-rust-sdk stack, including encryption. Over the last year we’ve been taking more and more of a careful look at libolm, and despite our best efforts a few memory management bugs have crept in - which vodozemac should be immune to. Vodozemac will solve another embarrassing problem with libolm: that its default cryptography primitives are designed for correctness rather than performance or safety. By switching to Rust’s ed25519-dalek and rustCrypto AES primitives we should be in a much better position in terms of performance and safety.
Next up, we’ll be fully integrating vodozemac into matrix-rust-sdk, and figuring out how best to provide it as a libolm replacement in general.
Matrix Security
Alongside the new Cryptography team we’ve also established a new dedicated Security team for Matrix, led by dkasak. As well as fuzzing excursions into libolm and similar research, Denis has been handling all our security disclosure policy submissions, managing the Intigriti bug bounty programme, helping coordinate all our security releases, and coordinating the upcoming external independent security audit of vodozemac, matrix-rust-sdk, Element and Synapse. It’s a huge step forwards to be able to fund full-time infosec researchers to focus exclusively on Matrix, and this is just the beginning!
Trust and Safety
Another place where we’ve created a dedicated team this year is around Trust & Safety: building tools to fight spam and abuse on our own servers, while also empowering the wider network of users, moderators and admins to manage abuse as they see fit. This includes lots of work on Mjolnir, our primary moderation bot, but also defining MSCs such as MSC3215 (Aristotle: Moderation in all things) and MSC3531 (Letting moderators hide messages pending moderation) and internal tooling as we experiment with different approaches.
We’ll have more updates on this in the coming year as we release the tools we’ve been working on, but suffice it to say that the goal is to empower mainstream users in the wider Matrix network to apply their own rules as they see fit, directly from the comfort of their favourite Matrix client - without having to know what a Mjolnir is (or how to run one), and without having to be a moderation expert.
OpenID Connect
A new project brewing throughout 2021 has been the investigation into replacing the entirety of Matrix’s authentication APIs with industry standard OpenID Connect. Spearheaded by Quentin, this has proved to be a fascinating and challenging endeavour, but we’re starting to see some really interesting results. The problem we’re trying to solve here is:
As Matrix grows, we’re seeing more and more clients and services appearing which you might want to log into with your Matrix account. But do you really want to trust each app with your account password? And what if you only want to give it access to a small subset of your account?
Similarly, we’re seeing more and more login mechanisms used to access Matrix - it’s no longer just a matter just a username + password; many servers use single-sign-on (e.g. mozilla.org) or social login (fosdem.org, matrix.org), or layer on 2FA or MFA hardware tokens and similar to access their accounts via an SSO provider. We also see passwordless login on the horizon.
So, do we really want to mandate each new Matrix client to have to implement custom flows to handle this explosion of login/registration mechanisms? And is it even really the client’s problem in the first place? You’re securing access to your account on your chosen server, which isn’t really a client-specific thing at all.
The real turning point for the project however has been our recent experiences building out a new wave of single-use domain-specific clients (see below) for video conferencing, whiteboarding, metaverse-browsing etc… where by far the most painful bit of the project has been hooking up the UI for login, registration, guest access, incremental signup, password reset, email verification, CAPTCHA, SSO, etc. And that’s even when building on top of matrix-react-sdk, which theoretically has it all already thanks to Element Web!
Frankly, it has become blindingly obvious that it’s crazy for clients to reimplement this every time, and they should instead chuck the user over to a sign-on portal provided by their homeserver - just like Google and everyone else’s single-sign-on does. And rather than inventing our own homebrew way of doing that, we should just use the existing industry standard SSO best practices defined by OpenID Connect.
The main objections which have come up against this are: “what if my Matrix client doesn’t have a web browser, or what if I want to provide my own native login UI”, and “does this design out the idea of using a single password to access your account as well as your E2EE history”? In both instances, we have workarounds: in practice, there are so many Matrix clients around that we won’t be removing today’s legacy login/registration APIs any time soon (just like HTTP Basic Auth is still very much a thing on the web!). And in terms of “cryptographic login”, there are ways we could daisychain the auth required to unlock your E2EE storage to also authenticate you with your server - although this would be a major extension (much as cryptographic login is already today!)
The current status is that we’ve defined a set of initial MSCs (MSC2964, MSC2965, MSC2966 and MSC2967), and are implementing an initial Open ID Connect auth server (in Rust!) called matrix-authentication-service (better name suggestions welcome!) designed to sit alongside your homeserver, and we’re experimenting with hooking Hydrogen (and some of the new domain-specific clients) up to see how it feels. But if it goes as well as we think it might, folks should prepare for 2022 to be the year where Matrix’s authentication system finally gets fixed!
Native Matrix Video/VoIP Conferencing
One of the most anticipated features in Matrix over the years has been the prospect of native, decentralised, end-to-end encrypted video and voice conferencing. Today, voice and video conferencing in Matrix works by embedding Jitsi as a third party centralised service into your chatroom. This works fairly well - but Jitsi is an entirely separate service with lots of moving parts, and its own concept of users and access control (provided by XMPP!) and its megolm-based end-to-end-encryption doesn’t actually integrate with Matrix’s own Olm identities, verification or cross-signing. The fact that the conference is then logically centralised on whoever is hosting the Jitsi service also misses one Matrix’s main goals - that users should be able to hold a conversation without being dependent on any single service or provider. Plus it’s really confusing that Matrix has proper native 1:1 calls for DMs… but then switches to a totally different system in group chats.
So, this year we set out to fix it - and succeeded :D The solution hinges around MSC3401 - a spec proposal that describes how to extend native 1:1 calls to work for groups, while providing real flexibility on how to actually mix the calls together. At the simplest extreme, it defines how full mesh calls work (where every client simply calls every other client simultaneously) - but then also defines how you can mix calls together either using a single focus (conferencing server) or multiple foci run by different parties, where foci can either be Selective Forwarding Units (SFUs, like Jitsi) or Multipoint Conferencing Units (MCUs, like FreeSWITCH). The end result is to give us decentralised, cascading, end-to-end encrypted conferencing which even has direct compatibility with today’s 1:1 Matrix calling, letting you easily hook in bots and bridges which already support 1:1 Matrix calls!
Robert Long has been frantically hacking away at the initial implementation over the last few months, fleshing out full-mesh conferencing at first and getting it running in as many browsers as possible (including Mobile Safari and Chrome Android!). We were hoping to fully unveil the end result in time for Christmas, but in practice we hit some last minute snags (turns out Matthew forgot guest users can’t use TURN, who knew? so much for incremental login! 😰) which have pushed the launch to early next year. But hopefully in a few weeks, you’ll be able to start jumping on a native group call in Matrix!
Meanwhile, those interested can see all the gory details from our CommCon 2021 talk a few weeks ago, complete with a demo of the shape of things to come…
Next up, we’ll be working on building an MSC3401-compatible SFU so we can go beyond full mesh (which typically supports a maximum of ~7 callers). Our candidates right now are mediasoup, ion-sfu, janus and signal-calling-service - we’ll let you know how it goes! Also, if you’re interested in helping us build this out quicker, we are frantically searching for more WebRTC & VoIP gurus to join the team at Element working on this.
Applications Beyond Chat
Finally, 2021 was the year where we seriously started building out functionality on Matrix which goes far beyond plain old chat rooms.
Work began in the summer as a research project led by Ryan, formerly tech lead for Element Web - looking at ways to store hierarchical structured data into Matrix while preserving real-time semantics; effectively using Matrix as a collaborative decentralised object tree, providing CRDT (Conflict-free Replicated Data Types) to allow richer applications to be built on Matrix. This journey led him to create Patience as a test environment for building out these sort of clients, and meanwhile Timo (famous of The Board) joined the team to build out Full Screen Widgets in Element, providing a much better UI for beyond-chat experiments.
Meanwhile, Matthew Weidner and the Composable Systems Lab at CMU stunned us all by presenting a complete CRDT solution using Matrix named Collabs at Strange Loop 2021. This is really impressive stuff - the brave of heart can go and embed a Matrix-powered end-to-end-encrypted collaborative markdown editor straight into Element via Collabs by following the instructions here. In practice, Collabs works by serialising the CRDT updates as base64 blobs inside Matrix timeline events (hello Wave, is that you?), but we’re now investigating how you might reconcile this with maintaining a proper realtime object tree in Matrix.
It’s hard to overstate how powerful storing freeform tree CRDTs in Matrix would be. It could open up everything from decentralised encrypted collaborative document editing to collaborative whiteboarding and collaborative Figma-style (or Penpot- or Blender-style) design. You could even start storing an HTML DOM into a room, alongside its binary assets, giving you a multiplayer DOM to build on… and then imagine if you could store the syntax tree of the code operating on that DOM alongside it, in the same room. Before you know it, we will have created kind of some incredible Smalltalk / Croquet / Alan Kay nirvana where code is data and data is code and it’s all running live in some kind of decentralised encrypted multiplayer Metaverse :D
While we’ve been looking at storing object trees in Matrix, another obvious angle that has emerged is to use Matrix for encrypted decentralised file storage. MSC3089 is a proposal on how you might represent hierarchies of files in Matrix - where each room acts effectively as a directory of files, with spaces forming a directory structure (much as they do already in today’s Matrix), leveraging Matrix’s existing decentralised access control mechanisms to control who can access what. Combine such a file storage system with the collaborative editing capabilities mentioned above, and suddenly a really exciting proposition starts to emerge. We’re investigating this right now, and all will be revealed early next year…
Finally, and last but not least, Robert Long has been building on top of our shiny new Native Matrix Voice/Video Conferencing capabilities to use Matrix as the communication backbone for a truly open, equitable and interoperable vision of the Metaverse. The best way of describing it is to look at his awesome Third Room demo from the Open Metaverse Interoperability Group demo session in September:
Now, some folks will recall that since day one (in fact, since before day one) the hope for Matrix was that it might end up as the communications fabric of the Metaverse. We were about 4 years early when we first starting enthusing about this, and then still ahead of our time when we did the world’s first 3D Video calling over Matrix. However, it now feels like the world has finally caught up - and we’re in grave danger of being overtaken by a dystopia where the big tech companies balkanize the Metaverse into a series of closed proprietary user-exploiting walled gardens, much like today’s incumbent chat silos - but even worse.
This is our chance to fix it before it’s too late, and Element is funding a small but highly targeted team to focus exclusively on building out open interoperable Metaverse over Matrix - ensuring that collaboration in 3D (and 2D) spatial environments in future is decentralised, secure and standards-based. This obviously ties in directly with the rest of the Beyond Chat projects listed above: it’s early days, but it’s incredibly exciting to imagine where we could end up if this works!
Finally, a question which has kept coming up while working on Beyond Chat projects has been whether to implement this new functionality as Matrix widgets, bake them into existing Matrix clients, or build them as domain-specific dedicated Matrix clients. But perhaps we’re thinking about this all wrong: what if your Matrix client was just a browser for Matrix rooms? Some of these could be chatrooms. Some of these could be VoIP/Video conferences or Discord-style voice/video rooms. Some of these could be message boards or mailing lists. Some of these could be collaborative editors or whiteboards. Some of these could be 3D views into the metaverse. Some of these could be rendered via widgets; some could be rendered natively if the client knows how. And some of these could even be good old web pages(!!!).
Imagine if your Matrix client was effectively a genuine browser of arbitrary decentralised realtime content? If your view into a Matrix room was just that: a full window view into that room, be it textual or 2D or 3D - and your Matrix client was just a browser which added the necessary chrome and navigation to help you tab between rooms, login and logout, manage your encryption, track who’s in the room, track your notifications, etc.?
Meanwhile, if you’re in a web browser, you might hop into a lightweight single-page domain-specific webapp which happens to use Matrix for collaboration. Or if you’re in a Matrix client/browser, you could hop to the same matrix URL to get at the same functionality with all the supporting chrome and UI overlays sliding in as needed…
Perhaps the vision of Matrix as the missing communication layer of the open Web is more literal than we ever thought. Eitherway, it will be fascinating to see how Applications Beyond Chat evolves over the next year.
2022
Now, I dare you to cross-reference all of the above with last year’s predictions for 2021 to see how we did :D In practice, the only things from the list we haven’t got to are peeking-over-federation (although arguably fast joins are a key part of that), account portability, and restoring incremental sign-up (although our new clients have it!).
So, here go the predictions for 2022 (keeping it short, otherwise it’ll be 2023 before this blog post gets finished…):
Client polish and performance - our prime directive is to ensure that Matrix clients can be built with UX polish and quality which exceeds our centralised alternatives. In practice, this means:
Element must spark joy. Ensuring Element’s Information Architecture continues to be simplified and refined, and that nobody who knows how to use a computer hits a WTF moment when first using the app. Never again do we want to see someone on Twitter saying “I have no idea how to use Matrix”.
Instant launch. With Sync v3 and matrix-rust-sdk we hope to make Element launch instantly on all platforms - including initial sync.
Fast joins. We should never get bored while waiting to join a room or accept an invite.
Spaces. While Spaces are already a huge improvement in letting users organise and discover rooms, there’s still much more to be done:
Flair - Users who are members of a space should be able to announce it loud and proud with a Flair badge on their avatar, like we used to with the old pre-spaces Communities feature (MSC3219 being the potential proposal).
Synchronising access controls - You should be able to apply access controls based on whether a user is a member of a given group (so that if you invite them to #moderators:example.com, they automatically get made moderator in all the rooms in a given space). It looks likely that this will be implemented at last using joepie91’s MSC3216 proposal for Synchronized access control for Spaces (rather than Matthew’s original MSC2962 - an excellent example of the community steering the spec process :)
Bulk joins - It should be a one-button operation to join all the rooms in a space.
**Subspaces **- as more and more spaces emerge, the ability to navigate them as a hierarchy becomes more and more useful. We want to get to the point where we can turn off the Matrix.org public rooms list, and instead present a Space tree of all the good rooms we know about in Matrix… delegating over curation to the wider community; building a huge USENET-style hierarchy of where to go in Matrix. To do that, we need subspaces to sing!
Removing communities/groups, which will then be entirely superseded by spaces.
**Threads **go-live!
Location share go-live
Pinned messages, so the most important messages are always visible to everyone n the room
Starred messages, so you never lose a message ever again
Custom emoji, finally merging in all the custom emoji work from the community.
matrix-rust-sdk
Element iOS on rust-sdk
Element Android on rust-sdk-crypto
…and experiment to see how matrix-rust-sdk feels on Web? It’s a real shame that Daydream got archived…
Encryption
Vodozemac in matrix-rust-sdk, maybe even elsewhere.
**Updated E2EE Audit **spanning vodozemac, olm+megolm, matrix-rust-sdk… and a representative sample of a typical Element+Synapse deployment.
DMLS - getting to the point where we can experiment with it in real clients.
Encryption Agility - the ability to migrate encrypted history is going to become really important as we evolve our E2EE, whether that’s by adding in post-quantum algorithms, or moving from Megolm to MLS, or any other shifts. We will need to start thinking about it in 2022.
Next-generation MSCs
Aggregations - finalising the foundational MSCs for aggregations, at last
Extensible events - finalising the foundational MSCs for extensible events, at last
**Sync v3 **- finalising the MSC and implementing it in matrix-rust-sdk
Fast joins - getting them implemented in Synapse and Dendrite
Peeking over federation - getting them implemented in Synapse and Dendrite
Extensible profiles - who needs a facebook wall when you have a profile room on Matrix?
Open ID Connect - using OIDC as an alternative auth mechanism for new clients.
Gitter parity
Importing the Gitter archives into Matrix via MSC2716
Implementing excellent public static Matrix archives (replacing both view.matrix.org and gitter.im’s static views)
Transfiguring Gitter into a Gitter-themed Element
Dendrite
**Parity with Synapse **- and out of beta, with any luck!
P2P Matrix
Exposing the normal Matrix network via P2P!
Multihomed accounts
Store and forward (if only by relaying via other P2P Matrix nodes)
**Low bandwidth transports **- via PineCoAP or similar
Making federation robust in a highly disconnected network.
Hydrogen
**Daily Driver **- making sure that Hydrogen can be readily used as a daily driver Matrix client, even if it lacks full parity with Element.
**Embeddable Hydrogen **- making the most of Hydrogen as a tiny lightweight PWA to embed it into existing websites.
Bots and Bridges
**Landing End-to-Bridge-Encryption **for all existing matrix-appservice-bridge based bridges
All the integrations!
First-class UI for configuring integrations!
Trust & Safety
Empower users to manage abuse within their communities.
Something we didn’t mention in 2021 is the increasing interest in building border gateways and hardware cross domain gateways to safely link different Matrix federations together. We expect to see a lot of activity in this space in 2022, and there should be some new MSCs too :)
Beyond Chat
**Metaverse on Matrix **- building out the dream as per above!
**Collaborative editing **- extending Matrix to store trees of events, and collaborate on them in realtime - starting with a collaborative editor!
File storage in Matrix - building out real-life file storage on top of Matrix.
So, there you have it. If you’ve got this far… it’s incredible; you’re amazing: thank you for reading! The sheer length of this update shows just how much Matrix has grown in 2021 relative to previous years; it’s frankly terrifying to imagine how long the equivalent post will be next year. We may have to change the format a little :)
And that’s a wrap for 2021: we hope you stay safe and have an excellent end of the year. Huge thanks for flying Matrix and supporting the project - we literally wouldn’t be here without you.
