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)

The Foundation needs you

The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.

It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.

Support us