Matrix.org - Releases

Matrix v1.18 release

2026-03-26T16:00:43+00:00

Hey all,</p>

Today’s release of Matrix 1.18</a> 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.</p> </span>

🔗</a>Policy servers</h2>
After about a year of development, policy servers</a> have made their way into the stable spec. Typically paired with reactive tooling like moderation bots, these servers can optionally</em> 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.</p>
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.</p>
For more information on what policy servers can be used for, read the announcement post</a> for the Foundation’s own implementation, named policyserv.</p>

🔗</a>Invite blocking</h2>
Several proposals (tracked largely by MSC4192</a>) 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</em> into the spec, MSC4380</a> boiled the feature down to its essential component: a single on/off toggle for invites</a>. Future expansion to block based on servers, user IDs, Space members, etc is possible and tracked in other MSCs like MSC4155</a>.</p>
We look forward to seeing design teams take on those more advanced safety controls to expand the capabilities of invite blocking beyond MSC4380</a>’s simple toggle!</p>
🔗</a>Account suspension & locking</h2>
Account suspension and locking were introduced back around Matrix 1.13</a>, 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.</p>
🔗</a>Reporting improvements</h2>
Though small, MSC4277</a> harmonizes the various reporting endpoints</a> 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!</p>
🔗</a>The full changelog</h2>
The full changelog for Matrix 1.18 is:</p>
🔗</a>Client-Server API</h3>
New Endpoints</strong></p>
Add `GET /_matrix/client/v1/admin/suspend/{userId}</code>, as per` `MSC4323</a>. (#2278</a>)</li>`
`Add PUT /_matrix/client/v1/admin/suspend/{userId}</code>, as per MSC4323</a>. (#2278</a>)</li>`
`Add GET /_matrix/client/v1/admin/lock/{userId}</code>, as per MSC4323</a>. (#2278</a>)</li>`
Add PUT /_matrix/client/v1/admin/lock/{userId}</code>, as per MSC4323</a>. (#2278</a>)</li> </ul> Removed Endpoints</strong></p> The score</code> request parameter on /_matrix/client/v3/rooms/{roomId}/report/{eventId}</code> was removed as per MSC4277</a>. (#2311</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add the account management capabilities for the OAuth 2.0 authentication API, as per MSC4191</a>. (#2270</a>)</li> Add OAuth 2.0 aware clients, as per MSC3824</a>. (#2272</a>)</li> Add administrator endpoints to lock and suspend server-local users and add the m.account_management</code> capability, as per MSC4323</a>. (#2278</a>)</li> Add m.recent_emoji</code> account data event to track recently used emoji as per MSC4356</a>. (#2291</a>)</li> Add m.forget_forced_upon_leave</code> capability for servers to transparently auto-forget rooms that the user leaves as per MSC4267</a>. (#2292</a>)</li> Add support for m.room.redaction</code> events at the PUT /rooms/{roomId}/send/{eventType}/{txnId}</code> endpoint, as per MSC4169</a>. (#2298</a>)</li> Clients supporting the ol</code> HTML element must also support the start</code> attribute, as per MSC4313</a>. (#2299</a>)</li> Add recommendation about excluding non-cross-signed devices from encrypted conversations, as per MSC4153</a>. (#2301</a>)</li> Add invite blocking, as per MSC4380</a>. (#2305</a>)</li> /_matrix/client/v3/rooms/{roomId}/report</code> and /_matrix/client/v3/rooms/{roomId}/report/{eventId}</code> may respond with HTTP 200 regardless of the reported subject's existence or add a random delay when generating responses as per MSC4277</a>. (#2311</a>)</li> Add M_USER_LIMIT_EXCEEDED</code> common error code, as per MSC4335</a>. (#2315</a>)</li> Add the OAuth 2.0 Device Authorization Grant (RFC 8628) as a supported grant type, as per MSC4341</a>. (#2320</a>)</li> Add the is_animated</code> flag to the info</code> object of the m.image</code> msgtype and the m.sticker</code> event, as per MSC4230</a>. (#2328</a>, #2338</a>)</li> Add a "Policy Servers" module, as per MSC4284</a>. (#2332</a>)</li> </ul> Spec Clarifications</strong></p> The optional submit_url</code> response parameter of the /requestToken</code> endpoints uses the same request and response parameters and error codes as the Identity Service API's POST /_matrix/identity/v2/validate/email/submitToken</code>, as per MSC4183</a>. (#2277</a>)</li> Update non-historic mentions of matrix-doc repo to matrix-spec/-proposals. Contributed by @HarHarLinks. (#2280</a>)</li> Remove unintended TeX formatting. Contributed by @HarHarLinks. (#2283</a>)</li> Clarify the requiredness of event_id</code> in predecessor</code>. (#2304</a>)</li> Clarify terminology for keys in cross-signing module. (#2306</a>)</li> Add 404 responses to the OpenAPI of GET /login</code> and GET /auth_metadata</code> endpoints. The responses were already defined in text but not written in OpenAPI. (#2316</a>)</li> Fix various typos throughout the specification. Contributed by @HarHarLinks. (#2318</a>)</li> Clarified attachment encryption to require secure generation of keys and hash verification. (#2324</a>)</li> Order the common and other error codes alphabetically and remove duplicate M_THREEPID_IN_USE</code> definition. (#2336</a>)</li> Fix various typos throughout the specification. (#2337</a>)</li> </ul> 🔗</a>Server-Server API</h3> Removed Endpoints</strong></p> Remove /v1/send_join</code> and /v1/send_leave</code>, as per MSC4376</a>. (#2319</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add a concept of "Policy Servers", as per MSC4284</a>. (#2332</a>)</li> </ul> Spec Clarifications</strong></p> Clarify what the minimum_valid_until_ts</code> field means when it is set in key queries. (#2191</a>)</li> Specify validation for PDUs passed to and returned from federation membership endpoints. (#2284</a>)</li> Specify that callers of /_matrix/federation/v1/openid/userinfo</code> must validate the returned user ID. (#2288</a>)</li> Change m.signing_update</code> typo to m.signing_key_update</code>. Contributed by @velikopter (#2300</a>)</li> Add link to JSON signing algorithm in server-server auth section for clarity. Contributed by @thetayloredman. (#2329</a>)</li> Fix various typos throughout the specification. (#2338</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#2330</a>)</li> </ul> 🔗</a>Identity Service API</h3> Spec Clarifications</strong></p> Clarify the error codes that can be returned with a 400 HTTP status code by the POST /_matrix/identity/v2/validate/email/submitToken</code> and POST /_matrix/identity/v2/validate/msisdn/submitToken</code> endpoints, introducing the M_TOKEN_INCORRECT</code> error code, as per MSC4183</a>. (#2277</a>)</li> Order the standard error codes alphabetically. (#2336</a>)</li> </ul> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> Clarify meaning of floating-point powerlevels. (#2297</a>)</li> Remove the post-1.16 release note for room version 12. (#2303</a>)</li> </ul> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Add identifier pronunciation guidelines. Contributed by @HarHarLinks. (#2307</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Include the spec release version in the filenames in the tarballs generated by CI. (#2276</a>)</li> </ul> Spec Clarifications</strong></p> Clarify vendor prefixing requirements. (#2222</a>)</li> Auto-create draft releases when building release tags. (#2275</a>)</li> Replace the Twitter link in the footer with our BlueSky and Mastodon socials. (#2282</a>)</li> Upgrade to docsy v0.13.0. (#2287</a>)</li> Updates to the release documentation. (#2289</a>)</li> Remove unused leftover CSS files. (#2290</a>)</li> Update the footer social links to match matrix.org. Contributed by @HarHarLinks. (#2317</a>)</li> Fix various typos throughout the specification. Contributed by @HarHarLinks. (#2318</a>)</li> Render error code sections as definition lists to improve readability. (#2323</a>)</li> </ul>

Matrix v1.17 specification released 2025-12-18T16:00:00+00:00 Hey all,</p> At this year’s Matrix Conference we said</a> 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.</p> Today we’re releasing Matrix 1.17</a> 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.</p> Improvements to the spec website</a> include a dropdown to get at old spec versions more easily, and an index of HTTP endpoints at the top of each page.</p> This release of the spec also sees the incorporation of the specifications for the Olm and Megolm cryptographic ratchets</a>. Olm and Megolm themselves haven’t changed, but we did want them to be on the spec site :)</p> Thanks especially to Johannes and Kévin for continuing to improve the quality of the spec with features, clarifications, and MSC text!</p> </span> 🔗</a>The full changelog</h2> 🔗</a>Client-Server API</h3> Removed Endpoints</strong></p> Remove legacy mentions, as per MSC4210</a>. (#2186</a>)</li> </ul> Backwards Compatible Changes</strong></p> Allow application services to masquerade as specific devices belonging to users, as per MSC4326</a>. (#2221</a>)</li> Add the m.oauth</code> authentication type for User-Interactive Authentication, as per MSC4312</a>. (#2234</a>)</li> Allow application services to manage devices and register users without the legacy authentication API, as per MSC4190</a>. (#2267</a>)</li> </ul> Spec Clarifications</strong></p> Push rule IDs are globally unique within their kind. (#2214</a>)</li> Don't advertise creator</code> field in description of room creation. (#2215</a>)</li> room_id</code> is required for peeking via /_matrix/client/v3/events</code>. (#2216</a>)</li> The server-name</code> segment of MXC URIs is sanitised differently from the media-id</code> segment. (#2217</a>)</li> Add note to each endpoint that uses capability negotiation. (#2223</a>)</li> Additional OpenGraph properties can be present in URL previews. (#2225</a>)</li> Clarify the special casing of membership events and redactions in power levels. (#2231</a>)</li> M_RESOURCE_LIMIT_EXCEEDED</code> is now listed as a common error code. (#2232</a>)</li> Add m.login.terms</code> to enumeration of authentication types. (#2233</a>)</li> Clarify how to use state_after</code> ahead of declaring full support for its spec version. (#2240</a>)</li> device_one_time_keys_count</code> is only optional if no unclaimed one-time keys exist. (#2245</a>)</li> Clarify that servers may choose not to use M_USER_DEACTIVATED</code> at login time, for example for privacy reasons when they can't authenticate deactivated users. (#2246</a>)</li> Usage of the event_id_only</code> format for push notifications is not mandatory. (#2255</a>)</li> Fix various typos throughout the specification. (#2224</a>, #2227</a>, #2250</a>)</li> </ul> 🔗</a>Server-Server API</h3> No significant changes.</p> 🔗</a>Application Service API</h3> Backwards Compatible Changes</strong></p> Allow application services to masquerade as specific devices belonging to users, as per MSC4326</a>. (#2221</a>)</li> Allow application services to manage devices and register users without the legacy authentication API, as per MSC4190</a>. (#2267</a>)</li> </ul> Spec Clarifications</strong></p> Fix JSON formatting in the "Server admin style permissions" examples. (#2213</a>)</li> </ul> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> 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</a>)</li> 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</a>)</li> </ul> 🔗</a>Appendices</h3> No significant changes.</p> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Swapped icon for X (fka. twitter) to updated logo in footer. (#2219</a>)</li> Inline Olm & Megolm specifications. (#2226</a>, #2241</a>, #2242</a>)</li> Silence failing redocly-cli rule. (#2238</a>)</li> Use NPM Trusted Publishers for publishing @matrix-org/spec</code> to npm. (#2239</a>)</li> Add version picker in the navbar. (#2256</a>, #2258</a>, #2259</a>, #2260</a>, #2261</a>, #2264</a>, #2268</a>)</li> Add a list of endpoints to the top of each spec page. (#2262</a>)</li> </ul> Matrix v1.16 release 2025-09-17T16:00:43+00:00 Hey all,</p> Today’s Matrix 1.16</a> release brings two major features to the protocol: extensible profiles</strong></a> and room version 12</strong></a> from Project Hydra</a>! 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</a> covers the changes in more detail, so this post will focus on extensible profiles and our plan for Matrix 2.0.</p> As always, the full changelog and descriptions of the 9 MSCs released today is at the end of this post.</p> </span> 🔗</a>Extensible profiles</h2> 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.</p> Huge thanks and congratulations to Tom for landing this highly requested feature in their first-ever MSC</a>.</p> 🔗</a>Matrix 2.0</h2> Over the years we’ve talked</a> a lot about Matrix 2.0, and even demoed</a> 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</a> merged before the Matrix Conference</a> in October.</p> Watch this space and the Office of the Matrix Spec Core Team</a> room on Matrix for updates as we work toward Matrix 2.0/the conference.</p> 🔗</a>The full changelog</h2> The full changelog for Matrix 1.16 is:</p> 🔗</a>Client-Server API</h3> Deprecations</strong></p> Deprecate m.set_avatar_url</code> and m.set_displayname</code> capabilities, as per MSC4133</a>. (#2071</a>)</li> </ul> Removed Endpoints</strong></p> Remove unintentional intentional mentions in replies, as per MSC4142</a>. (#2210</a>)</li> </ul> Backwards Compatible Changes</strong></p> Update user profile endpoints to handle custom fields, and add a new m.profile_fields</code> capability, as per MSC4133</a>. (#2071</a>)</li> Add format</code> query parameter to GET /state/{eventType}/{stateKey}</code> to allow fetching metadata of a specific state event. (#2175</a>)</li> Add the use_state_after</code> query parameter and state_after</code> response property to GET /sync</code>, as per MSC4222</a>. (#2187</a>)</li> When upgrading rooms to room version 12</a>, additional_creators</code> may be specified on the POST /_matrix/client/v3/rooms/{roomId}/upgrade</code></a> endpoint, as per MSC4289</a>. (#2193</a>)</li> When creating rooms with room version 12</a>, the trusted_private_chat</code> preset should merge the invitees into the supplied content.additional_creators</code> in the resulting room, as per MSC4289</a>. (#2193</a>)</li> In room version 12</a>, the power level of room creators is now infinitely high as per MSC4289</a>. (#2193</a>)</li> In room version 12</a>, room IDs no longer have a domain component as per MSC4291</a>. (#2193</a>)</li> When creating rooms with room version 12</a>, the initial power levels will restrict the ability to upgrade rooms by default, as per MSC4289</a>. (#2193</a>)</li> Add a profile field for a user's time zone, as per MSC4175</a>. (#2206</a>)</li> Invites and knocks are now expected to contain the m.room.create</code> event in their stripped state entries, as per MSC4311</a>. (#2207</a>)</li> </ul> Spec Clarifications</strong></p> Clarify that format</code> is required if formatted_body</code> is specified. (#2167</a>)</li> The latest_event</code> in an aggregated set of thread events uses the same format as the event itself. (#2169</a>)</li> Fix various typos throughout the specification. (#2171</a>, #2177</a>, #2179</a>)</li> Clarify that clients should replace events with the most recent replacement by origin_server_ts</code>. (#2190</a>)</li> Fix /sync</code> flow referencing incorrect parameter to use with /messages</code>. (#2195</a>)</li> Clarify wording around the world_readable</code> history visibility setting. Contributed by @HarHarLinks. (#2204</a>)</li> </ul> 🔗</a>Server-Server API</h3> Backwards Compatible Changes</strong></p> invite_room_state</code> and knock_room_state</code> now have additional requirements and validation depending on the room version, as per MSC4311</a>. (#2207</a>)</li> </ul> 🔗</a>Application Service API</h3> No significant changes.</p> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Backwards Compatible Changes</strong></p> Room IDs in room version 12 are now the event ID of the create event with the normal room ID sigil (!</code>), as per MSC4291</a>. (#2193</a>)</li> Room creators are formalized in room version 12 and have infinitely high power level, as per MSC4289</a>. (#2193</a>)</li> State Resolution is updated in room version 12 to reduce the opportunity for "state resets", as per MSC4297</a>. (#2193</a>)</li> The default room version is now room version 12, though servers SHOULD keep using room version 11 for a little while, as per MSC4304</a>. (#2193</a>)</li> Add room version 12</a> as per MSC4304</a>. (#2193</a>, #2199</a>)</li> </ul> Spec Clarifications</strong></p> In room versions 1 through 12, an event's auth_events</code> have always needed to belong to the same room as per MSC4307</a>. (#2193</a>)</li> </ul> 🔗</a>Appendices</h3> Backwards Compatible Changes</strong></p> Room IDs can now appear without a domain component in room version 12</a>, as per MSC4291</a>. (#2193</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Add "placeholder MSC" process definition. (#2157</a>)</li> </ul> Spec Clarifications</strong></p> Declare the Application Service Registration schema to follow JSON Schema spec 2020-12. (#2132</a>)</li> Declare the event schemas to follow JSON Schema spec 2020-12. (#2132</a>)</li> Upgrade the docsy theme to version 0.12.0. (#2160</a>)</li> GitHub actions are now building the OpenAPI spec/identity-service-api/api.json</code> file. (#2172</a>)</li> Minor fixes to JSON schemas. (#2182</a>)</li> Specify a correct spelling for "display name". (#2189</a>)</li> Fix a grammatical typo on the Matrix Spec Process documentation page. (#2205</a>)</li> </ul> Matrix v1.15 release 2025-06-26T17:10:43+00:00 Hey all,</p> Matrix 1.15</a> is here with improvements to authentication, room summaries, and rich topics! A few months ago</a> we were starting to see the next generation authentication MSCs (led by MSC3861</a>) 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</a>'s generous contributions</a>.</p> 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.</p> </span> 🔗</a>Next-generation Authentication</h2> 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</a>, the work hit the spotlight in 2023</a> to outline how the system is expected to work, setting the stage for this year's incredible migration</a> of 110 million matrix.org users in just 30 minutes.</p> With the MSCs part of the spec</a>, 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</a> to the next-gen auth system which will be making their way towards the spec over the next while.</p> Congratulations to the team, and thanks for making Matrix a safer and more secure place.</p> 🔗</a>Room summaries</h2> MSC3266</a> 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</a>. 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</a> 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.</p> Thanks to Nico for bearing with us through the years of review, and final push to the spec itself.</p> 🔗</a>Rich topics</h2> Rooms can now be bold</strong> and use lists to the heart's content thanks to MSC3765</a> 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</a>, 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.</p> Thanks to Johannes for landing this highly requested feature in the spec.</p> 🔗</a>The full changelog</h2> The full changelog for Matrix 1.15 is:</p> 🔗</a>Client-Server API</h3> New Endpoints</strong></p> Add GET /_matrix/client/v1/room_summary/{roomIdOrAlias}</code>, as per MSC3266</a>. (#2125</a>)</li> Add GET /_matrix/client/v1/auth_metadata</code>, as per MSC2965</a>. (#2147</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add m.topic</code> content block to enable rich text in m.room.topic</code> events as per MSC3765</a>. (#2095</a>)</li> Include device keys with Olm-encrypted events as per MSC4147</a>. (#2122</a>)</li> Add /_matrix/client/v1/room_summary/{roomIdOrAlias}</code> and extend /_matrix/client/v1/rooms/{roomId}/hierarchy</code> with the new optional properties allowed_room_ids</code>, encryption</code> and room_version</code> as per MSC3266</a>. (#2125</a>, #2158</a>)</li> Add the OAuth 2.0 based authentication API, as per MSC3861</a> and its sub-proposals. (#2141</a>, #2148</a>, #2149</a>, #2150</a>, #2151</a>, #2159</a>, #2164</a>)</li> </ul> Spec Clarifications</strong></p> Clarify behaviour when the topic</code> key of a m.room.topic</code> event is absent, null, or empty. (#2068</a>)</li> Fix the example of the GET /sync</code> endpoint and the m.room.member</code> example used in several places. (#2077</a>)</li> 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</a>)</li> "Public" rooms in profile look-ups are defined through their join rule and history visibility. (#2101</a>)</li> "Public" rooms in user directory queries are defined through their join rule and history visibility. (#2102</a>)</li> Rooms published in /publicRooms</code> don't necessarily have public</code> join rules or world_readable</code> history visibility. (#2104</a>)</li> "Public" rooms with respect to call invites are defined through their join rule. (#2106</a>)</li> "Public" rooms have no specific meaning with respect to moderation policy lists. (#2107</a>)</li> "Public" rooms with respect to presence are defined through their join rule. (#2108</a>)</li> Spaces are subject to the same access mechanisms as rooms. (#2109</a>)</li> Fix various typos throughout the specification. (#2121</a>, #2144</a>)</li> Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. (#2140</a>)</li> Add missing fields in example for ExportedSessionData</code>. (#2154</a>)</li> </ul> 🔗</a>Server-Server API</h2> Backwards Compatible Changes</strong></p> Add m.topic</code> content block to enable rich text in m.room.topic</code> events as per MSC3765</a>. (#2095</a>)</li> Extend /_matrix/federation/v1/hierarchy/{roomId}</code> with the new optional properties encryption</code> and room_version</code> as per MSC3266</a>. (#2125</a>)</li> </ul> Spec Clarifications</strong></p> 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</a>)</li> 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</a>)</li> Clarify that auth event of content.join_authorised_via_users_server</code> is only necessary for m.room.member</code> with a membership</code> of join</code>. (#2100</a>)</li> Rooms published in /publicRooms</code> don't necessarily have public</code> join rules or world_readable</code> history visibility. (#2104</a>)</li> Fix various typos throughout the specification. (#2128</a>)</li> Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. (#2140</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Clarify in the application service registration schema the url: null</code> behaviour. (#2130</a>)</li> </ul> 🔗</a>Identity Service API</h3> Spec Clarifications</strong></p> Clarify that public keys can be encoded using standard or URL-safe base64. (#2083</a>)</li> </ul> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> No significant changes.</p> 🔗</a>Appendices</h3> No significant changes.</p> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Adjust margins in rendered endpoints. (#2081</a>)</li> Replace Hugo shortcodes in OpenAPI output. (#2088</a>)</li> Add well-known funding manifest urls</a> to spec to authorise https://matrix.org/funding.json</a>. Contributed by @HarHarLinks. (#2115</a>)</li> Fix the historical info box when generating the historical spec in CI. (#2123</a>)</li> Update the header navigation menu with links to modern matrix.org. Contributed by @HarHarLinks. (#2137</a>)</li> </ul> Matrix v1.14 release 2025-03-27T16:53:43+00:00 Hey all,</p> We're right at the end of Q1 2025 with a new spec release: Matrix 1.14</a>! Our original plan</a> 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.</p> 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</a>, to complement last release's report room endpoint - everything else is primarily maintenance of the spec. The full changelog is below, as always.</p> </span> 🔗</a>The full changelog</h2> The full changelog for Matrix 1.14 is:</p> 🔗</a>Client-Server API</h3> New Endpoints</strong></p> Add POST /_matrix/client/v3/users/{userId}/report</code>, as per MSC4260</a>. (#2093</a>)</li> </ul> Removed Endpoints</strong></p> Remove server_name</code> parameter from /_matrix/client/v3/join/{roomIdOrAlias}</code> and /_matrix/client/v3/knock/{roomIdOrAlias}</code>, as per MSC4213</a>. (#2059</a>)</li> </ul> Spec Clarifications</strong></p> The POST /_matrix/client/v3/rooms/{roomId}/initialSync</code> endpoint is no longer deprecated, as it is still used for peeking. (#2036</a>)</li> Clarify wording in the /join</code> endpoints' summaries and descriptions. Contributed by @HarHarLinks. (#2038</a>)</li> Clarify formats of string types. (#2046</a>)</li> Fix various typos throughout the specification. (#2047</a>, #2048</a>, #2080</a>, #2091</a>)</li> Document the instance_id</code> field of Protocol Instance</code> in the responses to GET /_matrix/client/v3/thirdparty/protocols</code> and GET /_matrix/client/v3/thirdparty/protocol/{protocol}</code>. (#2051</a>)</li> Applying redactions is a SHOULD for clients. (#2055</a>)</li> Clarify which rooms are returned from /hierarchy</code>. (#2064</a>)</li> Clients can choose which history visibility options they offer to users when creating rooms. (#2072</a>)</li> </ul> 🔗</a>Server-Server API</h3> Spec Clarifications</strong></p> Remove the origin</code> field in PUT /send_join</code> responses, because it was never sent in the first place. (#2050</a>)</li> Clarify that m.join_rules</code> should be in the auth_events</code> of an m.room.member</code> event with a membership</code> of knock</code>. (#2063</a>)</li> Remove an erroneous room_id</code> field in a few examples. (#2076</a>)</li> </ul> 🔗</a>Application Service API</h3> No significant changes.</p> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Backwards Compatible Changes</strong></p> Update the default room version to 11, as per MSC4239</a>. (#2105</a>)</li> </ul> Spec Clarifications</strong></p> For room versions 6 and 7, clarify in the authorization rules that m.federate</code> must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. (#2065</a>)</li> Fix various typos throughout the specification. (#2066</a>)</li> Refactor PDU definitions to reduce duplication. (#2070</a>)</li> Clarify the maximum depth</code> value for room versions 6, 7, 8, 9, 10, and 11. (#2114</a>)</li> </ul> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Clarify that arbitrary unicode is allowed in user/room IDs and room aliases. (#1506</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Generate the changelog release info with Hugo, rather than the changelog generation script. (#2033</a>)</li> Update release steps documentation. (#2041</a>)</li> Remove unused release_date</code> from Hugo config. (#2042</a>)</li> Clarify that v1.0 of Matrix was a release prior to the current global versioning system. (#2045</a>)</li> Fix syntax highlighting and click-to-copy buttons for code blocks by purging less CSS. (#2049</a>)</li> Fix the version of the Identity Service API when Matrix 1.0 was introduced. (#2061</a>)</li> Fix parsing of nested slices in resolve-refs</code> and resolve-allof</code> partials. (#2069</a>)</li> Deduplicate the definition of RoomKeysUpdateResponse</code>. (#2073</a>)</li> Deduplicate the definitions of Invite3pid</code>. (#2074</a>)</li> Support more locations for examples in OpenAPI definitions and JSON schemas. (#2076</a>)</li> Add link to the git commit for the unstable changelog. (#2078</a>)</li> </ul> Matrix v1.13 release 2024-12-19T19:53:43+00:00 Hey all,</p> Another 9 MSCs have been released today in Matrix 1.13</a>! It’s just over 2 months since Matrix 1.12</a> 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 :)</p> </span> 🔗</a>Account suspension</h2> Last release brought Account Locking</em></a> to the spec, and this release brings Account Suspension</em></a> - 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).</p> Clients should continue calling /sync</code> to detect when a lock/suspension is lifted (or converted to deactivation). MSC3939</a> and MSC3823</a> both have suggestions on what a UI could look like for the different states.</p> 🔗</a>Reporting rooms</h2> Event reporting</a> 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</a>.</p> 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.</p> 🔗</a>Up next in Matrix 1.14 and 2025</h2> 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.</p> As always, if there’s an MSC ready for FCP, let us know in the SCT Office room</a>! We’re currently on an administrative break until January 8th, 2025, but we’re still around and prioritizing features as we see them.</p> 🔗</a>The full changelog</h2> The full changelog for Matrix 1.13 is:</p> 🔗</a>Client-Server API</h3> New Endpoints</strong></p> Add POST /_matrix/client/v3/rooms/{roomId}/report</code>, as per MSC4151</a>. (#1938</a>, #2028</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add error codes to requestToken endpoints, as per MSC4178</a>. (#1944</a>)</li> Remove reply fallbacks, as per MSC2781</a>. (#1994</a>)</li> Clarify the allowed HTTP methods in CORS responses, as per MSC4138</a>. (#1995</a>, #2011</a>)</li> Add new M_USER_SUSPENDED</code> error code behaviour, as per MSC3823</a>. (#2014</a>)</li> </ul> Spec Clarifications</strong></p> The reason</code> parameter in POST /_matrix/client/v3/rooms/{roomId}/report/{eventId}</code> can be omitted instead of left blank, as per MSC2414</a>. (#1938</a>)</li> Correct OpenAPI specification for query parameters to GET /_matrix/client/v3/thirdparty/location/{protocol}</code> endpoint. (#1947</a>)</li> Sort VoIP events semantically. (#1967</a>)</li> Clarify that servers must forward custom keys in PusherData</code> when sending notifications to the push gateway. (#1973</a>)</li> Clarify formats of string types. (#1978</a>, #1979</a>, #1980</a>)</li> Clarify that the async upload endpoint will return 404 in some cases. (#1983</a>)</li> Remove distinction between StateFilter</code> and RoomEventFilter</code>. (#2015</a>)</li> Add hyperlinks throughout the specification. (#2016</a>)</li> Use json</code> instead of json5</code> for syntax highlighting. (#2017</a>)</li> Specify order that one-time keys are issued by /keys/claim</code>, as per MSC4225</a>. (#2029</a>)</li> </ul> 🔗</a>Server-Server API</h3> Backwards Compatible Changes</strong></p> Make ACLs apply to EDUs, as per MSC4163</a>. (#2004</a>)</li> </ul> Spec Clarifications</strong></p> Add 403 error response to /_matrix/federation/v1/state_ids/{roomId}</code>. (#1926</a>)</li> </ul> 🔗</a>Application Service API</h3> Backwards Compatible Changes</strong></p> Allow sending ephemeral data to application services, as per MSC2409</a>. (#2018</a>)</li> </ul> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> Spec Clarifications</strong></p> Document the schema of PusherData</code>. (#1968</a>)</li> The path of HTTP pusher URLs is fixed to /_matrix/push/v1/notify</code>. (#1974</a>)</li> </ul> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> Clarify rule 4.3.1 of the auth rules in room version 11 to state which event's sender</code> the state_key</code> needs to match. (#2024</a>)</li> </ul> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Remove note about reference implementations. (#1966</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Add x-weight</code> property for sorting events rendered with the event-group</code> shortcode. (#1967</a>)</li> Enforce consistent vertical spacing between paragraphs in endpoint definitions. (#1969</a>, #2005</a>)</li> Remove boxes/added-in-paragraph</code> shortcode. (#1970</a>)</li> Remove withVersioning</code> parameter of rver-fragment</code> shortcode. (#1971</a>)</li> Remove span</code> element from added-in</code> and changed-in</code> shortcodes. (#1972</a>)</li> Fix formatting of added-in</code> and changed-in</code> shortcodes by using %</code> delimiter. (#1975</a>)</li> Remove CSS workaround for scroll-anchoring. (#1976</a>)</li> Rename custom-formats.yaml</code> to string-formats.yaml</code> and update its docs. (#1977</a>)</li> Fix relative URLs when serving the specification with a custom baseURL</code>. (#1984</a>, #1997</a>)</li> Rename .htmltest.yaml</code> to .htmltest.yml</code>. (#1985</a>)</li> Improve the JS script to highlight the current ToC entry. (#1991</a>, #2002</a>)</li> Upgrade docsy to 0.11.0 and hugo to 0.139.0. (#1996</a>, #2007</a>)</li> Improve the quality of the rendered diagrams (#1999</a>)</li> Update the Inter font and allow the browser to render the page before it is loaded (#2000</a>)</li> Use a proper Matrix favicon (#2001</a>)</li> Clean up unused CSS classes in openapi/render-operation</code> partial. (#2003</a>)</li> Fix changed-in</code> partial when used with multiple paragraphs. (#2006</a>)</li> Optimize generated CSS by removing unused selectors. (#2008</a>)</li> Remove trailing slash on void HTML elements. (#2009</a>)</li> Remove type</code> and language</code> attributes of script</code> element. (#2021</a>)</li> Change the accessible role of info boxes to note</code>. (#2022</a>)</li> </ul> Matrix v1.12 release 2024-10-07T19:53:43+00:00 Hey all,</p> Welcome to the Matrix 1.12</a>! It’s been just over 3 months since Matrix 1.11</a> 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</a>, and after things wrapped up</a> 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:</p> 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</a>. 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.</p> Read on for a few highlights, and the full changelog at the end of this post.</p> </span> 🔗</a>Account locking</h2> 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</a> 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.</p> When paired with MSC3823</a>-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</a> is pending some implementation checks at the moment, but is expected to land in the next couple of releases.</p> Clients looking to implement locking or suspension will need to look at error codes, and continue calling /sync</code> to determine when the account state changes (either back to active, or deactivated). MSC3939</a> and MSC3823</a> both have suggestions for what the UI might look like for a client as well.</p> 🔗</a>Marking rooms as unread</h2> 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</a> 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.</p> 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</a>, for example.</p> 🔗</a>Up next in Matrix 1.13 and beyond</h2> 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</a>, 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</a>!</p> 🔗</a>The full changelog</h2> The full changelog for Matrix 1.12 is:</p> 🔗</a>Client-Server API</h3> Deprecations</strong></p> Deprecate the server_name</code> query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias}</code> and POST /_matrix/client/v3/knock/{roomIdOrAlias}</code>, as per MSC4156</a>. (#1933</a>)</li> </ul> Removed Endpoints</strong></p> Remove references to device-specific push rules. (#1842</a>)</li> Remove the deprecated name attribute on HTML anchor elements, as per MSC4159</a>. (#1870</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add 403 responses on GET /_matrix/client/v3/profile/{userId}/avatar_url</code> and GET /_matrix/client/v3/profile/{userId}/displayname</code>, as per MSC4170</a>. (#1867</a>)</li> Add support for marking rooms as unread, as per MSC2867</a>. (#1895</a>, #1941</a>)</li> Add via</code> query parameter on POST /_matrix/client/v3/join/{roomIdOrAlias}</code> and POST /_matrix/client/v3/knock/{roomIdOrAlias}</code>, as per MSC4156</a>. (#1933</a>)</li> Add account locking, as per MSC3939</a>. (#1934</a>)</li> Guest accounts can now download/thumbnail media from the new authenticated endpoints, as per MSC4189</a>. (#1959</a>)</li> </ul> Spec Clarifications</strong></p> Rename and sort the modules in the feature profiles table for easier skimming. (#1855</a>)</li> Clarify that room avatars cannot be encrypted. (#1871</a>)</li> Document the acronyms and alternate names for the "Secrets" section. (#1875</a>)</li> Improve recommendation for how to form transaction IDs. (#1888</a>)</li> Clarify that the deprecated dont_notify</code> and coalesce</code> push rule actions MUST be ignored, not rejected. (#1890</a>)</li> Fix various typos throughout the specification. (#1892</a>)</li> Add missing references to m.set_displayname</code>, m.set_avatar_url</code>, and m.3pid_changes</code> in capabilities table. (#1897</a>)</li> Clarify that the fallback login page calls window.matrixLogin.onLogin</code> instead of window.onLogin</code>. (#1899</a>)</li> Remove confusing description of restricted rooms with no valid conditions. (#1903</a>)</li> Clarify that window.matrixLogin.onLogin</code> is called with the response body of POST /_matrix/client/v3/login</code>. (#1905</a>)</li> Document the m.get_login_token</code> capability, as per MSC3882</a>. (#1908</a>)</li> Clarify that the User identifier</code> object in POST /_matrix/client/v3/login</code> contains additional properties that depend on the identification type. (#1909</a>)</li> Don't mention that GET /_matrix/client/v3/profile/{userId}</code> can return additional properties because this is true for almost every endpoint. (#1910</a>)</li> Improve wording of the unauthenticated media deprecation box. Contributed by @HarHarLinks. (#1916</a>)</li> Additional properties in GET /.well-known/matrix/client</code> don't have to be objects. (#1920</a>)</li> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> Specify Content-Type</code> and Content-Disposition</code> usage in the media repo, as per MSC2701</a> and MSC2702</a>. (#1935</a>)</li> Additional keys in GET /_matrix/client/v3/capabilities</code> don't have to be objects. (#1945</a>)</li> </ul> 🔗</a>Server-Server API</h3> Backwards Compatible Changes</strong></p> Add 403 response on GET /_matrix/federation/v1/query/profile</code>, as per MSC4170</a>. (#1867</a>)</li> </ul> Spec Clarifications</strong></p> Remove origin</code> field from PDU example because it doesn't exist in the schema anymore. (#1918</a>)</li> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> Fix required fields in GET /_matrix/key/v2/server</code> response schema. (#1930</a>)</li> Use "server name" instead of "DNS name" to avoid confusion with the "DNS name" component of "server names" as defined in the appendices. (#1946</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> </ul> 🔗</a>Identity Service API</h3> Spec Clarifications</strong></p> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> </ul> 🔗</a>Push Gateway API</h3> Spec Clarifications</strong></p> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> </ul> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> Fix a formatting issue in state resolution v2. (#1896</a>)</li> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> </ul> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> The Matrix.org Foundation no longer requires "real" or "legally identifiable" names in order to contribute to projects. (#1886</a>, #1914</a>)</li> Document the removal</code> changelog category. (#1907</a>)</li> Use dedicated fonts for better support of mathematical symbols. (#1919</a>)</li> Document that the spec uses RFC 2119</a> keywords. Contributed by @HarHarLinks. (#1928</a>)</li> Provide markdown checklists for changelogs under /changelog/$VERSION/checklist.md</code>. (#1937</a>, #1954</a>)</li> Add the deprecated</code> field to properties of OpenAPI definitions and JSON Schemas. (#1940</a>)</li> Use relative permalink to redirect to latest changelog. (#1956</a>)</li> </ul> Matrix v1.11 release 2024-06-20T16:52:27+00:00 Hey all,</p> We’ve just released the milestone Matrix 1.11</a> update for the protocol. It’s been almost exactly 3 months since the last release, Matrix 1.10</a>, keeping us on track for our once-a-quarter release schedule.</p> 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</a>. 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</a>.</p> This post covers MSC3916</a> and its implementation guidelines in more detail, but the full changelog for Matrix 1.11 is available at the end, as always.</p> </span> 🔗</a>MSC3916: Authenticated Media</h2> The Trust & Safety team has been hard at work fixing the design flaw in media mentioned above, taking MSC3916</a> 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.</p> Servers are encouraged to freeze</em> unauthenticated media access (i.e. only allow historical media to be accessed without auth) before</em> 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.</p> 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.</p> 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.</p> 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</a> and #matrix-homeserver-developers:matrix.org</a> to help developers implement this new feature - feel free to visit the respective room for your project and ask questions.</p> Below is some implementation guidance for developers, though is not a replacement for the spec</a>. Where this post and the spec differ, please prefer the spec. :)</p> 🔗</a>Client implementation guidance</h3> Thankfully, supporting authenticated media should be relatively trivial for most clients. When the homeserver declares support for Matrix 1.11 through /versions</a></code>, the client should use the new /_matrix/client/v1/media/*</code> endpoints</a>, noting that they now require authentication. The user’s access token can be supplied using the Authorization</code> header. (Note that using the query string ?access_token</code> method is not recommended, and deprecated</a> in Matrix 1.11 for all endpoints.)</p> If the server doesn’t</em> support Matrix 1.11, the existing /_matrix/media/*</code> endpoints should continue to be used.</p> This may end up looking something like the following in a client:</p> const </span>specVersions = doRequest(</span>'GET'</span>, </span>'/_matrix/client/versions'</span>, accessToken); </span>if </span>(specVersions.versions.includes(</span>"v1.11"</span>)) { </span> </span>return </span>doRequest(</span>'GET'</span>, </span>`/_matrix/client/v1/media/download/${</span>serverName</span>}/${</span>mediaId</span>}`</span>, accessToken); </span>} </span>else </span>{ </span> </span>return </span>doRequest(</span>'GET'</span>, </span>`/_matrix/media/v3/download/${</span>serverName</span>}/${</span>mediaId</span>}`</span>, </span>null</span>); </span>} </span></code></pre> Clients which rely on a web browser may have to use a Service Worker</a> to append the required header, particularly for img</code> tags and similar.</p> Clients should additionally note that, as well as /_matrix/media/v3/download/{serverName}/{mediaId}</a></code>, the following other endpoints have moved to the /_matrix/client/v1/media/*</code> namespace:</p> GET /_matrix/client/v1/media/preview_url</a></code></li> GET /_matrix/client/v1/media/config</a></code></li> GET /_matrix/client/v1/media/thumbnail/{serverName}/{mediaId}</a></code></li> GET /_matrix/client/v1/media/download/{serverName}/{mediaId}/{fileName}</a></code></li> </ul> The media /upload</a></code>, /upload/{serverName}/{mediaId}</a></code>, and /create</a></code> endpoints have not yet moved; they are expected to make the switch in a future spec version.</p> 🔗</a>Server implementation guidance</h3> As mentioned above, servers are a bit more tricky. The Client-Server API endpoints are relatively straightforward: they are the exact same as the previous endpoints, just with authentication added and at a new path. The Federation API endpoints are a bit more challenging. Most server projects have already started implementation, but for those which haven’t (or need a bit of guidance), there’s some information here</a>.</p> Server authors are also encouraged to review the client guidance above to gain a better understanding of what their connected clients will be looking for and doing.</p> 🔗</a>Up next in Matrix 1.12 and beyond</h2> Over the next 2-3 months, we’ll be focusing on the following MSCs:</p> Early review of Matrix 2.0 features as they become ready. Sliding sync - MSC3575</a>, or its Simplified variation, and applicable extensions.</li> Group VoIP - Exact MSCs to be determined, as they may change following implementation.</li> OIDC Authentication - primarily MSC3861</a>.</li> Encryption stability - primarily MSC4153</a>.</li> </ul> </li> Pre-implementation review of Trust & Safety MSCs as required. Exact MSCs to be determined. Likely to include some “reporting v2” work.</li> </ul> </li> Extensible Events and Custom Emoji/Stickers unblocking as required and able.</li> </ul> Additionally, we’ll be continuing to define the expectations of a Spec Core Team member, particularly as it relates to the Governing Board of 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.</p> 🔗</a>The full changelog</h2> Read on for full details of what’s in Matrix 1.11:</p> 🔗</a>Client-Server API</h3> Deprecations</strong></p> Authentication using a query string is now deprecated, as per MSC4126</a>. The Authorization</code> header should be used instead. (#1808</a>)</li> Use of the /_matrix/media/*</code> endpoints is now deprecated. New, authenticated, endpoints are available instead. (#1858</a>)</li> </ul> New Endpoints</strong></p> GET /_matrix/client/v1/media/config</code></a> (#1858</a>)</li> GET /_matrix/client/v1/media/download/{serverName}/{mediaId}</code></a> (#1858</a>)</li> GET /_matrix/client/v1/media/download/{serverName}/{mediaId}/{fileName}</code></a> (#1858</a>)</li> GET /_matrix/client/v1/media/preview_url</code></a> (#1858</a>)</li> GET /_matrix/client/v1/media/thumbnail/{serverName}/{mediaId}</code></a> (#1858</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add support for muting in VoIP calls, as per MSC3291</a>. (#1755</a>)</li> Add optional animated</code> query string option to GET /thumbnail</code>, as per MSC2705</a>. (#1757</a>)</li> Specify terms of services at registration, as per MSC1692</a>. (#1812</a>)</li> Add support for mathematical messages, as per MSC2191</a>. (#1816</a>)</li> Do not require UIA when first uploading cross-signing keys, as per MSC3967</a>. (#1828</a>)</li> Add the new unsigned.membership</code> property to events, as per MSC4115</a>. (#1847</a>)</li> Media downloads and thumbnails are now authenticated, as per MSC3916</a>. (#1858</a>)</li> Some media endpoints are now consistently under /_matrix/client/{version}/media/*</code> instead of /_matrix/media/*</code>, as per MSC3916</a>. (#1858</a>)</li> </ul> Spec Clarifications</strong></p> Add /logout</code> and clarify the endpoints which do not take a JSON request body. (#1644</a>)</li> Clarify that the type</code> of the POST /login</code> request must be one of the types returned by the GET /login</code> response. (#1776</a>)</li> Link to existing grammar where possible in types. (#1813</a>)</li> Rename "recovery key" to "backup decryption key". (#1819</a>)</li> Clarify that the device's Ed25519 signing key should be used in QR code verification (as opposed to the device's Curve25519 identity key). (#1829</a>)</li> Fix various typos throughout the specification. (#1832</a>, #1841</a>, #1852</a>, #1853</a>)</li> Specify the encoding to be used when generating QR codes for device verification. (#1839</a>)</li> Clarify that an access token is optional on the POST /account/password</code> and POST /account/deactivate</code> endpoints. (#1843</a>)</li> Use RFC 2119 keywords more consistently. (#1846</a>, #1861</a>)</li> Move size limits for user, room and event IDs into the appendix and clarify that the length is to be measured in bytes. (#1850</a>)</li> Clarify that relations recursion should be capped at a certain depth. (#1854</a>)</li> Add missing secrets, third-party invites and room tagging modules to feature profiles table. (#1860</a>)</li> Clarify when server name is used and link to the definition. (#1862</a>)</li> Clarify where keys reside when checking an m.room.encrypted</code> event. (#1863</a>)</li> Clarify that /media/v3/upload/{serverName}/{mediaId}</code> requires authentication. (#1872</a>)</li> </ul> 🔗</a>Server-Server API</h3> Deprecations</strong></p> Use of the Client-Server API /_matrix/media/*</code> endpoints is now deprecated. New, authenticated, endpoints are available instead. (#1858</a>)</li> </ul> New Endpoints</strong></p> GET /_matrix/federation/v1/media/download/{mediaId}</code></a> (#1858</a>)</li> GET /_matrix/federation/v1/media/thumbnail/{mediaId}</code></a> (#1858</a>)</li> </ul> Backwards Compatible Changes</strong></p> Media downloads and thumbnails are now authenticated, as per MSC3916</a>. (#1858</a>, #1869</a>)</li> </ul> Spec Clarifications</strong></p> Link to existing grammar where possible in types. (#1813</a>)</li> Clarify that whitespace around commas is allowed in the X-Matrix</code> Authorization</code> header value params list. (#1818</a>)</li> Clarify that the event</code> field of the /v2/send_join</code> response is only required when the event is signed by the resident server. (#1834</a>, #1840</a>)</li> Replace references to RFC 7235 and RFC 7230 that are obsoleted by RFC 9110. (#1844</a>)</li> Fix various typos throughout the specification. (#1877</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Clarify that appservices should be notified of events relating to the sender_localpart</code> user. (#1810</a>)</li> </ul> 🔗</a>Identity Service API</h3> Deprecations</strong></p> Authentication using a query string is now deprecated, as per MSC4126</a>. The Authorization</code> header should be used instead. (#1808</a>)</li> </ul> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> Clarify that redaction events are still subject to all applicable auth rules. (#1824</a>)</li> Fix various typos throughout the specification. (#1827</a>, #1848</a>)</li> Fix the rendering of the event format for room versions 1 and 2. (#1883</a>)</li> Generate the Table of Contents with Hugo rather than JavaScript. (#1884</a>)</li> </ul> 🔗</a>Appendices</h3> Deprecations</strong></p> Deprecate linking to events in rooms identified by alias, as per MSC4132</a>. (#1823</a>)</li> </ul> Spec Clarifications</strong></p> Define 'Opaque Identifier Grammar'. (#1791</a>)</li> Define common cryptographic key representation. (#1819</a>)</li> Move size limits for user, room and event IDs into the appendix and clarify that the length is to be measured in bytes. (#1850</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Update the spec release process and related documentation. (#1759</a>)</li> Fix npm release script for @matrix-org/spec</code>. (#1765</a>)</li> Formatting fixes in CONTRIBUTING.rst</code>. (#1769</a>)</li> Improve rendering on mobile devices. (#1770</a>, #1771</a>)</li> Fix the OpenAPI definition of the security schemes. (#1772</a>)</li> Simplify uses of resolve-refs</code> partial. (#1773</a>)</li> Fix Hugo warnings. (#1775</a>, #1788</a>)</li> Fix github-labels.rst</code>. (#1781</a>)</li> Update dependencies. (#1786</a>, #1803</a>, #1804</a>)</li> Solve allOf</code> recursively in OpenAPI and JSON Schemas. (#1787</a>)</li> Fix property type resolution in render-object-table</code> partial. (#1789</a>)</li> Factor out common definition of Tag</code> type. (#1793</a>)</li> Update the version of Hugo used to render the spec to v0.124.1. (#1794</a>)</li> Add support for pattern formats for patternProperties</code>. (#1796</a>)</li> Clean up unnecessary allOf</code>s in OpenAPI definitions. (#1797</a>)</li> Show information about "Additional Properties" in object tables. (#1798</a>)</li> Fix anchors for schemas under oneOf</code>. (#1799</a>)</li> Use reference to OneTimeKeys</code> schema in OpenAPI definitions. (#1800</a>)</li> Do not use the title</code> of objects containing only additionalProperties</code> or patternProperties</code>. (#1801</a>)</li> Add anchors in definition</code> shortcode. (#1802</a>)</li> Set python version for the Towncrier CI job. (#1805</a>)</li> Replace set-output</code> with environment files in CI. (#1806</a>)</li> Render response headers. (#1809</a>)</li> Use patternProperties</code> in more places with supported formats. (#1813</a>)</li> Add support for rendering string formats. (#1814</a>)</li> Refactor the OpenAPI definitions of the content repository endpoints. (#1822</a>)</li> Clean up pull request template. (#1831</a>)</li> Do not add empty arrays to examples. (#1849</a>)</li> Generate the Table of Contents with Hugo rather than JavaScript. (#1851</a>, #1885</a>)</li> Fix syntax errors in the spec release issue template. (#1856</a>)</li> Use environment variables for Netlify build job. (#1865</a>)</li> Render added/changed in info on request and response content types. (#1876</a>)</li> Fix validation errors in generated HTML. (#1880</a>)</li> Ensure most generated HTML IDs are unique. (#1881</a>)</li> Allow to specify a prefix for generated HTML IDs of API endpoints. (#1882</a>)</li> </ul> Matrix v1.10 release 2024-03-22T16:52:27+00:00 Hey all,</p> Matrix 1.10</a> 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</a>) brought in some protocol maintenance for us though, and the implementation teams have been hard at work building the Matrix 2.0 stack</a> concurrent to the Matrix 1.10 work released today.</p> 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.</p> 🔗</a>MSC3077: Multi-stream VoIP</h2> MSC3077</a> and its related proposal MSC3291</a> (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</a> and MSC3401</a>, though Element’s VoIP team is considering a possible third alternative which runs MSC3401</a> 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.</p> As always, early review is appreciated though please note that MSC3898</a> and MSC3401</a> are particularly in flux at the moment.</p> 🔗</a>Up next in Matrix 1.11 and beyond</h2> Over the next 2-3 months, we’ll be focusing on the following MSCs:</p> Trust & Safety improvements (at the protocol level). MSC3823</a> - Account suspension</li> MSC3939</a> - Account locking</li> MSC3916</a> - Authentication for media (time permitting)</li> MSC4117</a> - Reversible redactions (pre-implementation review)</li> 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.</li> </ul> </li> Early review of Matrix 2.0 features as they become ready. Sliding sync (MSC3575</a>) + applicable extensions.</li> Group VoIP - Exact MSCs to be determined, as they may change following implementation.</li> OIDC Authentication - Exact MSCs to be determined.</li> </ul> </li> Pre-implementation review of Extensible Events</a> core content blocks MSCs. Many of these MSCs require updates before they are ready for formal review.</li> MSC3954</a> - Emotes</li> MSC3955</a> - Notices / automated events</li> MSC3927</a> - Audio</li> MSC3551</a> - Files</li> MSC3552</a> - Images and Stickers</li> MSC3553</a> - Videos</li> </ul> </li> </ul> 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.</p> 🔗</a>The full changelog</h2> Read on for full details of what’s in Matrix 1.10:</p> 🔗</a>Client-Server API</h3> Backwards Compatible Changes</strong></p> Allow /versions</code> to optionally accept authentication, as per MSC4026</a>. (#1728</a>)</li> Add local erasure requests, as per MSC4025</a>. (#1730</a>)</li> Use the body</code> field as optional media caption, as per MSC2530</a>. (#1731</a>)</li> Add server support discovery endpoint, as per MSC1929</a>. (#1733</a>)</li> Add support for multi-stream VoIP, as per MSC3077</a>. (#1735</a>)</li> Specify that the Retry-After</code> header may be used to rate-limit a client, as per MSC4041</a>. (#1737</a>)</li> Add support for recursion on the GET /relations</code> endpoints, as per MSC3981</a>. (#1746</a>)</li> </ul> Spec Clarifications</strong></p> The strike</a> element is deprecated in the HTML spec. Clients should prefer s</a> instead. (#1629</a>)</li> Clarify that read receipts should be batched by thread as well as by room. (#1685</a>)</li> Clarify that threads can be created based on replies. (#1687</a>)</li> Clarify in the reply fallbacks example that the prefix sequence should be repeated for each line. (#1690</a>)</li> Clarify the format of account data objects for secret storage. (#1695</a>, #1734</a>)</li> Clarify that the key backup MAC is implemented incorrectly and does not pass the ciphertext through HMAC-SHA-256. (#1712</a>)</li> Clarify one-time key and fallback key types in examples. (#1715</a>)</li> Clarify that the HKDF calculation for SAS uses base64-encoded keys rather than the raw key bytes. (#1719</a>)</li> Clarify how to perform the ECDH exchange in step 12 of the SAS process. (#1720</a>)</li> Document the deprecation policy of HTML tags, as per MSC4077</a>. (#1732</a>)</li> The font</a> element is deprecated in the HTML spec. Clients should prefer span</a> with the data-mx-bg-color</code> and data-mx-color</code> attributes instead. (#1739</a>)</li> Disambiguate uses of PublicRoomsChunk</code> in the GET /hierarchy</code> endpoint. (#1740</a>)</li> Clarify that sdpMid</code> and sdpMLineIndex</code> are not required in m.call.candidates</code>. (#1742</a>)</li> Fix various typos throughout the specification. (#1748</a>)</li> Clearly indicate that each Content-Type</code> may have distinct behaviour on non-JSON requests/responses. (#1756</a>)</li> Clarify that the m.push_rules</code> account data type cannot be set using the /account_data</code> API, as per MSC4010</a>. (#1763</a>)</li> </ul> 🔗</a>Server-Server API</h3> Spec Clarifications</strong></p> Clarify Server-Server API request signing example by using the POST</code> HTTP method, as GET</code> requests don't have request bodies. (#1721</a>)</li> Disambiguate uses of PublicRoomsChunk</code> in the GET /hierarchy</code> endpoint. (#1740</a>)</li> Clarify that the children_state</code>, room_type</code> and allowed_room_ids</code> properties in the items of the children</code> array of the response of the GET /hierarchy</code> endpoint are not required. (#1741</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Clarify that the /login</code> and /register</code> endpoints should fail when using the m.login.application_service</code> login type without a valid as_token</code>. (#1744</a>)</li> </ul> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> For room versions 7 through 11: Clarify that invite->knock</code> is not a legal transition. (#1717</a>)</li> </ul> 🔗</a>Appendices</h3> No significant changes.</p> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Update the spec release process. (#1680</a>)</li> Minor clarifications to the contributing guide. (#1697</a>)</li> Update Docsy to v0.8.0. (#1699</a>, #1762</a>)</li> Fix npm release script for @matrix-org/spec</code>. (#1713</a>)</li> Add some clarifications around implementation requirements for MSCs. (#1718</a>)</li> Update HTML templates to include links to object schema definitions. (#1724</a>)</li> Factor out all the common parameters of the various /relations</code> apis. (#1745</a>)</li> Add support for $ref</code> URIs containing fragments in OpenAPI definitions and JSON schemas. (#1751</a>, #1754</a>)</li> </ul> Matrix v1.9 release 2023-11-29T17:44:27+00:00 Hey all,</p> We’ve just pushed out Matrix 1.9</a>! Our last release was Matrix 1.8</a> and brought us a whole new room version. Matrix 1.9 continues a theme of an annual maintenance release</a>, bringing with it mostly clarifications and bug fixes.</p> 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.</p> 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 :)</p> 🔗</a>Messaging interoperability</h2> 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.</p> 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</a>. The proposed protocol for MIMI is based upon the Linearized Matrix work, but is primarily designed for an MLS-centric environment.</p> 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</a>.</p> 🔗</a>Custom emoji/stickers</h2> We mentioned in Matrix 1.8’s release that we’d be taking a look at MSC2545</a>, MSC1951</a>, MSC4027</a>, and MSC3892</a> - 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</a>/MSC3911</a> where media is linked to a specific event.</p> 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</a>. 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.</p> 🔗</a>Upcoming in Matrix 1.10</h2> 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:</p> Authenticated media MSC3916</a> - Authentication for media</li> MSC3911</a> - Linking media to events</li> </ul> </li> Custom emoji/stickers MSC2545</a> - Image packs</li> MSC1951</a> - Different style of image packs</li> MSC4027</a> - Images in reactions</li> MSC3892</a> - Encrypted emotes</li> </ul> </li> MSC4074</a> - Server-side annotation aggregation</li> MSC4048</a> - Authenticated key backup</li> Extensible Events MSC3954</a> - Text emotes</li> MSC3955</a> - Replacement for notice messages</li> MSC3551</a> - Files</li> MSC3552</a> - Images and Stickers</li> MSC3553</a> - Videos</li> MSC3927</a> - Audio</li> </ul> </li> Encrypted Appservices MSC2409</a> - Sending EDUs to appservices</li> MSC3202</a> - Encrypted appservices</li> </ul> </li> MSC2702</a> - Content-Disposition semantics for media</li> MSC3939</a> - Account locking</li> </ul> This list is not</strong> 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</a> 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).</p> 🔗</a>The full changelog</h2> Matrix 1.9 is a relatively light maintenance release, but it still has a changelog! Read on for full details.</p> 🔗</a>Client-Server API</h3> Backwards Compatible Changes</strong></p> Add the m.rule.suppress_edits</code> default push rule, as per MSC3958</a>. (#1617</a>)</li> </ul> Spec Clarifications</strong></p> Fix m.call.negotiate</code> schema and example. (#1546</a>)</li> Clarify that the via</code> property is required for m.space.parent</code> and m.space.child</code> as per MSC1772</a>. Contributed by @PaarthShah. (#1618</a>)</li> Add a note to the /publicRooms</code> API that the server name is case sensitive. (#1638</a>)</li> Clarify that an m.room.name</code> event with an absent name</code> field is not expected behavior. (#1639</a>)</li> Fix schemas used for account data and presence events in GET /initialSync</code>. (#1647</a>)</li> Fix various typos throughout the specification. (#1658</a>, #1661</a>, #1665</a>)</li> Fix .m.rule.suppress_notices</code> push rule not being valid JSON. (#1671</a>)</li> Add missing properties for event_property_is</code> and event_property_contains</code> push conditions to PushConditions</code> object. (#1673</a>)</li> Indicate that fallback keys should have a fallback</code> property set to true</code>. (#1676</a>)</li> Clarify that thread roots are not considered within the thread. (#1677</a>)</li> </ul> 🔗</a>Server-Server API</h3> Spec Clarifications</strong></p> Fix schema of m.receipt</code> EDU. (#1636</a>)</li> Fix various typos throughout the specification. (#1661</a>)</li> Clarify that federation requests for non-local users are invalid. (#1672</a>)</li> </ul> 🔗</a>Application Service API</h3> No significant changes.</p> 🔗</a>Identity Service API</h3> No significant changes.</p> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> No significant changes.</p> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Clarify timestamp specification with respect to leap seconds. (#1627</a>)</li> Fix various typos throughout the specification. (#1652</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Add more CI checks for OpenAPI definitions and JSON Schemas. (#1656</a>)</li> Generate server-server OpenAPI definition. (#1657</a>)</li> </ul> Spec Clarifications</strong></p> Replace all mentions of Swagger by OpenAPI. (#1633</a>)</li> Fix enum types in JSON schemas. (#1634</a>)</li> Fix schema of m.mentions</code> object. (#1635</a>)</li> Fix rendering of m.receipt</code> event in Client-Server API. (#1637</a>)</li> Remove required fieldname</code> in appservice Protocol definition. (#1646</a>)</li> Fix github action workflow responsible for releasing of @matrix-org/spec package. (#1648</a>)</li> Upgrade GitHub actions. (#1660</a>)</li> </ul> Matrix v1.8 release 2023-08-23T16:25:37+00:00 Hey all,</p> Matrix 1.8</a> is out now! The last release, Matrix 1.7</a>, 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</a>-related MSCs from that original plan, but made an effort to get the other stuff looked at as well.</p> 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 :)</p> 🔗</a>Room version 11</h2> Matrix 1.8 features a new room version</a>! 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.</p> Specified originally as MSC3820</a>, v11 introduces the following changes:</p> MSC2174</a> - Move redacts</code> to the content</code> of m.room.redaction</code> events.</li> MSC2175</a> - Remove creator</code> from m.room.create</code> events (use sender</code> instead).</li> MSC3989</a> - Remove origin</code> from events.</li> MSC2176</a>, MSC3821</a> - General updates to redaction algorithm.</li> </ul> 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</a> and MSC3995</a>).</p> In future room versions the cleanup effort will continue, alongside additional features for supporting the IETF use cases. Watch this space for updates.</p> 🔗</a>Upcoming in Matrix 1.9</h2> We’re continuing the trend of planning ahead and have the following themes planned for work in Matrix 1.9:</p> Anything required by the MIMI/IETF efforts we’re undertaking. This currently includes: Extensible Events</li> Role-Based Access Control (RBAC; new MSC expected)</li> Next generation of Linearized Matrix (already)</li> MSC4044</a> and MSC4045</a></li> Binary-encoded events (maybe, but probable)</li> Canonical DMs (maybe)</li> Sending events as rooms/servers instead of just users (maybe)</li> Further room version cleanup as needed</li> </ul> </li> Merging MSC3939</a>.</li> Accepting a combination of MSC2545</a>, MSC1951</a>, MSC3892</a>, and MSC4027</a>. This may involve creating a new MSC to cover the functionality of each, plus the needful for IETF and Extensible Events efforts.</li> Merging MSC3391</a> (time permitting).</li> </ul> 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 :)</p> 🔗</a>The full changelog</h2> 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.</p> 🔗</a>Client-Server API</h3> Backwards Compatible Changes</strong></p> Require callers to be joined to the room to report its events, as per MSC2249</a>. (#1517</a>)</li> </ul> Spec Clarifications</strong></p> Fix missing type</code> property in the JSON schema definition of the m.reaction</code> event. Contributed by @chebureki. (#1552</a>)</li> Make sure examples types match schema in definitions. (#1563</a>)</li> Allow null</code> in room_types</code> in POST /publicRooms</code> endpoints schemas. (#1564</a>)</li> Fix broken header formatting. Contributed by @midnightveil. (#1578</a>)</li> Render binary request and response bodies. (#1579</a>)</li> Fix description of MAC calculation in SAS verification. (#1590</a>)</li> Update link to SAS emoji definition data. (#1593</a>)</li> Fix various typos throughout the specification. (#1597</a>)</li> </ul> 🔗</a>Server-Server API</h3> Deprecations</strong></p> Deprecate matrix</code> SRV lookup steps during server discovery, as per MSC4040</a>. (#1624</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add matrix-fed</code> SRV lookup steps to server discovery, as per MSC4040</a>. (#1624</a>)</li> </ul> Spec Clarifications</strong></p> Document why /state_ids</code> can respond with a 404. (#1521</a>)</li> Fix response definition for POST /_matrix/federation/v1/user/keys/claim</code>. (#1559</a>)</li> Fix examples in server keys definition. (#1560</a>)</li> Make sure examples types match schema in definitions. (#1563</a>)</li> Allow null</code> in room_types</code> in POST /publicRooms</code> endpoints schemas. (#1564</a>)</li> Fix broken header formatting. Contributed by @midnightveil. (#1578</a>)</li> Remove spurious mention of a "default port" with respect to SRV record lookup. (#1615</a>)</li> Switch to ordered list for server name resolution steps. (#1623</a>)</li> </ul> 🔗</a>Application Service API</h3> Spec Clarifications</strong></p> Fix type of custom fields</code> in thirdparty lookup queries. (#1584</a>)</li> </ul> 🔗</a>Identity Service API</h3> Spec Clarifications</strong></p> Make sure examples types match schema in definitions. (#1563</a>)</li> </ul> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Backwards Compatible Changes</strong></p> Add room version 11 as per MSC3820</a>. (#1604</a>)</li> Move redacts</code> from top level to content</code> on m.room.redaction</code> events in room version 11, as per MSC2174</a>. (#1604</a>)</li> Remove creator</code> from m.room.creator</code> events in room version 11, as per MSC2175</a>. (#1604</a>)</li> Remove remaining usage of origin</code> from events in room version 11, as per MSC3989</a>. (#1604</a>)</li> Update the redaction rules in room version 11, as per MSC2176</a> and MSC3821</a>. (#1604</a>)</li> </ul> 🔗</a>Appendices</h3> Backwards Compatible Changes</strong></p> Allow +</code> in Matrix IDs, as per MSC4009</a>. (#1583</a>)</li> </ul> Spec Clarifications</strong></p> Clarify spec re canonical JSON to handle negative-zero; also, give an example of negative-zero and a large power of ten. (#1573</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Upgrade Swagger data to OpenAPI 3.1. (#1310</a>)</li> Create @matrix-org/spec</code> npm package to ship the SAS Emoji data definitions & translations. (#1620</a>)</li> </ul> Spec Clarifications</strong></p> Update the CI to validate the file extension of changelog entries. (#1542</a>)</li> Disclosure sections now only display their title when collapsed. (#1549</a>)</li> Fix the sidebar in recent versions of Hugo. (#1551</a>)</li> Bump jsonschema to validate JSON Schemas against Draft 2020-12. (#1556</a>)</li> Use Redocly CLI to validate OpenAPI definitions. (#1558</a>)</li> Use tag name as the OpenAPI definition version. (#1561</a>)</li> Make sure version in x-changedInMatrixVersion</code> is a string. (#1562</a>)</li> Clarify usage of ABNF for grammar in the documentation style guide. (#1582</a>)</li> Remove unnecessary oneOf</code>s in JSON schemas. (#1585</a>)</li> Update the version of Hugo used to render the spec to v0.113.0. (#1591</a>)</li> Fix rendered changelog with new version of towncrier. (#1598</a>)</li> Improve the layout of tables on desktop displays. Contributed by Martin Fischer. (#1601</a>)</li> </ul> Matrix v1.7 release 2023-05-25T18:56:10+00:00 Hey all,</p> Matrix 1.7</a> has just been released! The last spec release was about 3 months ago</a>, 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).</p> 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.</p> 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 👀</p> </span> 🔗</a>🖼️ Finally, improvements to media in Matrix</h2> The media repo has been largely unchanged since it was first released in 2015 as r0.0.0</a> - the only change being the addition of URL previews in r0.3.0</a> (released in 2017). Thankfully, the folks over at Beeper</a> have been busy changing this situation!</p> MSC3860</a> and MSC2246</a> 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</a> as allow_redirect</code>, 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.</p> Meanwhile, MSC2246 (largely specified here</a>) 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!</p> 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</a>, MSC4016: Streaming E2EE file transfers</a>, and MSC3870: Upload direct to URL</a> are all fairly promising MSCs we’re planning to take a look at in the next year or so.</p> 🔗</a>💖 Reactions are here</h2> 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</a> is merged</a>.</p> MSC2677 was the last part of the MSC1849</a> saga, with MSC2674</a> (relationships) and MSC2675</a> (server-side aggregation) landing in Matrix 1.3, and MSC2676</a> (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.</p> 🔗</a>🎉 Achievement: First MSC merged</h2> 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!</p> In no particular order:</p> benkuly</a> with MSC3925</a> (their first ever MSC!).</li> Fizzadar</a> with MSC3758</a> and MSC3860</a>.</li> hughns</a> with MSC3970</a> and MSC3882</a>.</li> Johennes</a> with MSC3873</a>.</li> </ul> Anyone can contribute MSCs, improving the whole of Matrix for everyone. If you have an idea (or bugfix), check out the guidelines</a> and let us know if you run into any questions in #matrix-spec:matrix.org</a> on Matrix - we’re always happy to help.</p> 🔗</a>🔜 Early considerations for Matrix 1.8</h2> 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.</p> 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</a> on Matrix, starting with the ideas we raised ourselves earlier in the year.</p> As of writing, our current plan for Matrix 1.8 includes:</p> Further work on adopting OIDC (namely progress on MSC3824</a>, MSC2965</a>, and other similar proposals).</li> Pushing the MSC3995</a> suite of MSCs towards acceptance/merge status.</li> Continuing the improvements of VoIP (MatrixRTC) as we work towards Matrix 2.0</a>.</li> Various improvements to event relationships, such as MSC3981</a>, and push in general, such as MSC3958</a> and MSC3391</a>.</li> </ul> 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</a> (even if those MSCs aren’t on-theme with the above - we still want to hear about them!).</p> 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</a>.</p> 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</a>.</p> 🔗</a>The full changelog</h2> 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</a>, zecakeh</a>, and Cadair</a> for contributing clarification & bug fix PRs in this release - we greatly appreciate it!</p> 🔗</a>Client-Server API</h3> New Endpoints</strong></p> POST /_matrix/media/v1/create</code></a> (#1499</a>)</li> PUT /_matrix/media/v3/upload/{serverName}/{mediaId}</code></a> (#1499</a>)</li> POST /_matrix/client/v1/login/get_token</code></a> (#1530</a>)</li> </ul> Backwards Compatible Changes</strong></p> Changes to the server-side aggregation of m.replace</code> (edit) events, as per MSC3925</a>. (#1440</a>, #1525</a>)</li> Add new push rule conditions event_property_is</code> and event_property_contains</code>, as per MSC3758</a> and MSC3966</a>. (#1464</a>)</li> Add m.annotation</code> relations (reactions), as per MSC2677</a>. (#1475</a>, #1531</a>)</li> Support asynchronous media uploads, as per MSC2246</a>. (#1499</a>, #1510</a>)</li> Document the m.mentions</code> property; the .m.rule.is_user_mention</code> and .m.rule.is_room_mention</code> push rules; and other notification behaviour, as per MSC3952</a>. (#1508</a>)</li> Improve VoIP signaling, as per MSC2746</a>. (#1511</a>, #1540</a>)</li> Update the scope of transaction IDs, as per MSC3970</a>. (#1526</a>)</li> Add an ability to redirect media downloads, as per MSC3860</a>. (#1529</a>)</li> Add an ability to use an existing session to log in another, as per MSC3882</a>. (#1530</a>)</li> </ul> Spec Clarifications</strong></p> Clarify the sections of the specification concerning aggregation of child events. (#1424</a>)</li> Fix various typos throughout the specification. (#1432</a>, #1442</a>, #1447</a>, #1455</a>, #1465</a>, #1500</a>, #1509</a>)</li> Clarify that reply chain fallback for threads might not be present. (#1439</a>)</li> Clarify what event property the content-specific push rules match against. (#1441</a>)</li> Clarify the semantics that make requests idempotent. (#1449</a>)</li> Improve documentation of how clients use push rules. (#1461</a>)</li> Clarify that servers should enforce a default limit</code> on a filter if one is not specified. (#1463</a>)</li> Disambiguate using property names with dots in them during push rule processing, as per MSC3873</a> and MSC3980</a>. (#1464</a>)</li> Fix phrasing & typography in the registration endpoint description. Contributed by @HarHarLinks. (#1474</a>)</li> Remove outdated text saying that state_default</code> is 0 if there is no m.room.power_levels</code> event in a room. (#1479</a>)</li> Remove fictitious token</code> parameter on /keys/query</code> endpoint. (#1485</a>)</li> Fix rendering of properties with a list of types. (#1487</a>)</li> Clarify parts of the cross-signing signature upload request. (#1495</a>)</li> Remove the dont_notify</code> and coalesce</code> push rule actions, as per MSC3987</a>. (#1501</a>)</li> Clarify m.location</code> scheme by partially reverting f1f32d3</a>. Contributed by @HarHarLinks. (#1507</a>)</li> Add missing knock_restricted</code> join rule to the m.room.join_rules</code> schema. (#1535</a>)</li> </ul> 🔗</a>Server-Server API</h3> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#1431</a>, #1447</a>, #1466</a>, #1518</a>)</li> Fix PDU examples by removing invalid OpenAPI reference to examples/minimal_pdu.json</code>. (#1454</a>)</li> Remove leftover {key_id}</code> from /_matrix/key/v2/server/</code>. (#1473</a>)</li> Remove extraneous age_ts</code> field from the reference hash calculation section. (#1536</a>)</li> </ul> 🔗</a>Application Service API</h3> New Endpoints</strong></p> POST /_matrix/app/v1/ping</code></a> (#1516</a>)</li> POST /_matrix/client/v1/appservice/{appserviceId}/ping</code></a> (#1516</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add homeserver->appservice ping mechanism, as per MSC2659</a>. Contributed by @tulir at @beeper. (#1516</a>, #1541</a>)</li> </ul> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#1447</a>)</li> </ul> 🔗</a>Identity Service API</h3> Spec Clarifications</strong></p> Corrections to the response format of /_matrix/identity/v2/store-invite</code>. (#1486</a>)</li> </ul> 🔗</a>Push Gateway API</h3> No significant changes.</p> 🔗</a>Room Versions</h3> Spec Clarifications</strong></p> Clarifications of event ID formats in early room versions (#1484</a>)</li> </ul> 🔗</a>Appendices</h3> Spec Clarifications</strong></p> Clarify that the term "Canonical JSON" is a specific thing within the Matrix specification. (#1468</a>)</li> Remove references to groups. (#1483</a>)</li> Clarifications of event ID formats in early room versions. (#1484</a>)</li> </ul> 🔗</a>Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Update references to Inter font. (#1444</a>)</li> Endpoint disclosures now hide everything but the URL. (#1446</a>)</li> Wrap $ref in allOf where other attributes are present, to improve OpenAPI compliance. (#1457</a>)</li> Minor cleanups to the GitHub Actions workflows (#1476</a>)</li> Fix generation of anchors for additional properties. (#1488</a>)</li> Fix various typos throughout the specification. (#1534</a>)</li> Document more of the spec release timeline/process. (#1538</a>)</li> </ul> Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0 2023-03-28T00:00:00+00:00 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</a> / GHSA-mwq8-fjpf-c2gr</a> for matrix-js-sdk and CVE-2023-28103</a> / GHSA-6g43-88cp-w5gv</a> for matrix-react-sdk).</p> 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.</p> 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.</p> 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.</p> We found these issues during a codebase audit that we had previously announced</a> 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</a> / GHSA-rfv9-x7hh-xc32</a> and CVE-2022-36060</a> / GHSA-2x9c-qwgf-94xr</a>, 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.</p> Synapse 1.78 released 2023-02-28T00:00:00+00:00 Greetings Matrix fans! We've published Synapse version 1.78</a> 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</a> for any important information about upgrading.</p> </span> 🔗</a>Announcements</h2> Please note that Synapse 1.78.0 replaces the /_synapse/admin/v1/media/<server_name>/delete</code> admin API with an identical endpoint at /_synapse/admin/v1/media/delete</code>. Please update your tooling to use the new endpoint. The deprecated version will be removed in a future release.</p> 🔗</a>The new stuff</h2> 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</a>). Synapse 1.78.0 updates this command adding account data to the user information that is returned by the export data command.</p> This version of Synapse also features a few changes to push rules, with implementations for MSC3758</a>: Add event_property_is push</code> rule condition kind, MSC3966</a>: event_property_contains</code> push rule condition, and the removal of the spurious dont_notify</code> action from the defaults for the .m.rule.reaction</code> 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</a>: Intentional Mentions, which aims to eliminate unintentional mentions and improve the experience of mentions in general.</p> 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</a>, and a fix for a bug introduced in Synapse 1.75 where the portdb script</a> 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.</p> Finally, for those deployments using workers, v1.78.0 fixed a bug introduced in Synapse 1.76 where 5s delays would occasionally occur.</p> 🔗</a>Everything else</h2> See the full changelog</a> for a complete list of changes in the release. Also please have a look at the upgrade notes</a>.</p> 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.</p> We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p> Synapse 1.77 released 2023-02-16T00:00:00+00:00 Greetings Matrix fans! We've published Synapse version 1.77</a> as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience.</p> </span> 🔗</a>The new stuff</h2> 🔗</a>Experimental support for intentional mentions (MSC3952)</h3> 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.</p> MSC3952</a> 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.</p> Synapse now implements this as an experimental feature.</p> 🔗</a>Experimental support to suppress notifications from message edits (MSC3958)</h3> 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</code>) will retrigger a noisy notification. That can be pretty annoying when the message is edited 10 times!</p> MSC3958</a> is here to solve that, and Synapse now implements it as an experimental feature.</p> 🔗</a>The quest for speed continues!</h3> Some iterative optimizations have been implemented that should make joining or leaving</a> large rooms even faster, and should also improve sending message</a>.</p> 🔗</a>Everything else</h2> See the full changelog</a>, for a complete list of changes in the release.</p> 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.</p> We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p>