Matrix Release Notes

Hey all,

Today’s release of Matrix 1.18 brings a total of 16 MSCs to the protocol. Many of those proposals improve Trust & Safety in Matrix, introducing features like invite blocking, policy servers, account suspension & locking, and general quality of life improvements to the reporting APIs. This blog post covers those safety features in a bit more detail - read on to the full changelog at the bottom for full details of everything in Matrix 1.18.

Policy servers

After about a year of development, policy servers have made their way into the stable spec. Typically paired with reactive tooling like moderation bots, these servers can optionally be added to a room when needed to provide proactive moderation. When enabled, all servers in a room ask the policy server for an opinion on their events before sending them with normal full mesh routing. If the policy server refuses to sign the event due to unwelcome content, it will not be delivered to other homeservers or local users.

How and what policies a policy server uses is left as an implementation detail. Some policies might be simple, like limiting the number of mentions allowed in a message, or more complex. Policy servers also do not need to track the underlying room DAG, allowing them to be relatively lightweight to build.

For more information on what policy servers can be used for, read the announcement post for the Foundation’s own implementation, named policyserv.

Invite blocking

Several proposals (tracked largely by MSC4192) have been opened over the years to limit the ability for unknown users to send invites to another user. These proposals often try to add safety features that are incredibly desirable, but are hard to put a UI on top of. In an effort to get something into the spec, MSC4380 boiled the feature down to its essential component: a single on/off toggle for invites. Future expansion to block based on servers, user IDs, Space members, etc is possible and tracked in other MSCs like MSC4155.

We look forward to seeing design teams take on those more advanced safety controls to expand the capabilities of invite blocking beyond MSC4380’s simple toggle!

Account suspension & locking

Account suspension and locking were introduced back around Matrix 1.13, but API endpoints to manage the states were not introduced at the time. As the new account states continue to gain popularity in server implementations, MSC4323 added those missing endpoints. Security and safety tooling can now use the new standard endpoints instead of having implementation-specific logic and switch statements.

Reporting improvements

Though small, MSC4277 harmonizes the various reporting endpoints to be similar in functionality, making it a little easier for clients to predict what happens when submitting reports. This is a highly welcome change ahead of the Foundation’s T&S team working on “Reporting v2” to modernize submitting reports (and appeals) to communities, servers, and federated locations later this year - stay tuned to the blog for updates on that project!

The full changelog

The full changelog for Matrix 1.18 is:

Client-Server API

New Endpoints

