🔗Matrix Live

🔗Dept of Status of Matrix 🌡️

Thib (m.org) reports

The Foundation is at a crossroads. We need to raise an additional $610K to break-even, and more immediately to raise $100K to keep our bridges running.

As a neutral custodian for the specification and much more, the Foundation is key to the success of Matrix. It is time to step up for it.

Read the full post on our blog

🔗Dept of Governance ⚖️

Gwmngilfen reports

🔗Announcing the Governing Board Working Groups process

The Governing Board has news! If you have been itching to know how to get involved, we are now ready to get you ... on-Board! 🥁 😀

The Working Groups are the beating heart of the GB - they get the work done. So naturally people have been asking "how do we make one?" and "what is expected of a Working Group?"

🔗Creating a Working Group

The process is fairly simple:

• First, find some people who want to work on the problem - we would suggest at least 3, but the more you have the better, as it shows the level of interest in the issue.
• Second, write down a charter for your Group - this doesn't need to be huge to start with, just a few sentences about what you want to be responsible for and the outcomes you want to achieve.
• Finally, get a Board Member to sponsor you - this means finding a Board Member who agrees with the work you want to do, and will act as your link to the rest of the Board. The #governing-board-office:matrix.org is a great place to start conversations about WGs and look for sponsors. If in doubt, ping me there ( @gwmngilfen:matrix.org ) and I will help if I can.

Once you have that done, the Board Member will discuss it with the rest of the GB, we'll put it to a vote, and if it passes, you're in! (If it doesn't, we'll be sure to pass back what feedback we can about why not).

We would advise making noise about your proposals for Working Groups in the community to rally support and/or new members to get work done. TWIM is a good place for that 😛

🔗Expectations of a Working Group

Working Groups are well named - they work. Some will provide advice & documents on a topic, others may produce code or similar outputs (think, a Docs WG?) but all have work to do. So, obviously you'll want to get on with that.

We also expect that:

• Working Groups will have at least a Matrix room to discuss work in asynchronously

• they will have regular meetings ("regular" is different for different groups, but we would expect not less than monthly). These could be video or chat meetings.

• they take minutes of the meetings - the Board member can help here, but someone should take notes if they are not available.

  • These minutes get passed up to the rest of the Board so we can all be kept up to date at a high level

Clearly there are also some longer term things that we expect, like an expectation to work well with other Working Groups, to build consensus for decisions, etc. The GB can help if things need unblocking, of course.

🔗Documentation

We do need a place to record the Working Groups, what exists already, what they do, how you get involved. This will be added to the Matrix.org website SOON™️

🔗Initial Working Groups

All of this is theoretical until we start creating some groups, so .. let's hear your proposals (and I have a few to post in a moment)! Let's get some work done 💪

HarHarLinks announces

🔗New GB Working Groups - call for members

Working Groups are the core of how the Governing Board orchestrates its work. We have some new ones for you to consider (for the first time 🎉)

🔗Website WG (proposed)

The GB is considering a proposal for a Website WG! @HarHarLinks has written a charter regarding how to get work done for the main Matrix website, and has a good initial member list. While this is de-facto work already being done, we'd like to make it official - it's been proposed by @HarHarLinks so if this sounds like something you'd be interested in, register your interest with them!

🔗Events WG (proposed)

The GB is considering a proposal for a Events WG! This would cover CfPs, staffing booths, merch, event tooling (Pretix box, etc) and so on. While this is de-facto work already being done, we'd like to make it official - its fairly detailed charter been proposed by @HarHarLinks so if this sounds like something you'd be interested in, register your interest with them!

Gwmngilfen reports

🔗Ideas for New GB Working Groups

In addition to the in-flight proposals from HarHarLinks, I have a couple of ideas that need input to get started...

🔗Documentation WG (idea)

I think we could benefit from a Documentation Working Group in Matrix. The Spec pages are excellent, but much of the rest of our docs falls to the general website team, and we see a lot of copies of things like https://doc.matrix.tu-dresden.de/en which suggest to me that people aren't finding our docs sufficient?

