Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
This week we have been preparing for IETF117, Matrix 1.8, Matrix 1.9, and Messaging Layer Security (MLS) for Matrix. Most of our work on globally interoperable communications is ongoing through the More Instant Messaging Interoperability (MIMI) working group at the IETF, and will be making significant strides in the coming days as we head to the IETF117 hackathon and meetup.
Over the last few months we've been working on a version of Linearized Matrix which supports the simplicity of linear event history while being fully compatible with today's Matrix network, and while we think that the 03 draft we wrote up accomplishes a lot of this, there's further work to be done to make it cleaner and easier to use. We've also been writing implementations of it to prove the semantics (and find areas which need improvement), starting with our cleanroom eigen-server TypeScript implementation and interoperating it with a branch of Synapse. During IETF117 we expect more implementations to sprout and have their interoperability tested - watch this space for updates on how that goes.
Aside from IETF117, we're continuing to look at the previously-selected Matrix 1.8 MSCs for release in mid-late August 2023. This might be slow over the next couple of weeks while half of us are at IETF117, but expect more forward progress when we get back. Matrix 1.9 is scheduled to be released sometime in November 2023, and a few months ago we said we were aiming to plan ahead for releases a bit more deliberately. Starting this week, we're accepting submissions for ideas and specific MSCs which need our attention in Matrix 1.9. If you have an MSC (current or future) which will need Spec Core Team (SCT) attention between August 2023 and November 2023, let us know in the SCT Office room. Once Matrix 1.8 is released (exact date TBD) we will have limited availability to add things to the Matrix 1.9 target - please raise your MSCs & themes as soon as possible. The current set of MSCs up for consideration can be found on the SCT Intake Board.
If you've made it this far in our weekly update, congratulations, and thank you. We expect things will rapidly start to happen with IETF117 kicking off tomorrow (July 22, 2023), and we will do our best to keep folks updated. Next week's TWIM in particular will have a post-IETF117 debrief for your reading enjoyment :)
As always, if you have any questions or concerns about what we're working on, visit the SCT Office and let us know. We can't promise a prompt reply (particularly during IETF117), but we will take a look when we can.
This MSC addresses a shortcoming in the current User-Interactive Authentication (UIA) mechanism where attempting to deduce the required authentication flows for an action will result in that action being carried out if it turns out no flows were required. This makes it tricky for a client to present a "are you sure you want to do X?" as a final step in completing an action that requires authentication.
The proposals aims to allow an OPTIONS pre-flight HTTP request to the same endpoint in order to retrieve the flows necessary, without actually carrying out the action. The proposal does note that using OPTIONS for this case is a bit non-standard though, and some clients may treat the typical 401 error code returned during User-Interactive Auth as a fatal error.
While this does address a flaw in the UIA system, it's worth noting that many other flaws exist! Matrix is planning to move over to an OpenID Connect-based authentication system in the not too distant future, which will likely have far fewer edge cases than our traditional, home-grown one. You can visit https://areweoidcyet.com/ for more information and to track the current progress on that front.
Given our commitment to open standards and interoperability, we’re delighted to see MLS be ratified by the IETF as RFC9420.
MLS is a new encryption standard defined by the IETF, the standards body that maintains much of what makes the internet work. In the same way that Transport Layer Security (TLS, another IETF standard) defines the way to provide encryption between users and servers, or between two different servers, MLS provides a standard way for users of a messaging service to communicate securely without servers being able to eavesdrop on their conversations.
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
Not a lot to say this week. The Spec Core Team is humming along with review, while we also wait for progress of various MSCs from their authors. The full list of what's in flight can be found in this week's Tuesday ping in the Office of the Spec Core Team room.
IETF and MIMI work is still continuing on in the background. Look out for a TWIM in the near future for an update to progress on that front!
This MSC defines an endpoint to send lots of state (max 50 at once) into a room in one go. This sounds useful for all sorts of tasks, and it's a wonder that it hasn't come up before.
If that sounds like an endpoint you'd like to go, give feedback on the MSC linked above!
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
Work to use Matrix as the standard for interoperable messaging at the IETF is continuing in full stride. At IETF 117 (July 22nd - 28th, 2023) we'll be talking about the precise requirements of an interoperable protocol, and encouraging Matrix be that protocol. Linearized Matrix is our proposal for the room model, with more updates expected in the coming days ahead of the submission deadline, meanwhile yours truly is working on using MSC1767 Extensible Events for a content format. Watch this space for updates leading up to IETF 117 🙂
We're also well on track to test interoperability of different Linearized Matrix implementations at the Hackathon - get in touch with us via the #sct-office:matrix.org if you're working on such an implementation so we can coordinate details. It's not too late to get started either; Linearized Matrix itself is relatively simple to implement compared to the full capability of Matrix, by design.
This MSC provides a means of establishing a trusted, secure communications channel across a potentially untrusted network. Subsequent MSCs could then use this channel to transfer details such as login tokens or key backup credentials in the context of setting up a new Matrix device. MSC3906 is one proposal that takes advantage of this.
This is just one piece of work building on the tree of MSCs supporting the shift of authentication in Matrix from home-brewed to OIDC. See https://areweoidcyet.com/ for more details on that effort.
Libera Chat recently announced their decision to opt-out of portalled rooms
from the Libera.Chat bridge instance hosted by the Matrix.org Foundation
(a decision we regret but respect).
This means that for the bridge to keep working, all of your portalled rooms
need to be turned into plumbed rooms before July 31st. All of this might be a
bit obscure, so let’s walk together through these concepts and give you the
tools to make sure the bridge keeps working for you.
We respect the decision but also recognise that this will be disruptive for
matrix.org users accessing IRC over the bridge.
Practically speaking, if you currently use matrix.org as a bouncer into Libera.Chat this will no longer be possible unless the admin of every room you inhabit is willing
to reconfigure the room for plumbing.
This post explains the situation as seen from the matrix.org side, what it means for matrix.org users and what to do next.
We launched the Matrix Public Archive publicly on June 2nd, 2023.
We decided to take it down on Sunday, June 25th out of precaution after a
member of OFTC staff warned us that the archive made the content of two OFTC IRC
channels bridged to Matrix available on the Internet.
After investigating the issue, we determined that the Matrix Public Archive's
behaviour was expected for these channels, given an IRC chanop had
explicitly configured the Matrix side of the rooms to be world-readable.
Let's talk about how room visibility works in vanilla Matrix, how it works with
bridges, and what are the next steps.
You might have seen the news already, but the Matrix.org Foundation is pleased to welcome the first public sector organisation as part of its membership: Gematik joined us as a Silver member!
Whether you're an individual, a business, a non-profit, a public sector organisation, you can join the Matrix.org Foundation as a member to support us in our mission and help us steer Matrix in the right direction!
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
Room version 11 has been accepted! A gentle reminder for Matrix client and homeserver implementations to update and incorporate the new changes. The full list can be found in the MSC itself (mainly changes to redaction semantics and related fields).
While this means that room version 11 is now considered stable, it's not recommended that homeserver implementations set their default room version for newly created rooms to 11 yet. We recommend waiting a few months for client and other homeserver implementations to gain support first.
Matrix has a concept of shared moderation policy lists - where you can create a room containing moderation actions that followers can apply to their own rooms, such as banning a particular known bad actor.
This MSC proposes to expand the list of possible types of recommendations with that of muting a user (removing a user's ability to send messages in a room). This could be especially useful if you moderate many, many rooms and have automation to apply moderation actions based off of a policy list room.
If such a policy change sounds useful to you, why not give the MSC a review and leave some feedback!
I've updated the Dash/Zeal Docset which you can use to read the Matrix Spec offline.
If you use Dash and installed it through the application's settings, an update should be available now. If you use Zeal, check out the update procedure on gitlab.com.
This week we released 1.87.0rc1. Please note that this will be the last release of Synapse that is compatible with Python3.7
and earlier. Now on to the highlights:
Add spam checker module API for logins
Fix forgotten rooms missing from initial sync after rejoining them
Remove experimental MSC2716 implementation to incrementally import history into existing rooms.
Fix a bug introduced in 1.57.0 where the wrong table would be locked on updating database rows when using SQLite as the database backend
and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at https://github.com/matrix-org/synapse/issues/new/choose.
Huge refactoring of Dendrite and gomatrixserverlib to pave the way for easier experimentation
A potential state reset when joining the same room multiple times in short sequence has been fixed
Several "membership" (e.g /kick, /ban) endpoints are using less heavy database queries to check if the user is allowed to perform this action
/3pid endpoints are now available on /v3 instead of the /unstable prefix
Support for connecting to appservices listening on unix sockets has been added (contributed by cyberb)
Admin APIs for token authenticated registration have been added (contributed by santhoshivan23)
...and a whole lot more. Check out the release notes for the full set of changes!
As always, feel free to stop by #dendrite:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.
After long time of inactivity in chooj's repo because I was busy with other stuff, we now have many improvements. Two most important changes are not user facing yet very important for development of chooj in the long term. First, the UI stuff have their own repository and are a separate NPM library. Second, I have almost converted the codebase from Javascript to Typescript. There are other small changes. Many bugs have been fixed. If you had problem logging in with chooj on your feature phone, give the build specified in this issue a try. It should have solved the bug. And please let me know if it fixes the problem, or if you have any other issue.
Element X Android is making big progress to become the fastest Element application ever developed! The application is now using the new Room List API from the Matrix SDK.
The application is getting lots of UI / UX polishment, as we are integrating the latest design.
Last but not least, the app has been renamed to “Element X” (with a space) and got a brand new icon!
We've made further steps towards fixing stuck notifications on nightly. The unread dot is now more reliable -- especially when used with the "mark room as read" functionality. We've also fixed reactions gone missing when the reacted to event isn't yet synced. Our plan ahead consists of re-triaging existing issues to surface cases we haven't yet accounted for. Afterwards we'll push ahead with MSC3981 which is already implemented both client- and server-side but needs testing. For further details, please see the tracking issue.
Our work on improving the notification settings is being finalised. We've conducted user testing this week and are preparing for a labs'ed launch.
As part of our integration with Compound, our new design system, the first pieces of typography and colour updates are landing on nightly. More news in this area soon.
Finally, we've also progressed on integrating OIDC and managed to get the login flow working in a POC manner.
Element Android 1.6.3 is now available for 20% of the users in the PlayStore. We are confident that we will reach 100% deployment by the end of next week, and then we will release the app on F-Droid. The roll out is slower than usual since this version is integrating the Crypto Rust SDK (the new Matrix SDK developed in Rust and also used by Element X iOS) and the migration of user private data is quite a sensitive area.
@sctlib/rtc now has support for Matrix /sendToDevice signaling.
It's a web-component that tries to offer a user interface for peers to connect via WebRTC
There are different "manual" signaling methods (such as copy/pasting the WebRTC connection data by hand, from one peer to the other), and the Matrix API /sendToDevice endpoint is the new addition.
It works with authenticated matrix users, as well as with guest user/device.
All this is a prototype and experimentation with client side browser based apps (with js/html/css/web-components/npm-packages), using @sctlib/matrix-room-element and its new api.js.sendToDevice method.
One of the thing I enjoy with this project, is that it is web-component based; meaning the new HTML custom DOM element, has a "clear API" through it's attribute api, methods, events (just like an <img/> or <video/>, or <form/> etc.).
allow to forget rooms (delete room specific content from database and cache) -> rewrite of the cache to allow indexes
PowerLevelsEventContent with type safe "events"-field (e. g. allow content.events.get<MessageEventContent>() additionally to the old way content.events["m.room.message"])
Introduce module trixnity-crypto-core and replace native crypto algorithms using native APIs (CoreCrypto on apple and OpenSSL on linux/mingw targets)
The library is fast approaching the 0.8 with the process being much steadier than before, now that we actually practice smaller, more frequent releases - thanks in no small amount to NeoChat people, nicely prodding the author of these lines on a regular basis. The release notes (very short, apparently we've got the beta right) are, as usual, at the project's Releases page and the final release can be expected some time next week, if we don't have unexpected showstoppers.
And just in case someone doesn’t know where to find us - you’re welcome in #quotient:matrix.org!
Have you ever had the need to set the same power levels for the same users in the a lot of rooms?
It's fairly tedious.
That's what room-architect tries to solve. You create groups of users and groups of rooms and set power levels to room-group<->user-group pairs, and this bot will keep the power levels there (as long as the Bot has the necessary power levels itself of course).
I have more planned, and a few more ideas beyond those, if you want to help, open a pull request on the project's Codeberg repository or open an issue if you find a bug. There is no Matrix-Room for this project yet, but I might create one if there seems to be interest.
Introducing Gate Bot, a Matrix bot that empowers Matrix room owners to create a safety gate between incoming users and their community. Through the use of verification checkpoints, including CAPTCHAs (with ongoing exploration of alternative methods), Gate Bot can effectively thwart automated spam bots while ensuring the protection of communities and their members.
Invite Gate Bot to a room to get started, then follow our setup guide on Github.
Last weekend, I made a few small changes that fixed or worked around minor bugs and usability issues that were brought to my attention by community members. This should make interactions with the bot match expectations more closely. Hooray for collaboration and iteration!
DevConf.CZ, an annual, Red Hat sponsored, open source community conference in Brno, CZ, was held on June 16 - 18.
This year, the conference was piloting Matrix as a primary communication platform and this is a short summary of how it went.
In the end, we went the self-hosting way!
Our hero @duck:milkypond.org from Red Hat's open source program office team did all the heavy lifting by setting up the Synapse and all the necessary services around it, incl. Mjolnir.
We've tried to use conference-bot with schedule in compatible json, but DevConf not using Pentabarf turned out to be too limiting, at least for our use-case.
Taking advantage of the Spaces feature, we created #2023:devconf.cz with three sub-spaces: 'General', 'Sessions', and 'Workshop & Meetups'. Attendees were suggested to join the 2023 space and go from there, as opposed to sharing invites to specific rooms or sub-spaces.
@inknos:snag.social and myself, @mhoyer:snag.social wrote a simple bot that was creating Q&A threads for each talk. It also pinned this message/thread. Online and in-person attendees were suggested to use the Q&A threads to ask questions and session chairs asked them to the speaker(s) in the time dedicated to questions and answers.
'Sessions' space was a home for rooms, which were an extensions of the real-life auditoriums. These rooms had a widget with a Youtube live stream and Q&A threads.
All rooms had a widget with a schedule for said room. The widget was pointing to a website designed to be used as digital signage, so it reflected any schedule changes immediately.
Compared to FOSDEM, and given the size of the conference, we decided to have only one general-purpose public room, which I think worked well. This way, organizers are able to do @ room pings there instead of creating a dedicated "Announcements" room for example.
I should also mention we've put together a Matrix section at devconf.cz web FAQ section: https://www.devconf.info/cz/faq/#matrix
The organization team did a great job communicating everything to the attendees, even the fact that it is a "pilot" and things might break (they didn't, yay!).
I don't have the exact numbers, but I believe there were 300+ users in the Main Chat room, which as far as I can tell is comparable to any chat platforms used in previous years. Not bad for a first year, especially since we only had a very limited time-frame to make it happen.
@dvolavko:matrix.org, the organizer of DevConf.CZ, shared this:
"""
Overall positive feedback. I think we should fully transition to Matrix after this experience. We were collecting attendees to telegram chat for the past 5 years and we reached a similar number on Matrix in 3 days.
""
TRBot is software written in C# and .NET 7 for playing video games collaboratively through an easy to learn, hard to master text format - think Twitch Plays Pokémon to the next level and with any game. This week we released version 2.8.0, which adds support for reading inputs in unencrypted Matrix rooms! On top of TRBot's built-in Twitch, IRC, XMPP and now Matrix support, Matrix bridges will unlock a multitude of other services to run TRBot on for more players to join in on the fun.
Join our room at https://matrix.to/#/#TRBot-Dev:matrix.org for development discussion and updates! We also use TRBot to host collaborative play streams through a community called https://matrix.to/#/#type2play:matrix.org.
Did you ever have a list of email addresses and Matrix rooms (or spaces) which you wish to invite them to? And you don't know their Matrix usernames or if they even have a Matrix account yet? Then this is going to be for you. ✨
For this year's edition of the Berlin University of the Arts open house day presentation (come visit July 21st - 23rd if you are around!) students and others are going to make use of Matrix once again to digitally present and announce their art pieces, installations, performances, events -- just like they did for the last two years. As part of the digital programme we kept running into the same issue: we have a big Matrix space structure representing an existing hierarchy of faculties, institutes, campus buildings, rooms, study programs, classes, seminars and so on. And with each of them we have a list of maintainers as in people who are responsible.
While we're still mostly working on other projects, we wrote the matrix-email-onboarding microservice to invite users to Matrix rooms (or spaces) via their email addresses, even before we know if they actually have a Matrix account or not.
It comes with a CLI tool to send out emails 📨 with a link (containing a secret token) for your users to click on (screenshot 1), and
A Node.js server-side application to handle web requests to
(1) check a given secret onboarding token 🔍 and list the linked Matrix rooms or spaces (screenshot 2)
(2) let the user sign in ☑️ with their Matrix account and automatically join the given rooms or spaces
(3) (optionally) promote those newly joined users to become moderators or administrators 🧑⚖️
We've decided to CC0 it. So go crazy, make use of it in your public institution, use it for your company, tinker around for yourself, create Issues or send Pull Requests on GitHub and do let us know what you think! Looking forward to all of it. 🥰
We were already proud to announce
that the national agency for the digitalisation of the healthcare system in
Germany (gematik) had selected Matrix as the open standard
on which to base all its interoperable instant messaging standard, back in 2021.
We are now delighted to let the world know that they are doubling down on
sovereignty and sustainability: gematik is the first organisation of the public
sector to join the Matrix.org Foundation as a Silver member.
Collaboration in the public sector
Our friends at the FSFE have been calling for software used
in public services to be free software in their
Public Money Public Code campaign. As
advocates of open standards and an open source project ourselves, this is
something we can get behind.
Software development can be an impenetrable world for people who don’t work in
the field. It can sometimes be difficult for people outside of our industry to
understand the importance of bitrotting and refactoring. One very unfortunate
effect of this is that new features are easy to fund because they feel very
tangible, but the most critical housekeeping work is not as appealing.
Yet, without regular refactoring to clean things up, it gets increasingly costly
and difficult to add new features. Counterintuitively, spending money on “the
boring tasks” is the most efficient use of money: without it the technical
stack would become either obsolete, bloated, or both, and it would be much more
costly to move to something else or maintain an in-house fork.
We’re very happy gematik is doing the right thing by supporting the technical
stack it builds TI-Messenger on. By supporting the Matrix.org Foundation,
gematik contributes to the sustainability of the protocol powering the
communications of the German healthcare system… but not exclusively.
Sharing costs across public services, and with the private sector
Matrix is an open standard, which means not only everyone can use it: when
someone contributes to Matrix, everyone benefits from it. This makes Matrix
particularly interesting for the public sector: if the German healthcare
contributes to Matrix, the German Armed Forces
benefit from it, and the other way around. It allows both to contribute less
of their budget, instead of contributing each to an entirely different
product. The German Federal Ministry of Defence already actively contributes
to Matrix development and funding via its public IT services provider BWI GmbH,
who relies on Element’s consulting services to develop their own Matrix-based
messenger.
But Matrix being open source, it also allows the public and private sector to
share the costs of maintenance by design. The public sector benefits from
the contributions of the private sector to Matrix, and the opposite is true as
well.
The Foundation plays a critical technical and social role in this system: it
centralises and curates contributions to the protocol so it remains unbiased,
coherent, and efficient.
This is just a beginning
We’re extremely happy to welcome the first public sector organisation in the
Matrix.org Foundation! Given how popular Matrix is among governments and the
public sector in general, we know this is just a beginning: it would be
illogical to deploy any solution at a large scale without contributing to its
sustainability.
Whether you’re an organisation from the public or the private sector, looking to
cut costs down by building on a common, standard and reliable foundation, you
can support Matrix and
join the Foundation today.
Thanks again to Beeper for all their contributions to the Matrix ecosystem, and we can't wait for more prospective members to show that they really mean to stand for open, decentralised secure communications 🚀
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
The SCT has largely been business as usual for the last week: progress is being made on the MSCs we know about, things are entering/completing FCP, etc. There has been some activity around MSC3820: Room Version 11 though, largely to ensure Linearized Matrix has a clean place to start building its own room version. It's also been about a year since Room Version 10 was cut, making it a good time to push some cleanup work out into the world.
If you'd like to test room version 11, update your Synapse and join #v11-opt2:t2l.io. It should look largely the same as any other room, but has changes that client developers should note around redactions.
For Linearized Matrix news, there's effort going into specifying the complete semantics and behaviour of Matrix's transport. The in-progress draft can be read here and should be published as an 02 in the coming days. 03 is expected to contain specific details around the MLS constraints. For clarity: the draft is an IETF Internet-Draft (I-D), aimed at a different audience than MSCs normally would. While the I-D makes little mention of it, existing Matrix servers participating in rooms with Linearized Matrix servers will continue to be full mesh, though Linearized Matrix servers will rely on a hub to send their events. DAG servers are not to rely on a hub.
Random MSC of the week
This week's random MSC is MSC3160: Message timezone markup! If you've ever tried to say "does 15:00 CET/13:00 UTC/09:00 EST/06:00 PST work for you?", this is the MSC that fixes that problem.
This week we released 1.86.0. Here are a few of the highlights:
Fix an error when having workers of different versions running.
Experimental MSC3861 support: delegate auth to an OIDC provider
Correctly clear caches when we delete a room
Expose a metric reporting the database background update status.
and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at https://github.com/matrix-org/synapse/issues/new/choose.
We finally released v0.4.0 this week with support for device verification and cross-signing.
Try them out at hydrogen.element.io by enabling cross-signing under Experimental Features in the settings.
This release also includes numerous bug fixes, see the release notes for more info.
We’re continuing work on the performance of our room list. It’s important to us that the app feels speedy and seamless so we’re spending the time to really nail these fundamentals.
We’re also finalising some functionality around message actions (like forwarding) and improving the flow when leaving rooms
This week our team has been continuing to work on message actions, finalising forwarding messages and reporting messages. Next we’ll move onto the copy function.
We’re also refining the design on some of our settings pages.
And we are integrating the new Room list API from the Rust SDK.
The web team is still hard at work uncovering and fixing bugs relating to stuck notifications.
Along with fixing bugs we’re also about to start testing our updates to the notification settings pages and expect these to be in labs in the next release
Our team is also making progress against our accessibility goals. Our current focus is improving the colour contrast throughout the app by updating our colour palette.
Along with the above we’re also working on integrating the new OIDC pieces as this new auth system will bring many improvements.
New German episode:
Meet Simon Dürsch, who is a founder of https://clup.life and passionate about collaboration within associations, clubs and similar communities. Out of his own needs to bring together people on different chat platforms, he's built a service to create bridged community rooms.
As an active follower of Matrix news, chat bridging (e.g. from and to WhatsApp) is probably no news to you, however, the interview shows that Matrix still has a lot of untapped potential to enable communication of currently fragmented communities.
On August 05-06 the annual Free and Open Source Conference (short FrOSCon) will take place at the German University of applied Sciences Bonn Rhine Sieg.
There is great interest in Matrix in Germany and this year in particular one of FrOSCon's focus aspects is "Open Source in public administration" which seems a great fit with Matrix as well.
Plus, of course it's always fun to meet the community!
A small team of volunteers from the community has gotten together to organize both a Devroom and a Booth/Stand. Please find last week's announcement for more detail.
We need your help!
You can help us out by:
submitting a topic for a talk or workshop you want to give (🇩🇪 or 🇬🇧) - we need at least a title and duration until July 2 23:59 CEST!
helping out at the stand
helping to manage the devroom! E.g. if you are versed with recording and broadcasting tech, that would help us make the content accessible beyond the in-person devroom
