Matrix v1.12 release

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.

🔗Account locking

Prior to Matrix 1.12, the available account states for a user were “active” and “deactivated”, with no options for in-between or less destructive states. MSC3939 adds a new state, “locked”, to the mix which preserves the user’s account, but logs them out and doesn’t let them back in until the lock is removed. This new state could be used to prevent an attacker from brute forcing an account, handling out of band verification, or be a reaction to a moderation/terms of service decision. The server admin can then later reverse the lock with no impact on the user’s rooms, messages, or account information, unlike with deactivation.

When paired with MSC3823-style suspension, server admins have more non-destructive options to stop a user’s pattern of behaviour. They can completely kick the user out of their account with locking, or allow them to continue using the account in “read only” mode. MSC3823 is pending some implementation checks at the moment, but is expected to land in the next couple of releases.

Clients looking to implement locking or suspension will need to look at error codes, and continue calling /sync to determine when the account state changes (either back to active, or deactivated). MSC3939 and MSC3823 both have suggestions for what the UI might look like for a client as well.

🔗Marking rooms as unread

Finally, it’s possible to mark a room as “unread” after reading it. The existing read receipts structure makes this a uniquely difficult task to do traditionally, but MSC2867 found a way to get the same effect using account data instead. This approach doesn’t always maintain the unread message count, if it can even be calculated, but does offer users an ability to mark a room as something to come back to.

Client implementation can be a bit tricky when interacting with the overall notification system, but some may find it easy to add support for. In future it may be possible to mark individual messages as unread, or have the server calculate unread-ness over Simplified Sliding Sync, for example.

🔗Up next in Matrix 1.13 and beyond

Matrix 1.13 is expected to be released between late November and early December 2024. Many of the Matrix 2.0 features are undergoing finishing touches, particularly on the MSC side, and may also be ready for inclusion in the spec release. Meanwhile, we’re keeping an eye on MSCs proposed for Final Comment Period, and taking suggestions for MSCs which may be ready for the next stage in the process: if there’s something you think is ready for FCP, let us know in the SCT Office room!

🔗The full changelog

The full changelog for Matrix 1.12 is:

🔗Client-Server API

Deprecations

• Deprecate the server_name query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias} and POST /_matrix/client/v3/knock/{roomIdOrAlias}, as per MSC4156. (#1933)

Removed Endpoints

• Remove references to device-specific push rules. (#1842)
• Remove the deprecated name attribute on HTML anchor elements, as per MSC4159. (#1870)

Backwards Compatible Changes

• Add 403 responses on GET /_matrix/client/v3/profile/{userId}/avatar_url and GET /_matrix/client/v3/profile/{userId}/displayname, as per MSC4170. (#1867)
• Add support for marking rooms as unread, as per MSC2867. (#1895, #1941)
• Add via query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias} and POST /_matrix/client/v3/knock/{roomIdOrAlias}, as per MSC4156. (#1933)
• Add account locking, as per MSC3939. (#1934)
• Guest accounts can now download/thumbnail media from the new authenticated endpoints, as per MSC4189. (#1959)

Spec Clarifications

• Rename and sort the modules in the feature profiles table for easier skimming. (#1855)
• Clarify that room avatars cannot be encrypted. (#1871)
• Document the acronyms and alternate names for the "Secrets" section. (#1875)
• Improve recommendation for how to form transaction IDs. (#1888)
• Clarify that the deprecated dont_notify and coalesce push rule actions MUST be ignored, not rejected. (#1890)
• Fix various typos throughout the specification. (#1892)
• Add missing references to m.set_displayname, m.set_avatar_url, and m.3pid_changes in capabilities table. (#1897)
• Clarify that the fallback login page calls window.matrixLogin.onLogin instead of window.onLogin. (#1899)
• Remove confusing description of restricted rooms with no valid conditions. (#1903)
• Clarify that window.matrixLogin.onLogin is called with the response body of POST /_matrix/client/v3/login. (#1905)
• Document the m.get_login_token capability, as per MSC3882. (#1908)
• Clarify that the User identifier object in POST /_matrix/client/v3/login contains additional properties that depend on the identification type. (#1909)
• Don't mention that GET /_matrix/client/v3/profile/{userId} can return additional properties because this is true for almost every endpoint. (#1910)
• Improve wording of the unauthenticated media deprecation box. Contributed by @HarHarLinks. (#1916)
• Additional properties in GET /.well-known/matrix/client don't have to be objects. (#1920)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Specify Content-Type and Content-Disposition usage in the media repo, as per MSC2701 and MSC2702. (#1935)
• Additional keys in GET /_matrix/client/v3/capabilities don't have to be objects. (#1945)

🔗Server-Server API

Backwards Compatible Changes

• Add 403 response on GET /_matrix/federation/v1/query/profile, as per MSC4170. (#1867)

Spec Clarifications

• Remove origin field from PDU example because it doesn't exist in the schema anymore. (#1918)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Fix required fields in GET /_matrix/key/v2/server response schema. (#1930)
• Use "server name" instead of "DNS name" to avoid confusion with the "DNS name" component of "server names" as defined in the appendices. (#1946)

🔗Application Service API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

🔗Identity Service API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

🔗Push Gateway API

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

🔗Room Versions

Spec Clarifications

• Fix a formatting issue in state resolution v2. (#1896)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

🔗Appendices

Spec Clarifications

• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)

🔗Internal Changes/Tooling

Spec Clarifications

• The Matrix.org Foundation no longer requires "real" or "legally identifiable" names in order to contribute to projects. (#1886, #1914)
• Document the removal changelog category. (#1907)
• Use dedicated fonts for better support of mathematical symbols. (#1919)
• Document that the spec uses RFC 2119 keywords. Contributed by @HarHarLinks. (#1928)
• Provide markdown checklists for changelogs under /changelog/$VERSION/checklist.md. (#1937, #1954)
• Add the deprecated field to properties of OpenAPI definitions and JSON Schemas. (#1940)
• Use relative permalink to redirect to latest changelog. (#1956)