Add GET /_matrix/client/v1/admin/suspend/{userId}, as per MSC4323. (#2278)

Add PUT /_matrix/client/v1/admin/suspend/{userId}, as per MSC4323. (#2278)

Add GET /_matrix/client/v1/admin/lock/{userId}, as per MSC4323. (#2278)

Add PUT /_matrix/client/v1/admin/lock/{userId}, as per MSC4323. (#2278)

Removed Endpoints

The score request parameter on /_matrix/client/v3/rooms/{roomId}/report/{eventId} was removed as per MSC4277. (#2311)

Backwards Compatible Changes

Add the account management capabilities for the OAuth 2.0 authentication API, as per MSC4191. (#2270)

Add OAuth 2.0 aware clients, as per MSC3824. (#2272)

Add administrator endpoints to lock and suspend server-local users and add the m.account_management capability, as per MSC4323. (#2278)

Add m.recent_emoji account data event to track recently used emoji as per MSC4356. (#2291)

Add m.forget_forced_upon_leave capability for servers to transparently auto-forget rooms that the user leaves as per MSC4267. (#2292)

Add support for m.room.redaction events at the PUT /rooms/{roomId}/send/{eventType}/{txnId} endpoint, as per MSC4169. (#2298)

Clients supporting the ol HTML element must also support the start attribute, as per MSC4313. (#2299)

Add recommendation about excluding non-cross-signed devices from encrypted conversations, as per MSC4153. (#2301)

Add invite blocking, as per MSC4380. (#2305)

/_matrix/client/v3/rooms/{roomId}/report and /_matrix/client/v3/rooms/{roomId}/report/{eventId} may respond with HTTP 200 regardless of the reported subject's existence or add a random delay when generating responses as per MSC4277. (#2311)

Add M_USER_LIMIT_EXCEEDED common error code, as per MSC4335. (#2315)

Add the OAuth 2.0 Device Authorization Grant (RFC 8628) as a supported grant type, as per MSC4341. (#2320)

Add the is_animated flag to the info object of the m.image msgtype and the m.sticker event, as per MSC4230. (#2328, #2338)

Add a "Policy Servers" module, as per MSC4284. (#2332)

Spec Clarifications

The optional submit_url response parameter of the /requestToken endpoints uses the same request and response parameters and error codes as the Identity Service API's POST /_matrix/identity/v2/validate/email/submitToken, as per MSC4183. (#2277)

Update non-historic mentions of matrix-doc repo to matrix-spec/-proposals. Contributed by @HarHarLinks. (#2280)

Remove unintended TeX formatting. Contributed by @HarHarLinks. (#2283)

Clarify the requiredness of event_id in predecessor. (#2304)

Clarify terminology for keys in cross-signing module. (#2306)

Add 404 responses to the OpenAPI of GET /login and GET /auth_metadata endpoints. The responses were already defined in text but not written in OpenAPI. (#2316)

Fix various typos throughout the specification. Contributed by @HarHarLinks. (#2318)

Clarified attachment encryption to require secure generation of keys and hash verification. (#2324)

Order the common and other error codes alphabetically and remove duplicate M_THREEPID_IN_USE definition. (#2336)

Fix various typos throughout the specification. (#2337)

Server-Server API

Removed Endpoints

Remove /v1/send_join and /v1/send_leave, as per MSC4376. (#2319)

Backwards Compatible Changes

Add a concept of "Policy Servers", as per MSC4284. (#2332)

Spec Clarifications

Clarify what the minimum_valid_until_ts field means when it is set in key queries. (#2191)

Specify validation for PDUs passed to and returned from federation membership endpoints. (#2284)

Specify that callers of /_matrix/federation/v1/openid/userinfo must validate the returned user ID. (#2288)

Change m.signing_update typo to m.signing_key_update. Contributed by @velikopter (#2300)

Add link to JSON signing algorithm in server-server auth section for clarity. Contributed by @thetayloredman. (#2329)

Fix various typos throughout the specification. (#2338)

Application Service API

Spec Clarifications

Fix various typos throughout the specification. (#2330)

Identity Service API

Spec Clarifications

Clarify the error codes that can be returned with a 400 HTTP status code by the POST /_matrix/identity/v2/validate/email/submitToken and POST /_matrix/identity/v2/validate/msisdn/submitToken endpoints, introducing the M_TOKEN_INCORRECT error code, as per MSC4183. (#2277)

Order the standard error codes alphabetically. (#2336)

Push Gateway API

No significant changes.

Room Versions

Spec Clarifications

Clarify meaning of floating-point powerlevels. (#2297)

Remove the post-1.16 release note for room version 12. (#2303)

Appendices

Spec Clarifications

Add identifier pronunciation guidelines. Contributed by @HarHarLinks. (#2307)

Internal Changes/Tooling

Backwards Compatible Changes

Include the spec release version in the filenames in the tarballs generated by CI. (#2276)

Spec Clarifications

Clarify vendor prefixing requirements. (#2222)

Auto-create draft releases when building release tags. (#2275)

Replace the Twitter link in the footer with our BlueSky and Mastodon socials. (#2282)

Upgrade to docsy v0.13.0. (#2287)

Updates to the release documentation. (#2289)

Remove unused leftover CSS files. (#2290)

Update the footer social links to match matrix.org. Contributed by @HarHarLinks. (#2317)

Fix various typos throughout the specification. Contributed by @HarHarLinks. (#2318)

Render error code sections as definition lists to improve readability. (#2323)

Original source

Hey all,
At this year’s Matrix Conference we said we were aiming for this very spec release to be 2.0 proper. It looks like the MSCs still need a little bit more time to get over the line though, but they’re extremely close — one of the next few releases is expected to be Matrix 2.0.
Today we’re releasing Matrix 1.17 while the 2.0 MSCs continue to make forward progress. This release is smaller than some, with four MSCs merged, but as normal also includes a number of clarifications.
Improvements to the spec website include a dropdown to get at old spec versions more easily, and an index of HTTP endpoints at the top of each page.
This release of the spec also sees the incorporation of the specifications for the Olm and Megolm cryptographic ratchets. Olm and Megolm themselves haven’t changed, but we did want them to be on the spec site :)
Thanks especially to Johannes and Kévin for continuing to improve the quality of the spec with features, clarifications, and MSC text!
🔗The full changelog
🔗Client-Server API
Removed Endpoints
Remove legacy mentions, as per MSC4210. (#2186)
Backwards Compatible Changes
Allow application services to masquerade as specific devices belonging to users, as per MSC4326. (#2221)
Add the m.oauth authentication type for User-Interactive Authentication, as per MSC4312. (#2234)
Allow application services to manage devices and register users without the legacy authentication API, as per MSC4190. (#2267)
Spec Clarifications
Push rule IDs are globally unique within their kind. (#2214)
Don't advertise creator field in description of room creation. (#2215)
room_id is required for peeking via /_matrix/client/v3/events. (#2216)
The server-name segment of MXC URIs is sanitised differently from the media-id segment. (#2217)
Add note to each endpoint that uses capability negotiation. (#2223)
Additional OpenGraph properties can be present in URL previews. (#2225)
Clarify the special casing of membership events and redactions in power levels. (#2231)
M_RESOURCE_LIMIT_EXCEEDED is now listed as a common error code. (#2232)
Add m.login.terms to enumeration of authentication types. (#2233)
Clarify how to use state_after ahead of declaring full support for its spec version. (#2240)
device_one_time_keys_count is only optional if no unclaimed one-time keys exist. (#2245)
Clarify that servers may choose not to use M_USER_DEACTIVATED at login time, for example for privacy reasons when they can't authenticate deactivated users. (#2246)
Usage of the event_id_only format for push notifications is not mandatory. (#2255)
Fix various typos throughout the specification. (#2224, #2227, #2250)
🔗Server-Server API
No significant changes.
🔗Application Service API
Backwards Compatible Changes
Allow application services to masquerade as specific devices belonging to users, as per MSC4326. (#2221)
Allow application services to manage devices and register users without the legacy authentication API, as per MSC4190. (#2267)
Spec Clarifications
Fix JSON formatting in the "Server admin style permissions" examples. (#2213)
🔗Identity Service API
No significant changes.
🔗Push Gateway API
No significant changes.
🔗Room Versions
Spec Clarifications
In room versions 8 through 12, clarify that "sufficient permission to invite users" on restricted joins also includes being a joined member of the room. (#2220)
In room versions 3 through 12, clarify that when you have the power to redact, it is possible to redact events that you don't have the power to send. (#2249)
🔗Appendices
No significant changes.
🔗Internal Changes/Tooling
Spec Clarifications
Swapped icon for X (fka. twitter) to updated logo in footer. (#2219)
Inline Olm & Megolm specifications. (#2226, #2241, #2242)
Silence failing redocly-cli rule. (#2238)
Use NPM Trusted Publishers for publishing @matrix-org/spec to npm. (#2239)
Add version picker in the navbar. (#2256, #2258, #2259, #2260, #2261, #2264, #2268)
Add a list of endpoints to the top of each spec page. (#2262)

Original source

Hey all,

Today’s Matrix 1.16 release brings two major features to the protocol: extensible profiles and room version 12 from Project Hydra! With room version 12, users should see fewer “state resets” and a clearer hierarchy for power levels in the room. The Project Hydra blog post covers the changes in more detail, so this post will focus on extensible profiles and our plan for Matrix 2.0.

As always, the full changelog and descriptions of the 9 MSCs released today is at the end of this post.

Extensible profiles

Since the invention of profiles, people have wanted to advertise information to others. Matrix is no different, with time zones, pronouns, preferred languages, job titles, and more being among the top requested dedicated fields. Matrix 1.16 brings time zone support to ensure the new extensible system is capable of representing basic information. However users are able to use custom namespaces today to describe additional details, whereas new MSCs may formally define fields to be added to the specification for broad client support.

Huge thanks and congratulations to Tom for landing this highly requested feature in their first-ever MSC.

Matrix 2.0

Over the years we’ve talked a lot about Matrix 2.0, and even demoed the implementations of Matrix 2.0 MSCs at last year’s Matrix Conference. After spending the majority of the last year polishing the implementations and touching up the MSCs, we’re setting our sights on Matrix 2.0. If we’re lucky, we’ll even get the 12+ remaining MSCs merged before the Matrix Conference in October.

Watch this space and the Office of the Matrix Spec Core Team room on Matrix for updates as we work toward Matrix 2.0/the conference.

The full changelog

The full changelog for Matrix 1.16 is:

Client-Server API

Deprecations

Deprecate m.set_avatar_url and m.set_displayname capabilities, as per MSC4133. (#2071)

Removed Endpoints

Remove unintentional intentional mentions in replies, as per MSC4142. (#2210)

Backwards Compatible Changes

Update user profile endpoints to handle custom fields, and add a new m.profile_fields capability, as per MSC4133. (#2071)

Add format query parameter to GET /state/{eventType}/{stateKey} to allow fetching metadata of a specific state event. (#2175)

Add the use_state_after query parameter and state_after response property to GET /sync, as per MSC4222. (#2187)

When upgrading rooms to room version 12, additional_creators may be specified on the POST /_matrix/client/v3/rooms/{roomId}/upgrade endpoint, as per MSC4289. (#2193)

When creating rooms with room version 12, the trusted_private_chat preset should merge the invitees into the supplied content.additional_creators in the resulting room, as per MSC4289. (#2193)

In room version 12, the power level of room creators is now infinitely high as per MSC4289. (#2193)

In room version 12, room IDs no longer have a domain component as per MSC4291. (#2193)

When creating rooms with room version 12, the initial power levels will restrict the ability to upgrade rooms by default, as per MSC4289. (#2193)

Add a profile field for a user's time zone, as per MSC4175. (#2206)

Invites and knocks are now expected to contain the m.room.create event in their stripped state entries, as per MSC4311. (#2207)

Spec Clarifications

Clarify that format is required if formatted_body is specified. (#2167)

The latest_event in an aggregated set of thread events uses the same format as the event itself. (#2169)

Fix various typos throughout the specification. (#2171, #2177, #2179)

Clarify that clients should replace events with the most recent replacement by origin_server_ts. (#2190)

Fix /sync flow referencing incorrect parameter to use with /messages. (#2195)

Clarify wording around the world_readable history visibility setting. Contributed by @HarHarLinks. (#2204)

Server-Server API

Backwards Compatible Changes

invite_room_state and knock_room_state now have additional requirements and validation depending on the room version, as per MSC4311. (#2207)

Application Service API

No significant changes.

Identity Service API

No significant changes.

Push Gateway API

No significant changes.

Room Versions

Backwards Compatible Changes

Room IDs in room version 12 are now the event ID of the create event with the normal room ID sigil (!), as per MSC4291. (#2193)

Room creators are formalized in room version 12 and have infinitely high power level, as per MSC4289. (#2193)

State Resolution is updated in room version 12 to reduce the opportunity for "state resets", as per MSC4297. (#2193)

The default room version is now room version 12, though servers SHOULD keep using room version 11 for a little while, as per MSC4304. (#2193)

Add room version 12 as per MSC4304. (#2193, #2199)

Spec Clarifications

In room versions 1 through 12, an event's auth_events have always needed to belong to the same room as per MSC4307. (#2193)

Appendices

Backwards Compatible Changes

Room IDs can now appear without a domain component in room version 12, as per MSC4291. (#2193)

Internal Changes/Tooling

Backwards Compatible Changes

Add "placeholder MSC" process definition. (#2157)

Spec Clarifications

Declare the Application Service Registration schema to follow JSON Schema spec 2020-12. (#2132)

Declare the event schemas to follow JSON Schema spec 2020-12. (#2132)

Upgrade the docsy theme to version 0.12.0. (#2160)

GitHub actions are now building the OpenAPI spec/identity-service-api/api.json file. (#2172)

Minor fixes to JSON schemas. (#2182)

Specify a correct spelling for "display name". (#2189)

Fix a grammatical typo on the Matrix Spec Process documentation page. (#2205)

Original source

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.

Next-generation Authentication

Over the last several years, there has been significant effort put into designing, implementing, and deploying industry-standard authentication for Matrix in the form of OIDC. Though the MSCs were first opened in 2022, the work hit the spotlight in 2023 to outline how the system is expected to work, setting the stage for this year's incredible migration of 110 million matrix.org users in just 30 minutes.

With the MSCs part of the spec, we're now a full step closer to Matrix 2.0 being released. The remainder of Matrix 2.0 will take some time still to fully land in the spec, but there's progress being made in the meantime. MSC enthusiasts should also take a look at a number of enhancement proposals to the next-gen auth system which will be making their way towards the spec over the next while.

Congratulations to the team, and thanks for making Matrix a safer and more secure place.

Room summaries

MSC3266 has been around for a while in various forms (including a brief moment where it was used in production, oops 🙈), and has finally made it to the spec. Clients can use the new endpoint to get richer information about a room they're not quite participating in yet, providing a better experience to users on invites, knocks, and even matrix.to links. Most clients have already implemented support, but if yours could do with better context on unjoined rooms in particular, this could be the missing piece they need to make that happen.

Thanks to Nico for bearing with us through the years of review, and final push to the spec itself.

Rich topics

Rooms can now be bold and use lists to the heart's content thanks to MSC3765 landing in the spec. Some rooms already make use of this to provide user-friendly links to information in their topics, and now all rooms can use the stable identifiers to represent their rooms in the richest way possible. Under the hood, the feature makes use of Extensible Events, but avoids the requirement for a new room version thanks to healthy fallback support - clients are encouraged to experiment with different rendering approaches ahead of extensible events (slowly) working its way towards a spec release.

Thanks to Johannes for landing this highly requested feature in the spec.

The full changelog

The full changelog for Matrix 1.15 is:

Client-Server API

New Endpoints

Add GET /_matrix/client/v1/room_summary/{roomIdOrAlias}, as per MSC3266. (#2125)

Add GET /_matrix/client/v1/auth_metadata, as per MSC2965. (#2147)

Backwards Compatible Changes

Add m.topic content block to enable rich text in m.room.topic events as per MSC3765. (#2095)

Include device keys with Olm-encrypted events as per MSC4147. (#2122)

Add /_matrix/client/v1/room_summary/{roomIdOrAlias} and extend /_matrix/client/v1/rooms/{roomId}/hierarchy with the new optional properties allowed_room_ids, encryption and room_version as per MSC3266. (#2125, #2158)

Add the OAuth 2.0 based authentication API, as per MSC3861 and its sub-proposals. (#2141, #2148, #2149, #2150, #2151, #2159, #2164)

Spec Clarifications

Clarify behaviour when the topic key of a m.room.topic event is absent, null, or empty. (#2068)

Fix the example of the GET /sync endpoint and the m.room.member example used in several places. (#2077)

Clarify the format of third-party invites, including the fact that identity server public keys can be encoded using standard or URL-safe base64. (#2083)

"Public" rooms in profile look-ups are defined through their join rule and history visibility. (#2101)

"Public" rooms in user directory queries are defined through their join rule and history visibility. (#2102)

Rooms published in /publicRooms don't necessarily have public join rules or world_readable history visibility. (#2104)

"Public" rooms with respect to call invites are defined through their join rule. (#2106)

"Public" rooms have no specific meaning with respect to moderation policy lists. (#2107)

"Public" rooms with respect to presence are defined through their join rule. (#2108)

Spaces are subject to the same access mechanisms as rooms. (#2109)

Fix various typos throughout the specification. (#2121, #2144)

Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. (#2140)

Add missing fields in example for ExportedSessionData. (#2154)

Server-Server API

Backwards Compatible Changes

Add m.topic content block to enable rich text in m.room.topic events as per MSC3765. (#2095)

Extend /_matrix/federation/v1/hierarchy/{roomId} with the new optional properties encryption and room_version as per MSC3266. (#2125)

Spec Clarifications

Add a note to the invite endpoints that invites to local users may be received twice over federation if the homeserver is already in the room. (#2067)

Clarify the format of third-party invites, including the fact that identity server public keys can be encoded using standard or URL-safe base64. (#2083)

Clarify that auth event of content.join_authorised_via_users_server is only necessary for m.room.member with a membership of join. (#2100)

Rooms published in /publicRooms don't necessarily have public join rules or world_readable history visibility. (#2104)

Fix various typos throughout the specification. (#2128)

Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. (#2140)

Application Service API

Spec Clarifications

Clarify in the application service registration schema the url: null behaviour. (#2130)

Identity Service API

Spec Clarifications

Clarify that public keys can be encoded using standard or URL-safe base64. (#2083)

Push Gateway API

No significant changes.

Room Versions

No significant changes.

Appendices

No significant changes.

Internal Changes/Tooling

Spec Clarifications

Adjust margins in rendered endpoints. (#2081)

Replace Hugo shortcodes in OpenAPI output. (#2088)

Add well-known funding manifest urls to spec to authorise https://matrix.org/funding.json. Contributed by @HarHarLinks. (#2115)

Fix the historical info box when generating the historical spec in CI. (#2123)

Update the header navigation menu with links to modern matrix.org. Contributed by @HarHarLinks. (#2137)

Original source

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.

The full changelog

The full changelog for Matrix 1.14 is:

Client-Server API

New Endpoints

Add POST /_matrix/client/v3/users/{userId}/report, as per MSC4260. (#2093)

Removed Endpoints

Remove server_name parameter from /_matrix/client/v3/join/{roomIdOrAlias} and /_matrix/client/v3/knock/{roomIdOrAlias}, as per MSC4213. (#2059)

Spec Clarifications

The POST /_matrix/client/v3/rooms/{roomId}/initialSync endpoint is no longer deprecated, as it is still used for peeking. (#2036)

Clarify wording in the /join endpoints' summaries and descriptions. Contributed by @HarHarLinks. (#2038)

Clarify formats of string types. (#2046)

Fix various typos throughout the specification. (#2047, #2048, #2080, #2091)

Document the instance_id field of Protocol Instance in the responses to GET /_matrix/client/v3/thirdparty/protocols and GET /_matrix/client/v3/thirdparty/protocol/{protocol}. (#2051)

Applying redactions is a SHOULD for clients. (#2055)

Clarify which rooms are returned from /hierarchy. (#2064)

Clients can choose which history visibility options they offer to users when creating rooms. (#2072)

Server-Server API

Spec Clarifications

Remove the origin field in PUT /send_join responses, because it was never sent in the first place. (#2050)

Clarify that m.join_rules should be in the auth_events of an m.room.member event with a membership of knock. (#2063)

Remove an erroneous room_id field in a few examples. (#2076)

Application Service API

No significant changes.

Identity Service API

No significant changes.

Push Gateway API

No significant changes.

Room Versions

Backwards Compatible Changes

Update the default room version to 11, as per MSC4239. (#2105)

Spec Clarifications

For room versions 6 and 7, clarify in the authorization rules that m.federate must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. (#2065)

Fix various typos throughout the specification. (#2066)

Refactor PDU definitions to reduce duplication. (#2070)

Clarify the maximum depth value for room versions 6, 7, 8, 9, 10, and 11. (#2114)

Appendices

Spec Clarifications

Clarify that arbitrary unicode is allowed in user/room IDs and room aliases. (#1506)

Internal Changes/Tooling

Spec Clarifications

Generate the changelog release info with Hugo, rather than the changelog generation script. (#2033)

Update release steps documentation. (#2041)

Remove unused release_date from Hugo config. (#2042)

Clarify that v1.0 of Matrix was a release prior to the current global versioning system. (#2045)

Fix syntax highlighting and click-to-copy buttons for code blocks by purging less CSS. (#2049)

Fix the version of the Identity Service API when Matrix 1.0 was introduced. (#2061)

Fix parsing of nested slices in resolve-refs and resolve-allof partials. (#2069)

Deduplicate the definition of RoomKeysUpdateResponse. (#2073)

Deduplicate the definitions of Invite3pid. (#2074)

Support more locations for examples in OpenAPI definitions and JSON schemas. (#2076)

Add link to the git commit for the unstable changelog. (#2078)

Original source

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 :)

Account suspension

Last release brought Account Locking to the spec, and this release brings Account Suspension - a highly related but semantically different feature. Locking prevents the user from accessing their account, typically as a consequence of security reasons or restrictions, while suspension aims to disrupt while retaining a (mostly) readonly experience for the user. Both actions are reversible, and available to safety and security teams to help manage their servers with alternatives to deactivation (a destructive, irreversible, action).

Clients should continue calling /sync to detect when a lock/suspension is lifted (or converted to deactivation). MSC3939 and MSC3823 both have suggestions on what a UI could look like for the different states.

Reporting rooms

Event reporting has been in the spec since the very early days of Matrix, allowing users to send concerns about particular content to their homeserver administrators for review. A notable gap in this functionality is being able to report whole rooms from the public room directory or out of band in general - this has been addressed in Matrix 1.13 with the new report room endpoint.

The T&S team continues to work on designing a possible replacement to reporting in general, considering functionality like appeals, report-to-moderators, classification, and other quality of life improvements.

Up next in Matrix 1.14 and 2025

Mentioned earlier in this post, Matrix 1.14 is expected to be released around FOSDEM 2025 in early February. Many of the Matrix 2.0 features, like OIDC and Simplified Sliding Sync, are getting ever-closer to the needed proposed-FCP state to become part of the spec. We currently expect that the Matrix 2.0 features will land in either Matrix 1.14 or Matrix 1.15, converting the applicable release to Matrix 2.0 as a specification version. This is highly dependent on the MSCs progressing through FCP though, and may get pushed out as needed.

As always, if there’s an MSC ready for FCP, let us know in the SCT Office room! We’re currently on an administrative break until January 8th, 2025, but we’re still around and prioritizing features as we see them.

The full changelog

The full changelog for Matrix 1.13 is:

Client-Server API

New Endpoints

Add POST /_matrix/client/v3/rooms/{roomId}/report, as per MSC4151. (#1938, #2028)

Backwards Compatible Changes

Add error codes to requestToken endpoints, as per MSC4178. (#1944)

Remove reply fallbacks, as per MSC2781. (#1994)

Clarify the allowed HTTP methods in CORS responses, as per MSC4138. (#1995, #2011)

Add new M_USER_SUSPENDED error code behaviour, as per MSC3823. (#2014)

Spec Clarifications

The reason parameter in POST /_matrix/client/v3/rooms/{roomId}/report/{eventId} can be omitted instead of left blank, as per MSC2414. (#1938)

Correct OpenAPI specification for query parameters to GET /_matrix/client/v3/thirdparty/location/{protocol} endpoint. (#1947)

Sort VoIP events semantically. (#1967)

Clarify that servers must forward custom keys in PusherData when sending notifications to the push gateway. (#1973)

Clarify formats of string types. (#1978, #1979, #1980)

Clarify that the async upload endpoint will return 404 in some cases. (#1983)

Remove distinction between StateFilter and RoomEventFilter. (#2015)

Add hyperlinks throughout the specification. (#2016)

Use json instead of json5 for syntax highlighting. (#2017)

Specify order that one-time keys are issued by /keys/claim, as per MSC4225. (#2029)

Server-Server API

Backwards Compatible Changes

Make ACLs apply to EDUs, as per MSC4163. (#2004)

Spec Clarifications

Add 403 error response to /_matrix/federation/v1/state_ids/{roomId}. (#1926)

Application Service API

Backwards Compatible Changes

Allow sending ephemeral data to application services, as per MSC2409. (#2018)

Identity Service API

No significant changes.

Push Gateway API

Spec Clarifications

Document the schema of PusherData. (#1968)

The path of HTTP pusher URLs is fixed to /_matrix/push/v1/notify. (#1974)

Room Versions

Spec Clarifications

Clarify rule 4.3.1 of the auth rules in room version 11 to state which event's sender the state_key needs to match. (#2024)

Appendices

Spec Clarifications

Remove note about reference implementations. (#1966)

Internal Changes/Tooling

Spec Clarifications

Add x-weight property for sorting events rendered with the event-group shortcode. (#1967)

Enforce consistent vertical spacing between paragraphs in endpoint definitions. (#1969, #2005)

Remove boxes/added-in-paragraph shortcode. (#1970)

Remove withVersioning parameter of rver-fragment shortcode. (#1971)

Remove span element from added-in and changed-in shortcodes. (#1972)

Fix formatting of added-in and changed-in shortcodes by using % delimiter. (#1975)

Remove CSS workaround for scroll-anchoring. (#1976)

Rename custom-formats.yaml to string-formats.yaml and update its docs. (#1977)

Fix relative URLs when serving the specification with a custom baseURL. (#1984, #1997)

Rename .htmltest.yaml to .htmltest.yml. (#1985)

Improve the JS script to highlight the current ToC entry. (#1991, #2002)

Upgrade docsy to 0.11.0 and hugo to 0.139.0. (#1996, #2007)

Improve the quality of the rendered diagrams (#1999)

Update the Inter font and allow the browser to render the page before it is loaded (#2000)

Use a proper Matrix favicon (#2001)

Clean up unused CSS classes in openapi/render-operation partial. (#2003)

Fix changed-in partial when used with multiple paragraphs. (#2006)

Optimize generated CSS by removing unused selectors. (#2008)

Remove trailing slash on void HTML elements. (#2009)

Remove type and language attributes of script element. (#2021)

Change the accessible role of info boxes to note. (#2022)

Original source

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)

Original source

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.

MSC3916: Authenticated Media

The Trust & Safety team has been hard at work fixing the design flaw in media mentioned above, taking MSC3916 under their wing and bringing it to release here. The goal has been to roll out the feature as fast as possible, and that’s culminated in the following plan after consultations with us on the Spec Core Team.

Servers are encouraged to freeze unauthenticated media access (i.e. only allow historical media to be accessed without auth) before Matrix 1.12 is released, which we anticipate will happen in about August 2024. Any media which is cached or uploaded before that freeze will remain accessible on the unauthenticated endpoints indefinitely to avoid breaking existing links in social media, external chats, etc. Media which is cached or uploaded after the freeze takes place will only be accessible through the new authenticated endpoints - callers will receive a 404 error on the unauthenticated side.

The MSC has a bit more detail about the side effects of this approach, and more on the considerations leading to this proposed plan. Implementations might choose to support a config flag to enable/disable the freeze as needed, or simply release a version which freezes unauthenticated media on startup. Either are effective approaches for improving user safety and privacy.

Each homeserver should additionally consider its local ecosystem before freezing unauthenticated media by ensuring bridges and the popular clients among users are ready for authenticated media in particular. Ideally, users should see no visible impact to this change being rolled out. To help encourage this, the matrix.org homeserver will be rolling out authenticated media relatively quickly itself - watch for news on the blog next week for specific timelines.

Client and server developers are encouraged to support authenticated media as soon as they can to help server admins make the switch. Servers have a bit more work to do than clients, unfortunately, but both should have a reasonably easy time adding in the relevant support. The T&S team have made themselves available in #matrix-client-developers:matrix.org and #matrix-homeserver-developers:matrix.org to help developers implement this new feature - feel free to visit the respective room for your project and ask questions.

Below is some implementation guidance for developers, though is not a replacement for the spec. Where this post and the spec differ, please prefer the spec. :)

Client implementation guidance

Thankfully, supporting authenticated media should be relatively trivial for most clients. When the homeserver declares support for Matrix 1.11 through /versions, the client should use the new /_matrix/client/v1/media/* endpoints, noting that they now require authentication. The user’s access token can be supplied using the Authorization header. (Note that using the query string ?access_token method is not recommended, and deprecated in Matrix 1.11 for all endpoints.)

If the server doesn’t support Matrix 1.11, the existing /_matrix/media/* endpoints should continue to be used.

This may end up looking something like the following in a client:

ուղ?

Original source

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)

Original source

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)

Original source

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)

Original source

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 👀

🔗🖼️ Finally, improvements to media in Matrix

The media repo has been largely unchanged since it was first released in 2015 as r0.0.0 - the only change being the addition of URL previews in r0.3.0 (released in 2017). Thankfully, the folks over at Beeper have been busy changing this situation!

MSC3860 and MSC2246 are both available as of today in the spec, improving how much bandwidth media repos need to offer and fixing a long-standing issue where uploading large files can be a challenge. MSC3860, specified here as allow_redirect, allows clients to opt-in to HTTP redirects on downloads, avoiding slowdowns from the server having to proxy and move the media twice. It’s particularly useful if your server uses a CDN like S3 to host media - just tell clients to go grab media directly from S3 instead.

Meanwhile, MSC2246 (largely specified here) gives clients an ability to upload their media after sending the associated event. The MSC was originally designed with bridges in mind, where message order and delays are very perceivable problems for users, however clients like Element X are thinking about using the feature to improve local echo on uploads as well. We’re excited to see uploads finally be reliable, and non-blocking for the conversation flow!

History would indicate that we’ve got several years to go before the next major improvement to media, but we’re looking to change that: MSC3916: Authentication for media, MSC4016: Streaming E2EE file transfers, and MSC3870: Upload direct to URL are all fairly promising MSCs we’re planning to take a look at in the next year or so.

🔗💖 Reactions are here

Reactions have actually been in use for quite some time already, but the MSC struggled to make it into the spec formally. With Matrix 1.7 though, MSC2677 is merged.

MSC2677 was the last part of the MSC1849 saga, with MSC2674 (relationships) and MSC2675 (server-side aggregation) landing in Matrix 1.3, and MSC2676 (edits) landing in Matrix 1.4 back in September 2022. There’s still some work to be done in this area though, and certainly some quality of life improvements asking to be written up as MSCs - watch this space for progress on those fronts.

🔗🎉 Achievement: First MSC merged

One of the best parts about writing an MSC is eventually seeing it released in the spec, and these folks saw their MSCs reach this milestone for the first time. Congratulations everyone, and please keep them coming!

In no particular order:

• benkuly with MSC3925 (their first ever MSC!).
• Fizzadar with MSC3758 and MSC3860.
• hughns with MSC3970 and MSC3882.
• Johennes with MSC3873.

Anyone can contribute MSCs, improving the whole of Matrix for everyone. If you have an idea (or bugfix), check out the guidelines and let us know if you run into any questions in #matrix-spec:matrix.org on Matrix - we’re always happy to help.

🔗🔜 Early considerations for Matrix 1.8

The SCT aims to cut a release in the middle of each calendar quarter, largely to avoid most conflicts with regional holidays, and since Matrix 1.1 the releases have been getting less and less organic. Instead of looking at MSCs whenever they’re raised, the SCT has been aiming to hear about which MSCs will need looking at. This is a very subtle difference, but one that dramatically changes how the quarterly releases are structured.

With each spec release, the SCT has slowly been working towards a place where the majority of MSC work is thought about in advance, and Matrix 1.8 is another milestone along this journey. Over the next couple weeks we’ll be working on a roadmap based on the MSCs that are raised to us in the SCT Office room on Matrix, starting with the ideas we raised ourselves earlier in the year.

As of writing, our current plan for Matrix 1.8 includes:

• Further work on adopting OIDC (namely progress on MSC3824, MSC2965, and other similar proposals).
• Pushing the MSC3995 suite of MSCs towards acceptance/merge status.
• Continuing the improvements of VoIP (MatrixRTC) as we work towards Matrix 2.0.
• Various improvements to event relationships, such as MSC3981, and push in general, such as MSC3958 and MSC3391.

While this doesn’t represent a commitment to have these MSCs merged, these are the areas that the SCT is likely to be thinking about for the next 3ish months. If you have MSCs that might be possible to merge before roughly August, let us know in the SCT Office room (even if those MSCs aren’t on-theme with the above - we still want to hear about them!).

Critically, our release planning does not just include MSCs that are on track for being merged. We are also aiming to track that a given MSC needs technical review (for example), or that it might be receiving attention external to the SCT (such as implementation). We’d love to hear what you’re working on so we can start bringing those MSCs to the top of the list - let us know in the SCT Office room.

As is the theme for this section, if you have any questions about what the release process looks like (or where a given MSC currently sits in the roadmap), let us know in the SCT Office room.

🔗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. Special thanks to MichaelKohler, zecakeh, and Cadair for contributing clarification & bug fix PRs in this release - we greatly appreciate it!

🔗Client-Server API

New Endpoints

• POST /_matrix/media/v1/create (#1499)
• PUT /_matrix/media/v3/upload/{serverName}/{mediaId} (#1499)
• POST /_matrix/client/v1/login/get_token (#1530)

Backwards Compatible Changes

• Changes to the server-side aggregation of m.replace (edit) events, as per MSC3925. (#1440, #1525)
• Add new push rule conditions event_property_is and event_property_contains, as per MSC3758 and MSC3966. (#1464)
• Add m.annotation relations (reactions), as per MSC2677. (#1475, #1531)
• Support asynchronous media uploads, as per MSC2246. (#1499, #1510)
• Document the m.mentions property; the .m.rule.is_user_mention and .m.rule.is_room_mention push rules; and other notification behaviour, as per MSC3952. (#1508)
• Improve VoIP signaling, as per MSC2746. (#1511, #1540)
• Update the scope of transaction IDs, as per MSC3970. (#1526)
• Add an ability to redirect media downloads, as per MSC3860. (#1529)
• Add an ability to use an existing session to log in another, as per MSC3882. (#1530)

Spec Clarifications

• Clarify the sections of the specification concerning aggregation of child events. (#1424)
• Fix various typos throughout the specification. (#1432, #1442, #1447, #1455, #1465, #1500, #1509)
• Clarify that reply chain fallback for threads might not be present. (#1439)
• Clarify what event property the content-specific push rules match against. (#1441)
• Clarify the semantics that make requests idempotent. (#1449)
• Improve documentation of how clients use push rules. (#1461)
• Clarify that servers should enforce a default limit on a filter if one is not specified. (#1463)
• Disambiguate using property names with dots in them during push rule processing, as per MSC3873 and MSC3980. (#1464)
• Fix phrasing & typography in the registration endpoint description. Contributed by @HarHarLinks. (#1474)
• Remove outdated text saying that state_default is 0 if there is no m.room.power_levels event in a room. (#1479)
• Remove fictitious token parameter on /keys/query endpoint. (#1485)
• Fix rendering of properties with a list of types. (#1487)
• Clarify parts of the cross-signing signature upload request. (#1495)
• Remove the dont_notify and coalesce push rule actions, as per MSC3987. (#1501)
• Clarify m.location scheme by partially reverting f1f32d3. Contributed by @HarHarLinks. (#1507)
• Add missing knock_restricted join rule to the m.room.join_rules schema. (#1535)

🔗Server-Server API

Spec Clarifications

• Fix various typos throughout the specification. (#1431, #1447, #1466, #1518)
• Fix PDU examples by removing invalid OpenAPI reference to examples/minimal_pdu.json. (#1454)
• Remove leftover {key_id} from /_matrix/key/v2/server/. (#1473)
• Remove extraneous age_ts field from the reference hash calculation section. (#1536)

🔗Application Service API

New Endpoints

• POST /_matrix/app/v1/ping (#1516)
• POST /_matrix/client/v1/appservice/{appserviceId}/ping (#1516)

Backwards Compatible Changes

• Add homeserver->appservice ping mechanism, as per MSC2659. Contributed by @tulir at @beeper. (#1516, #1541)

Spec Clarifications

• Fix various typos throughout the specification. (#1447)

🔗Identity Service API

Spec Clarifications

• Corrections to the response format of /_matrix/identity/v2/store-invite. (#1486)

🔗Push Gateway API

No significant changes.

🔗Room Versions

Spec Clarifications

• Clarifications of event ID formats in early room versions (#1484)

🔗Appendices

Spec Clarifications

• Clarify that the term "Canonical JSON" is a specific thing within the Matrix specification. (#1468)
• Remove references to groups. (#1483)
• Clarifications of event ID formats in early room versions. (#1484)

🔗Internal Changes/Tooling

Spec Clarifications

• Update references to Inter font. (#1444)
• Endpoint disclosures now hide everything but the URL. (#1446)
• Wrap $ref in allOf where other attributes are present, to improve OpenAPI compliance. (#1457)
• Minor cleanups to the GitHub Actions workflows (#1476)
• Fix generation of anchors for additional properties. (#1488)
• Fix various typos throughout the specification. (#1534)
• Document more of the spec release timeline/process. (#1538)

Original source

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.

Original source

Greetings Matrix fans! We've published Synapse version 1.78 as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience. Please take a look at the upgrade notes for any important information about upgrading.

Announcements

Please note that Synapse 1.78.0 replaces the /_synapse/admin/v1/media/<server_name>/delete admin API with an identical endpoint at /_synapse/admin/v1/media/delete. Please update your tooling to use the new endpoint. The deprecated version will be removed in a future release.

The new stuff

In case you were unaware, Synapse has a command line export data command which allows administrators to export data for a specific user (you can read more about this command here).

Synapse 1.78.0 updates this command adding account data to the user information that is returned by the export data command.

This version of Synapse also features a few changes to push rules, with implementations for MSC3758:
Add event_property_is push rule condition kind,
MSC3966: event_property_contains push rule condition, and the removal of the spurious dont_notify action from the defaults for the .m.rule.reaction pushrule. These changes empower end users to more fully customise their notification rules - MSC3758 allows users to ask to be notified when a field in an event contains any type of value, rather than only matching on strings, and MSC3966 provides crucial scaffolding for MSC3952: Intentional Mentions, which aims to eliminate unintentional mentions and improve the experience of mentions in general.

Synapse v1.78.0 includes some fixes for faster-joins related bugs as we work out the kinks. Some of these include a fix for a bug introduced in Synapse 1.76.0 where partially-joined rooms could not be deleted using the purge room API, and a fix for a bug introduced in Synapse 1.75 where the portdb script would fail to run after a room had been faster-joined. We continue to work to polish faster joins, and thank everyone who filed an issue.

Finally, for those deployments using workers, v1.78.0 fixed a bug introduced in Synapse 1.76 where 5s delays would occasionally occur.

Everything else

See the full changelog for a complete list of changes in the release. Also please have a look at the upgrade notes.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order): jahway603, williamkray, 999lakhisidhu, hari01584, saddfox, dklimpel, realtyem V02460, and thezaidbintariq.

We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.

Original source

Greetings Matrix fans! We've published Synapse version 1.77 as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience.

The new stuff

Experimental support for intentional mentions (MSC3952)

Mentioning other users on Matrix is difficult: it is not possible to know if mentioning a user by display name or Matrix ID will count as a mention, but is also too easy to mistakenly mention a user. MSC3952 proposes a solution. Its idea is to make the mentioning explicit in the protocol using a dedicated event property, instead of relying on searching the body of the message as before.

Synapse now implements this as an experimental feature.

Experimental support to suppress notifications from message edits (MSC3958)

Have you ever been annoyed by a noisy notification that keep coming back, but you can't pinpoint where it's coming from?

This is usually because edits to a message where you are mentioned (or that mention @room) will retrigger a noisy notification. That can be pretty annoying when the message is edited 10 times! MSC3958 is here to solve that, and Synapse now implements it as an experimental feature.

The quest for speed continues!

Some iterative optimizations have been implemented that should make joining or leaving large rooms even faster, and should also improve sending message.

Everything else

See the full changelog, for a complete list of changes in the release.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to these releases, including (in no particular order) icp1994, dklimpel, Fizzadar and realtyem.

We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.

Original source