So, without wanting to downplay the awesome work that has gone before, I think a dedicated Docs group could try to help specialise the various people working on the website, as well as provide a clear place to report issues with our materials. I'm willing to propose this, if you'd like to discuss it (or think it's an awful idea), please reach out to me ( @gwmngilfen:matrix.org )! in #governing-board-office:matrix.org

🔗New User Experience WG (idea)

Another group I'm thinking about is the New User WG - this would be focussed on how we get more people to Matrix, and improve those first few minutes/hours/days in our ecosystem - and how to gather their feedback effectively.

During the Matrix Unconference in Brussels, I hosted a session on this, and in just 45 mins we made 2 pages of ideas, so I think it's a rich area. Outputs would be advice/suggestions to other parts of the ecosystem for how we can make things better for our newer (and especially non-tech) users. I'm willing to propose this, if you'd like to discuss it (or think it's an awful idea), please reach out to me ( @gwmngilfen:matrix.org ) in #governing-board-office:matrix.org

Got ideas of other WGs? Talk to us in #governing-board-office:matrix.org! Onwards!

🔗Dept of Trust & Safety 🤗

Jim announces

An update on changes to the Matrix.org room directory: https://matrix.org/blog/2025/02/curated-room-directories/

🔗Dept of Clients 📱

🔗Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Doug says

• The next release of Element X iOS has an updated Rust SDK and as such, we will no longer support the Sliding Sync proxy - native Simplified Sliding Sync via your homeserver is the only sync option.
• We made huge progress on embedding the Element Call web app into the Element X (rather than loading it from the web) - we are able to participate in calls, and are now just adapting the code to fully support localisation when embedded.
• We have started implementing pills for rooms and events, just as in Element Web. The first step is to replace permalinks rendered in the timeline with these new pills.
• We had a nice little external contribution that fixes @mention suggestions to work from anywhere in your message and not just at the end. Thanks Vickoo 🙌

🔗Element X Android (website)

Android Matrix messenger application using the Matrix Rust SDK and Jetpack Compose.

Benoit reports

Working on several features currently:

• swipe between media: improvement when coming from the pinned Events list. Now merged!
• joining room by alias (can also be called address)
• user interactive verification. It's currently possible to verify your own sessions, it will be possible to verify other users
• fixing bugs! We have fixed a bunch of ANR issue, the first stats from the PlayStore are showing a drop in the ANR occurrences.
• new translations into Norwegian and Turkish. Thanks for all the contributors! As a reminder, anyone can help translating the mobile applications from here: https://localazy.com/p/element/ . Translations are shared between the iOS and Android application.

🔗Dept of SDKs and Frameworks 🧰

🔗matrix-rust-sdk (website)

Next-gen crypto-included SDK for developing Clients, Bots and Appservices; written in Rust with bindings for Node, Swift and WASM

poljar reports

It's been a quieter week, but progress continues! The event cache is receiving its final polish, including performance improvements, as it nears prime time.

The authentication system is also seeing ongoing enhancements, thanks to Kévin Commaille.

Additionally, work has begun on the successor to MSC3061, aiming to allow newly joined users to access the history of encrypted rooms.

🔗Event Cache Updates

