Releases

Hey all,

Matrix 1.15 is here with improvements to authentication, room summaries, and rich topics! A few months ago we were starting to see the next generation authentication MSCs (led by MSC3861) enter Final Comment Period and work towards acceptance. In that time, they've progressed all the way to being merged with today's release thanks to Kévin Commaille's generous contributions.

This post covers some of the highlights from the 10 MSCs the release brings to the world, with the full changelog at the end as always.

Continue reading…

Hey all,

We're right at the end of Q1 2025 with a new spec release: Matrix 1.14! Our original plan was to cut this release around FOSDEM with some Matrix 2.0 functionality, but ended up needing to push the release out due to those MSCs not quite being ready. As we're cutting this release though, several of the Next Generation Authentication MSCs are progressing through FCP and could do with a release once written up as spec PRs. We anticipate that Matrix 1.15 will be that release, and go out early in Q2 2025.

This release brings just 3 MSCs to the world, largely because the SCT has been focusing so much on Matrix 2.0 objectives. The only feature introduced is the report user endpoint, to complement last release's report room endpoint - everything else is primarily maintenance of the spec. The full changelog is below, as always.

Continue reading…

Hey all,

Another 9 MSCs have been released today in Matrix 1.13! It’s just over 2 months since Matrix 1.12 went out, and the last scheduled release for 2024 - the next release is planned for around FOSDEM 2025. Today’s release contains more T&S features and a number of clarifications and improvements. The full changelog is at the end of this post, per usual :)

Continue reading…

Hey all,

Welcome to the Matrix 1.12! It’s been just over 3 months since Matrix 1.11 introduced authenticated media, and today we’re bringing more Trust & Safety features to the ecosystem, alongside the normal clarifications and general improvements to the protocol. This release is also technically a few days late on the quarter, but it’s for good reason! Folks from across the ecosystem got together in Berlin for the Matrix Conference, and after things wrapped up we were busy following up on ideas started on site. We can’t wait to see all of these ideas materialize as MSCs, but in the meantime, back to the honorary Q3 release of the spec:

Matrix 1.12 marks the recommended date for all servers to enable their media freeze, similar to matrix.org’s back in early September 2024. Servers which haven’t yet enabled their media freeze are strongly encouraged to do so, if it makes sense for their users. Matrix 1.12 also brings some improvements and clarifications to authenticated media, and a total of 9 MSCs covering a wide range of features.

Read on for a few highlights, and the full changelog at the end of this post.

Continue reading…

Hey all,

We’ve just released the milestone Matrix 1.11 update for the protocol. It’s been almost exactly 3 months since the last release, Matrix 1.10, keeping us on track for our once-a-quarter release schedule.

There are 9 MSCs released in Matrix 1.11 today, but there’s one specific MSC we’d like to draw your attention to: MSC3916 - Authenticated Media. Until today, Matrix had a design flaw which allows a user to access media unauthenticated if they knew the URL. This has been used to share files in social media posts, link images outside of chats, and generally imply that a homeserver is a CDN for the internet. Some of these use cases are legitimate, though many are not. This is fixed with MSC3916.

This post covers MSC3916 and its implementation guidelines in more detail, but the full changelog for Matrix 1.11 is available at the end, as always.

Continue reading…

Hey all,

Matrix 1.10 is here! We aim to release the specification once in each calendar quarter, and with Q1 wrapping up in a few days we’re due for this quarter’s release. It has been 5 months since the last release (Matrix 1.9) brought in some protocol maintenance for us though, and the implementation teams have been hard at work building the Matrix 2.0 stack concurrent to the Matrix 1.10 work released today.

A total of 9 MSCs are released in Matrix 1.10, covering a wide range of maintenance, Matrix 2.0 preparation, and features for clients to use. This post focuses a bit on the Matrix 2.0 front and what’s expected in Matrix 1.11’s release cycle, but read on to the changelog at the bottom for full details on the changes which make up Matrix 1.10.

🔗MSC3077: Multi-stream VoIP

MSC3077 and its related proposal MSC3291 (muting in VoIP calls) lay some foundational groundwork for proper group VoIP to land in Matrix - an objective of Matrix 2.0. Currently this is taking shape at MSC3898 and MSC3401, though Element’s VoIP team is considering a possible third alternative which runs MSC3401 over something like LiveKit’s SFU - stay tuned for updates there. In the meantime, users in native 1:1 calls can enjoy proper screen sharing and mute capabilities ahead of the 1:N call support later this year.