• Simplified the flow when resolving a gap (#4691)
• Streamlined back-pagination logic (#4689)
• Implemented lazy-loading for EventCache (#4632)
• Significantly improved reply replacement speed by introducing an index over replies (#4669)

🔗Authentication Improvements

• Removed support for deserializing the old UserSession format that contained the issuer_info field (#4679)
• Adopted the new GET /auth_metadata Matrix API endpoint (#4673)
• Removed the method for authorizing arbitrary scopes (#4664)

🔗Other Notable Changes

• Added a new constructor to InboundGroupSession for easier creation from an m.room_key event (#4688)
• Renamed snapshot files to reduce filename length, allowing Windows users to work on the codebase again (#4625)
• Enabled history visibility overrides when creating a room (#4682)
• Ensured that paginations and syncs don’t add events to the pinned events timeline (#4645)

🔗Dept of Ops 🛠

🔗synadm (website)

Command line admin tool for Synapse (Matrix homeserver)

jacksonchen666 (they/it) announces

We have released synadm v0.47! This release packs a few features:

• Connection errors to Synapse should be more reasonably small and easy to understand, thanks to #168.
• synadm user redact is now added, which redacts a user's messages. Supports local and remote users, but intricate details are up to Synapse (see "Redact all events of a user").
• You can filter for empty rooms on the server side in synadm room list with --empty or --not-empty. This is in addition to synadm room purge-empty
• More options were added to synadm user list to match what Synapse supports
• synadm media quarantine and unquarantine now have the -U/--mxc-uri argument to pass MXC URIs to

That's all in code. There are a few changes in documentation, including the theme, listed on the changelogs.

And of course, a changelog is also available on GitHub. Our room is at #synadm:peek-a-boo.at if you have any questions or other stuff.

🔗matrix-docker-ansible-deploy (website)

Matrix server setup using Ansible and Docker

Slavi says

thanks to Aine of etke.cc, matrix-docker-ansible-deploy now supports FluffyChat Web as an additional Matrix client you can self-host.

To learn more, see our Setting up FluffyChat Web documentation page.

Slavi announces

Thanks to Zepmann, matrix-docker-ansible-deploy now supports bridging to Bluesky via mautrix-bluesky.

To learn more, see our Setting up mautrix-bluesky documentation page.

🔗Dept of Interesting Projects 🛰️

🔗Matrixbird (website)

ahq announces

Matrixbird is an experimental "mail over matrix" idea I've been working on. It supports both traditional email and secure "matrix email" (local and federated) in a unified client.

🔗Matrix Federation Stats

Aine [don't DM] reports

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 10771 Matrix federateable servers have been discovered by matrixrooms.info, 3202 (29.7%) of them are publishing their rooms directory over federation. The published directories contain 21078 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

🔗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.

🔗#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

🔗That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

To learn more about how to prepare an entry for TWIM check out the TWIM guide.

After a successful 2024 with a lot to be proud of, and a Matrix Conference that brought our community together to celebrate 10 years of Matrix, we step into 2025 with a light budget and a mighty team poised to make the most of it!

Our priorities remain to make Matrix a safer network, keep growing the ecosystem, make the most of our Governing Board, and drive a fruitful and friendly collaboration across all actors.

However, whether we will manage to get there is not fully a given.

Continue reading…

As of yesterday, Matrix.org is using a curated room directory. We’re paring down the rooms that are visible to a collection of moderated spaces and rooms. This is an intervention against abuse on the network, and a continuation of work that we started in May 2024.

In early 2024 we noticed an uptick in users creating rooms to share harmful content. After a few iterations to identify these rooms and shut them down, we realised we needed to change tack. We landed on first reducing the discoverability and reach of these rooms - after all, no other encrypted messaging platform provides a room directory service, and unfortunately it can clearly serve as a mechanism to amplify abuse. So, in May 2024 we froze the room directory. Matrix.org users were no longer permitted to publish their rooms to the room directory. We also did some manual intervention to reduce the size of the directory as a whole, and remove harmful rooms ahead of blocking them.

This intervention aimed at three targets:

• Lowering the risk of users discovering harmful rooms
• Stopping the amplification of abuse via an under-moderated room directory
• Reducing the risk for Matrix client developers for app store reviews

In truth, the way room discovery works needs some care and attention. Room directories pre-date Spaces, and some of the assumptions don't hold up to real world use. From the freeze, and the months since, we've learned a few things. First, the criteria for appearing in a server's room directory in the first place is way too broad. Also, abuse doesn't happen in a vacuum. Some rooms that were fine at the time of the freeze, are not now. There are a few different causes for that, including room moderators losing interest. We looked for criteria to give us the confidence in removing the freeze, and we hit all the edge cases that make safety work so challenging.

Those lessons led to a realization. One of the values of the Foundation is pragmatism, rather than perfection. We weren't living up to that value, so we decided to change. The plan became simpler: move to a curated list of rooms, with a rough first pass of criteria for inclusion. In parallel, we asked the Governing Board to come up with a process for adding rooms in the future, and to refine the criteria. We've completed the first part of the plan today.

🔗What comes next

There's plenty of scope for refinement here, and we've identified a few places where we can get started:

• The Governing Board will publish criteria for inclusion in the Matrix.org room directory. They'll also tell you how you can suggest rooms and spaces for the directory.
• We're going to recommend safer defaults. Servers should not let users publish rooms unless there are appropriate filtering and moderation tools in place, and people to wield them. For instance, Element have made this change to Synapse in PR18175
• We're exploring discovery as a topic, including removing the room directory API. One promising idea is to use Spaces: servers could publish a default space, with rooms curated by the server admin. Our recent post includes some other projects we have in this area: https://matrix.org/blog/2025/02/building-a-safer-matrix/

🔗FAQs

What criteria did you use for this first pass?
We used a rough rubric: Is the room already in the room directory, and does the Foundation already protect the room with the Matrix.org Mjolnir? From there, we extended to well-moderated rooms and spaces that fit one of the following:

• Matrix client and server implementations (e.g. FluffyChat, Dendrite)
• Matrix community projects (e.g. t2bot.io)
• Matrix homeserver spaces with a solid safety record (e.g. tchncs.de, envs.net)

Why isn't the Office of the Foundation in the directory?
It didn't exist before May 2024, so the Office has never been in the directory. We're going to add it in the next few days, with a couple of other examples that fit our rough rubric.

How do I add my room/space to the list?
At the moment, you can't. The Governing Board will publish the criteria and the flow for getting on the list.

What do I do if I find a harmful room in the current directory?
You shouldn't, but if a room does have harmful content, check out How you can help

🔗Dept of Status of Matrix 🌡️

🔗Trust & Safety

Jim announces

If you are wondering what the Foundation Safety team get up to, and what we have planned, we have an update for you. Check out the post: Building a Safer Matrix

🔗Dept of Spec 📜

TravisR announces

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.

🔗MSC Status

New MSCs:

• MSC4264: Tokens for Contacting Accounts
• MSC4265: Data Protection Officer contact in /.well-known/matrix/support
• MSC4266: Policies in /.well-known/matrix/support

MSCs in Final Comment Period:

• No MSCs are in FCP.

Accepted MSCs:

• No MSCs were accepted this week.

Closed MSCs:

• No MSCs were closed/rejected this week.

🔗Spec Update

Lots of MSC implementation and iteration is happening behind the scenes at the moment, leading to not very exciting Spec Core Team (SCT) updates :) As this implementation work progresses, the Matrix 2.0 MSCs in particular will continue to push forwards towards acceptance.

In the meantime, early versions of Extensible Profiles is up for review and today's blog post "Building a Safer Matrix" hints at some T&S spec changes expected soon.

The next spec release is expected in early March 2025 - if there's MSCs you think should be included there, let the team know in the SCT Office!

🔗Informal TI-Messenger Spec Discussion

Johannes reports

@this-week-in:matrix.org for people interested in informally discussing the Matrix-based TI-Messenger (TI-M) spec, as of today we have a public room: https://matrix.to/#/#tim-spec:matrix.org

If you haven't heard of TI-M before, in a nutshell it's a chat standard for the German healthcare system.

Continue reading…

N.B. this post is also available in German below.

🔗Introduction

Right now, the world needs secure communication more than ever. Waves of security breaches such as the “Salt Typhoon” compromise of the telephone network’s wiretap system have led the FBI to advise US citizens to switch to end-to-end-encrypted communication. Geopolitical shifts painfully highlight the importance of privacy-preserving communication for vulnerable minorities, in fear of being profiled or targeted. Meanwhile the International Rules-Based Order is at risk like never before.

We built Matrix to provide secure communication for everyone - to be the missing communication layer of the Open Web. This is not hyperbole: Matrix is literally layered on top of the Web - letting organisations run their own servers while communicating in a wider network. As a result, Matrix is “decentralised”: the people who built Matrix do not control those servers; they are controlled by the admins who run them - and just as the Web will outlive Tim Berners-Lee, Matrix will outlive us.

Matrix itself is a protocol (like email), defined as an open standard maintained by The Matrix.org Foundation C.I.C - a UK non-profit incorporated in 2018 to act as the steward of the protocol; to coordinate the protocol’s evolution and to work on keeping the public Matrix network safe. The Foundation is funded by donations from its members (both individuals and organisations), and also organises the Matrix.org homeserver instance used by many as their initial home on the network.

Much like the Web, Matrix is a powerful technology available to the general public, which can be used both for good and evil.

The vast majority of Matrix’s use is constructive: enabling collaboration for open source software communities such as Mozilla, KDE, GNOME, Fedora, Ubuntu, Debian, and thousands of smaller projects; providing a secure space for vulnerable user groups; secure collaboration throughout academia (particularly in DACH); protecting healthcare communication in Germany; protecting national communication in France, Germany, Sweden and Switzerland; and providing secure communication for NATO, the US DoD and Ukraine. You can see the scope and caliber of the Matrix ecosystem from the talks at The Matrix Conference in September.

However, precisely the same capabilities which benefit privacy-sensitive organisations mean that a small proportion of members of the public will try to abuse the system.

We have been painfully aware of the risk of abuse since the outset of the project, and rather than abdicating responsibility in the way that many encrypted messengers do, we’ve worked steadily at addressing it. In the early days, even before we saw significant abuse, this meant speculating on approaches to combat it (e.g. our FOSDEM 2017 talk and subsequent 2020 blog post proposing decentralised reputation; now recognisable in Bluesky’s successful Ozone anti-abuse system and composable moderation). However, these posts were future-facing at the time - and these days we have different, concrete anti-abuse efforts in place.

In this post, we’d like to explain where things are at, and how they will continue to improve in future.

🔗What we do today

The largest use of our funding as a Foundation is spent on our full-time Safety team, and we expanded that commitment at the end of 2024. On a daily basis, the team triage, investigate, identify and remove harmful content from the Matrix.org server, and remove users who share that material. They also build tooling to prevent, detect and remove harmful content, and to protect the people who work on user reports and investigations.

The humans who make up the Foundation Trust & Safety team are dedicated professionals who put their own mental health and happiness in jeopardy every day, reviewing harmful content added by people abusing the service we provide. Their work exposes them to harms including child sexual exploitation and abuse (CSEA), terrorist content, non-consensual intimate imagery (NCII), harassment, hate, deepfakes, fraud, misinformation, illegal pornography, drugs, firearms, spam, suicide, human trafficking and more. It’s a laundry list of the worst that humanity has to offer. The grim reality is that all online services have to deal with these problems, and to balance the work to detect and remove that content with the rights of their users. We’re committed to that work, and to supporting the Trust & Safety team to the best of our ability — we are very grateful for their sacrifice.

Continue reading…

The Matrix.org Foundation and its growing community were once again present at the biggest OSS conference in Europe, and it's been a tremendous success! It was an opportunity for us to gather, share ideas and debate about ongoing topics, meet the broader FOSS community and present our work.

🔗Fringe Event

With 8000 visitors, FOSDEM is primarily a place to share your work with others and present the latest developments to those interested. But it's not necessarily the best venue for conversations within the community about topics that are still in-flight.

Because so many people are doing the trip to gather in a single city, it remains a good opportunity to gather your own community in a more intimate setting. This is precisely what Fringe Events happening before or after FOSDEM are about.

Continue reading…

🔗Matrix Live

🔗Dept of Status of Matrix 🌡️

Quentin Gliech reports

This week we released Matrix Authentication Service 0.13.0!

This is a big release, as we haven't done one since September.

It is fixing a lot of small issues, but here are a few of the big highlights:

• The email verification has been completely reworked, meaning that accounts don't require a valid email address on them anymore! They are still required for open password registrations, but MAS won't nag you anymore to add an email to your account.
• No more spurious logouts when consuming a refresh token! That was a recurring annoyance for people using Element X in poor network conditions.
• It now reliably provisions users to Synapse! Sometimes, MAS would just stop provisioning new sessions if, for some reason, it lost connections to Postgres. This is a thing of the past, as now MAS has a reliable job queue.
• New translations! MAS is now available in Czech, Dutch, Estonian, English, French, German, Portuguese, Simplified Chinese, Swedish, and Ukrainian. If you'd like to help MAS get translated to your language, head out to our Localazy project
• Better support for non-OIDC upstream OAuth 2.0 providers. Support for 'social login' options like Google or Sign-in with Apple went from 'good' to 'great', with many UI improvements.

Upgrading should be as easy as grabbing the latest Docker image or the pre-built binaries, restarting the service and voilà!

Feel free to stop by #matrix-auth:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.

Continue reading…

🔗Dept of Status of Matrix 🌡️

Thib (m.org) announces

FOSDEM was a huge success for the Matrix.org Foundation and community this year again!

• 🍕60 pizzas and an uncountable amount of drinks at the Fringe event
• 👕 100 t-shirts sold at the booth on the first day!!
• 🧑‍🏫 A completely packed devroom
• 🤝 Many great conversations at the booth

Shout out to Workadventure, Nordeck and Famedly who sponsored the Fringe Event and kept us refreshed and fed. And a huge thanks to everybody who showed up at the booth either to staff it or to say a kind word, bring constructive criticism, or have a casual conversation.

A more detailed wrap up post will be published this week. In the meantime, I’m leaving FOSDEM with a sense that we are doing the right thing, going in the right direction, and that people notice. I'm looking forward to meeting you all again, as well as those who couldn't make it to FOSDEM!

Continue reading…

This week we tried publishing TWIM on a Monday, but people seem to enjoy reading their Matrix news during the weekend. We will get back to publishing TWIM on Fridays!

🔗Matrix Live

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} says

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

🔗MSC Status

New MSCs:

• MSC4256: RFC 9420 MLS mode Matrix
• MSC4255: Bulk Profile Updates

MSCs in Proposed Final Comment Period:

• MSC3765: Rich text in room topics
• MSC3266: Room summary API
• MSC3757: Restricting who can overwrite a state event
• MSC4183: Additional Error Codes for submitToken endpoint
• MSC2965: OAuth 2.0 Authorization Server Metadata discovery

MSCs in Final Comment Period:

• MSC4239: Room version 11 as the default room version (merge)
• MSC4133: Extending User Profile API with Key:Value Pairs (merge)
  • FCP currently blocked due to an ongoing discussion.

Accepted MSCs:

• MSC4213: Remove server_name parameter from join and knock endpoints

Closed MSCs:

• MSC3975: rel_type for Replies
  • Closed by the MSC author.

🔗Spec Updates

Quite a flurry of activity in spec-land this week, as you can see from the above! MSC4133: Extending User Profile API with Key:Value Pairs moved into final comment period. While it still has one outstanding concern as of today, hopefully that can be worked out in the near future.

We also had a newly accepted MSC; MSC4213: Remove server_name parameter from join and knock endpoints. A small change, but a nice clean up to the spec.

Once again, thanks to everyone who's involved, and those that are only just getting started! The more the merrier.

Continue reading…

🔗Matrix Live

🔗Dept of Events and Talks 🗣️

🔗Matrix@FOSDEM 2025

As a reminder Matrix will again be present at FOSDEM this year!

As always, FOSDEM is free to attend and will happen at the 1. and 2. of February. Additionally we will have a fringe event on the 31st of January. You can find more information in the "Matrix in full force at FOSDEM" blog post.

Additionally please be aware that the Health and Safety Policy for the fringe event will be the same as the one of the Matrix Conference. Extremely briefly: You need to wear a mask while indoors, except while eating and drinking.

🔗Dept of Spec 📜

Andrew Morgan (anoa) {he/him} reports

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.

🔗MSC Status

New MSCs:

• MSC4253: Modifying or rejecting accepted MSCs
• MSC4252: Extensible Events modification: State event handling
• MSC4250: Authenticated media v2 (Cookie authentication for Client-Server API)

MSCs in Final Comment Period:

• MSC4213: Remove server_name parameter from join and knock endpoints (merge)

Accepted MSCs:

• No MSCs were accepted this week.

MSCs in Proposed Final Comment Period:

• MSC4133: Extending User Profile API with Key:Value Pairs
• MSC3765: Rich text in room topics
• MSC3266: Room summary API
• MSC4239: Room version 11 as the default room version
• MSC3757: Restricting who can overwrite a state event
• MSC4183: Additional Error Codes for submitToken endpoint

Closed MSCs:

• MSC3575: Sliding Sync (aka Sync v3)
  • Superseded by MSC4186: Simplified Sliding Sync
• [WIP] MSC4097: Interactions between media redirection and authentication
  • Replaced by spec-independent approaches.

🔗Spec Updates

As suggested from folks in the TWIM room, the above status now contains MSCs that are currently in proposed Final Comment Period. The hope is that this directs attention to MSCs that are close to being either merged/closed.

Let me know what you think!

Continue reading…