As always, early review is appreciated though please note that MSC3898 and MSC3401 are particularly in flux at the moment.

🔗Up next in Matrix 1.11 and beyond

Over the next 2-3 months, we’ll be focusing on the following MSCs:

• Trust & Safety improvements (at the protocol level).
  • MSC3823 - Account suspension
  • MSC3939 - Account locking
  • MSC3916 - Authentication for media (time permitting)
  • MSC4117 - Reversible redactions (pre-implementation review)
  • MSCs around a “reporting v2” flow in light of various legislation and compliance requirements. These MSCs are currently being written and should be up for pre-implementation review within the Matrix 1.11 cycle.
• Early review of Matrix 2.0 features as they become ready.
  • Sliding sync (MSC3575) + applicable extensions.
  • Group VoIP - Exact MSCs to be determined, as they may change following implementation.
  • OIDC Authentication - Exact MSCs to be determined.
• Pre-implementation review of Extensible Events core content blocks MSCs.
  • Many of these MSCs require updates before they are ready for formal review.
  • MSC3954 - Emotes
  • MSC3955 - Notices / automated events
  • MSC3927 - Audio
  • MSC3551 - Files
  • MSC3552 - Images and Stickers
  • MSC3553 - Videos

Additionally, we’ll be continuing to define the expectations of a Spec Core Team member, particularly as it relates to the upcoming Governing Board for the Foundation. This exercise has been extremely valuable to us so far, and will help identify areas the Foundation and SCT may need support from each other.

🔗The full changelog

Read on for full details of what’s in Matrix 1.10:

🔗Client-Server API

Backwards Compatible Changes

• Allow /versions to optionally accept authentication, as per MSC4026. (#1728)
• Add local erasure requests, as per MSC4025. (#1730)
• Use the body field as optional media caption, as per MSC2530. (#1731)
• Add server support discovery endpoint, as per MSC1929. (#1733)
• Add support for multi-stream VoIP, as per MSC3077. (#1735)
• Specify that the Retry-After header may be used to rate-limit a client, as per MSC4041. (#1737)
• Add support for recursion on the GET /relations endpoints, as per MSC3981. (#1746)

Spec Clarifications

• The strike element is deprecated in the HTML spec. Clients should prefer s instead. (#1629)
• Clarify that read receipts should be batched by thread as well as by room. (#1685)
• Clarify that threads can be created based on replies. (#1687)
• Clarify in the reply fallbacks example that the prefix sequence should be repeated for each line. (#1690)
• Clarify the format of account data objects for secret storage. (#1695, #1734)
• Clarify that the key backup MAC is implemented incorrectly and does not pass the ciphertext through HMAC-SHA-256. (#1712)
• Clarify one-time key and fallback key types in examples. (#1715)
• Clarify that the HKDF calculation for SAS uses base64-encoded keys rather than the raw key bytes. (#1719)
• Clarify how to perform the ECDH exchange in step 12 of the SAS process. (#1720)
• Document the deprecation policy of HTML tags, as per MSC4077. (#1732)
• The font element is deprecated in the HTML spec. Clients should prefer span with the data-mx-bg-color and data-mx-color attributes instead. (#1739)
• Disambiguate uses of PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)
• Clarify that sdpMid and sdpMLineIndex are not required in m.call.candidates. (#1742)
• Fix various typos throughout the specification. (#1748)
• Clearly indicate that each Content-Type may have distinct behaviour on non-JSON requests/responses. (#1756)
• Clarify that the m.push_rules account data type cannot be set using the /account_data API, as per MSC4010. (#1763)

🔗Server-Server API

Spec Clarifications

• Clarify Server-Server API request signing example by using the POST HTTP method, as GET requests don't have request bodies. (#1721)
• Disambiguate uses of PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)
• Clarify that the children_state, room_type and allowed_room_ids properties in the items of the children array of the response of the GET /hierarchy endpoint are not required. (#1741)

🔗Application Service API

Spec Clarifications

• Clarify that the /login and /register endpoints should fail when using the m.login.application_service login type without a valid as_token. (#1744)

🔗Identity Service API

No significant changes.

🔗Push Gateway API

No significant changes.

🔗Room Versions

Spec Clarifications

• For room versions 7 through 11: Clarify that invite->knock is not a legal transition. (#1717)

🔗Appendices

No significant changes.

🔗Internal Changes/Tooling

Spec Clarifications

• Update the spec release process. (#1680)
• Minor clarifications to the contributing guide. (#1697)
• Update Docsy to v0.8.0. (#1699, #1762)
• Fix npm release script for @matrix-org/spec. (#1713)
• Add some clarifications around implementation requirements for MSCs. (#1718)
• Update HTML templates to include links to object schema definitions. (#1724)
• Factor out all the common parameters of the various /relations apis. (#1745)
• Add support for $ref URIs containing fragments in OpenAPI definitions and JSON schemas. (#1751, #1754)

Hey all,

We’ve just pushed out Matrix 1.9! Our last release was Matrix 1.8 and brought us a whole new room version. Matrix 1.9 continues a theme of an annual maintenance release, bringing with it mostly clarifications and bug fixes.

Today’s release sees just 1 MSC formally merged to the specification, though this is expected for a maintenance release. For the last 2 months (and beyond), we have largely been focused on changes which haven’t settled enough to be MSCs yet, such as interactions with the More Instant Messaging Interoperability (MIMI) working group at the IETF.

This post covers a lot of what we’ve been up to for the last few months, and what we expect to get done for the Matrix 1.10 release cycle. As always, the full changelog for Matrix 1.9 is at the bottom of the post :)

🔗Messaging interoperability

One of the major features of Matrix is its ability to connect multitudes of messaging providers with a common communications fabric - a feature that is extremely useful in light of the EU’s Digital Markets Act (DMA) which requires gatekeepers to interoperate with other messaging providers.

We’ve been working with the MIMI working group at the IETF to establish a federation protocol for DMA-style messaging alongside our own experiments like MSC3995: Linearized Matrix. The proposed protocol for MIMI is based upon the Linearized Matrix work, but is primarily designed for an MLS-centric environment.

Discussions and experiments will continue over the next several months, and you can read all about our progress so far in TWIM 2023-11-10.

🔗Custom emoji/stickers

We mentioned in Matrix 1.8’s release that we’d be taking a look at MSC2545, MSC1951, MSC4027, and MSC3892 - a family of MSCs collectively called “custom emoji/stickers”. Our review started relatively late in the Matrix 1.9 release cycle (sorry), and we started thinking about interactions with MSC3916/MSC3911 where media is linked to a specific event.

We haven’t had a chance to really dig into the specific possible concerns on these two features overlapping, but do welcome feedback and suggestions for what might impact custom emoji/stickers over on our dedicated tracking issue. We’ll continue working through the problem space in the Matrix 1.10 release cycle, and hope to get both linked media and custom emoji/stickers up for FCP.

🔗Upcoming in Matrix 1.10

With each release we aim to have a plan for what the next release will look like, giving us a direction or theme to follow. Noting that the next release cycle has a lot of holidays (and FOSDEM) in it, we’ve got an initial list of things to look at, grouped by theme:

• Authenticated media
  • MSC3916 - Authentication for media
  • MSC3911 - Linking media to events
• Custom emoji/stickers
  • MSC2545 - Image packs
  • MSC1951 - Different style of image packs
  • MSC4027 - Images in reactions
  • MSC3892 - Encrypted emotes
• MSC4074 - Server-side annotation aggregation
• MSC4048 - Authenticated key backup
• Extensible Events
  • MSC3954 - Text emotes
  • MSC3955 - Replacement for notice messages
  • MSC3551 - Files
  • MSC3552 - Images and Stickers
  • MSC3553 - Videos
  • MSC3927 - Audio
• Encrypted Appservices
  • MSC2409 - Sending EDUs to appservices
  • MSC3202 - Encrypted appservices
• MSC2702 - Content-Disposition semantics for media
• MSC3939 - Account locking

This list is not final and will be iterated upon over the next couple of weeks. If you’ve got an MSC to add or remove, let us know in the SCT Office on Matrix. For all of the MSCs above, we aim to get them to a FCP-accepted state at a minimum, and merged to the spec if time permits (and makes sense - looking at you, Extensible Events).

🔗The full changelog

Matrix 1.9 is a relatively light maintenance release, but it still has a changelog! Read on for full details.

🔗Client-Server API

Backwards Compatible Changes

• Add the m.rule.suppress_edits default push rule, as per MSC3958. (#1617)

Spec Clarifications

• Fix m.call.negotiate schema and example. (#1546)
• Clarify that the via property is required for m.space.parent and m.space.child as per MSC1772. Contributed by @PaarthShah. (#1618)
• Add a note to the /publicRooms API that the server name is case sensitive. (#1638)
• Clarify that an m.room.name event with an absent name field is not expected behavior. (#1639)
• Fix schemas used for account data and presence events in GET /initialSync. (#1647)
• Fix various typos throughout the specification. (#1658, #1661, #1665)
• Fix .m.rule.suppress_notices push rule not being valid JSON. (#1671)
• Add missing properties for event_property_is and event_property_contains push conditions to PushConditions object. (#1673)
• Indicate that fallback keys should have a fallback property set to true. (#1676)
• Clarify that thread roots are not considered within the thread. (#1677)

🔗Server-Server API

Spec Clarifications

• Fix schema of m.receipt EDU. (#1636)
• Fix various typos throughout the specification. (#1661)
• Clarify that federation requests for non-local users are invalid. (#1672)

🔗Application Service API

No significant changes.

🔗Identity Service API

No significant changes.

🔗Push Gateway API

No significant changes.

🔗Room Versions

No significant changes.

🔗Appendices

Spec Clarifications

• Clarify timestamp specification with respect to leap seconds. (#1627)
• Fix various typos throughout the specification. (#1652)

🔗Internal Changes/Tooling

Backwards Compatible Changes

• Add more CI checks for OpenAPI definitions and JSON Schemas. (#1656)
• Generate server-server OpenAPI definition. (#1657)

Spec Clarifications

• Replace all mentions of Swagger by OpenAPI. (#1633)
• Fix enum types in JSON schemas. (#1634)
• Fix schema of m.mentions object. (#1635)
• Fix rendering of m.receipt event in Client-Server API. (#1637)
• Remove required fieldname in appservice Protocol definition. (#1646)
• Fix github action workflow responsible for releasing of @matrix-org/spec package. (#1648)
• Upgrade GitHub actions. (#1660)

Hey all,

Matrix 1.8 is out now! The last release, Matrix 1.7, was full of features and laid out a plan for what Matrix 1.8 was expected to become. We spent most of our time focusing on the MSC3995-related MSCs from that original plan, but made an effort to get the other stuff looked at as well.

With this release we see a total of 9 MSCs achieve their formally adopted status. The full changelog at the bottom has all the details, but please read on for what’s new in room version 11, and Matrix 1.9’s roadmap :)

🔗Room version 11

Matrix 1.8 features a new room version! Normally a room version wouldn’t have a particular theme, but for v11 we aimed to clean up the different algorithms and event format details. After 10 prior room versions there were some artifacts of the past sticking around (but not causing problems necessarily) - many of them are cleaned up here.

Specified originally as MSC3820, v11 introduces the following changes:

• MSC2174 - Move redacts to the content of m.room.redaction events.
• MSC2175 - Remove creator from m.room.create events (use sender instead).
• MSC3989 - Remove origin from events.
• MSC2176, MSC3821 - General updates to redaction algorithm.

Alongside being a cleanup room version, v11 is the initial base we used for our efforts in the IETF world. It provides an easier starting point for new server implementations, particularly when paired with Linearized Matrix (described as both an IETF Internet-Draft and MSC3995).

In future room versions the cleanup effort will continue, alongside additional features for supporting the IETF use cases. Watch this space for updates.

🔗Upcoming in Matrix 1.9

We’re continuing the trend of planning ahead and have the following themes planned for work in Matrix 1.9:

• Anything required by the MIMI/IETF efforts we’re undertaking. This currently includes:
  • Extensible Events
  • Role-Based Access Control (RBAC; new MSC expected)
  • Next generation of Linearized Matrix (already)
  • MSC4044 and MSC4045
  • Binary-encoded events (maybe, but probable)
  • Canonical DMs (maybe)
  • Sending events as rooms/servers instead of just users (maybe)
  • Further room version cleanup as needed
• Merging MSC3939.
• Accepting a combination of MSC2545, MSC1951, MSC3892, and MSC4027. This may involve creating a new MSC to cover the functionality of each, plus the needful for IETF and Extensible Events efforts.
• Merging MSC3391 (time permitting).

A lot of this stuff might take the shape of opening MSCs or thinking about the problems, but we’re also very optimistic about getting them through FCP before November 2023. Watch this space for updates :)

🔗The full changelog

There’s so many more things than what we covered in this blog post - flip through the changelog below for a full idea of what’s landed.

🔗Client-Server API

Backwards Compatible Changes

• Require callers to be joined to the room to report its events, as per MSC2249. (#1517)

Spec Clarifications

• Fix missing type property in the JSON schema definition of the m.reaction event. Contributed by @chebureki. (#1552)
• Make sure examples types match schema in definitions. (#1563)
• Allow null in room_types in POST /publicRooms endpoints schemas. (#1564)
• Fix broken header formatting. Contributed by @midnightveil. (#1578)
• Render binary request and response bodies. (#1579)
• Fix description of MAC calculation in SAS verification. (#1590)
• Update link to SAS emoji definition data. (#1593)
• Fix various typos throughout the specification. (#1597)

🔗Server-Server API

Deprecations

• Deprecate matrix SRV lookup steps during server discovery, as per MSC4040. (#1624)

Backwards Compatible Changes

• Add matrix-fed SRV lookup steps to server discovery, as per MSC4040. (#1624)

Spec Clarifications

• Document why /state_ids can respond with a 404. (#1521)
• Fix response definition for POST /_matrix/federation/v1/user/keys/claim. (#1559)
• Fix examples in server keys definition. (#1560)
• Make sure examples types match schema in definitions. (#1563)
• Allow null in room_types in POST /publicRooms endpoints schemas. (#1564)
• Fix broken header formatting. Contributed by @midnightveil. (#1578)
• Remove spurious mention of a "default port" with respect to SRV record lookup. (#1615)
• Switch to ordered list for server name resolution steps. (#1623)

🔗Application Service API

Spec Clarifications

• Fix type of custom fields in thirdparty lookup queries. (#1584)

🔗Identity Service API

Spec Clarifications

• Make sure examples types match schema in definitions. (#1563)

🔗Push Gateway API

No significant changes.

🔗Room Versions

Backwards Compatible Changes

• Add room version 11 as per MSC3820. (#1604)
• Move redacts from top level to content on m.room.redaction events in room version 11, as per MSC2174. (#1604)
• Remove creator from m.room.creator events in room version 11, as per MSC2175. (#1604)
• Remove remaining usage of origin from events in room version 11, as per MSC3989. (#1604)
• Update the redaction rules in room version 11, as per MSC2176 and MSC3821. (#1604)

🔗Appendices

Backwards Compatible Changes

• Allow + in Matrix IDs, as per MSC4009. (#1583)

Spec Clarifications

• Clarify spec re canonical JSON to handle negative-zero; also, give an example of negative-zero and a large power of ten. (#1573)

🔗Internal Changes/Tooling

Backwards Compatible Changes

• Upgrade Swagger data to OpenAPI 3.1. (#1310)
• Create @matrix-org/spec npm package to ship the SAS Emoji data definitions & translations. (#1620)

Spec Clarifications

• Update the CI to validate the file extension of changelog entries. (#1542)
• Disclosure sections now only display their title when collapsed. (#1549)
• Fix the sidebar in recent versions of Hugo. (#1551)
• Bump jsonschema to validate JSON Schemas against Draft 2020-12. (#1556)
• Use Redocly CLI to validate OpenAPI definitions. (#1558)
• Use tag name as the OpenAPI definition version. (#1561)
• Make sure version in x-changedInMatrixVersion is a string. (#1562)
• Clarify usage of ABNF for grammar in the documentation style guide. (#1582)
• Remove unnecessary oneOfs in JSON schemas. (#1585)
• Update the version of Hugo used to render the spec to v0.113.0. (#1591)
• Fix rendered changelog with new version of towncrier. (#1598)
• Improve the layout of tables on desktop displays. Contributed by Martin Fischer. (#1601)

Hey all,

Matrix 1.7 has just been released! The last spec release was about 3 months ago, keeping us on track for regular quarterly releases. Unlike Matrix 1.6 though, today’s release is packed with plenty of features, some of which we’d like to call out here. Not all implementations will have support for these features yet though, and that’s okay (expected, even).

Adding support for a spec release can be a significant body of work. Instead of implementations having everything ready for spec release day, the idea is that they gain support over the next few months. If you’re able, please help those projects get v1.7’s features.

Today, we see 15 MSCs achieve their formally adopted status. All of them bring forward some much-needed features to Matrix, and a few highlights are below. Read on to the full changelog for a complete overview, and for a sneak peak at what the Spec Core Team (SCT) is planning to look at for v1.8 👀

Continue reading…

Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427 / GHSA-mwq8-fjpf-c2gr for matrix-js-sdk and CVE-2023-28103 / GHSA-6g43-88cp-w5gv for matrix-react-sdk).

Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.

The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.

Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.

We found these issues during a codebase audit that we had previously announced in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059 / GHSA-rfv9-x7hh-xc32 and CVE-2022-36060 / GHSA-2x9c-qwgf-94xr, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.