Matrix.org - Spec

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>

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>

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>

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>
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>
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> 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> Application Service API</h3> No significant changes.</p> Identity Service API</h3> No significant changes.</p> Push Gateway API</h3> No significant changes.</p> Room Versions</h3> No significant changes.</p> 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> 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> 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> 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> 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> 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> 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> Application Service API</h3> Spec Clarifications</strong></p> Fix type of custom fields</code> in thirdparty lookup queries. (#1584</a>)</li> </ul> Identity Service API</h3> Spec Clarifications</strong></p> Make sure examples types match schema in definitions. (#1563</a>)</li> </ul> Push Gateway API</h3> No significant changes.</p> 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> 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> 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> 🖼️ 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> 💖 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> 🎉 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> 🔜 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> 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> 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> 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> 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> Identity Service API</h3> Spec Clarifications</strong></p> Corrections to the response format of /_matrix/identity/v2/store-invite</code>. (#1486</a>)</li> </ul> Push Gateway API</h3> No significant changes.</p> Room Versions</h3> Spec Clarifications</strong></p> Clarifications of event ID formats in early room versions (#1484</a>)</li> </ul> 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> 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> Matrix v1.6 release 2023-02-14T17:04:46+00:00 Hey all,</p> Matrix 1.6</a> is out there! Like Matrix 1.5 back in November</a>, this release is largely a maintenance update. Matrix 1.1 through 1.4 have been relatively major upgrades, so a little time between features doesn’t feel like a bad idea :)</p> As with all spec releases, we encourage implementations to gradually update over the next few months rather than have support for everything on release day - please be kind to the projects you use, and help them gain support if able.</p> Matrix 1.6 sees just 7 MSCs get merged, though this is to be expected from a maintenance release. Check out Matthew’s Matrix 2.0 talk</a> at FOSDEM for an idea of what’s expected over the next few releases.</p> We’ve covered a couple of the MSCs below, but read on to the full changelog for the full picture.</p> </span> MSC3030: Jump to date API</h2> _It’s here! The time machine we’ve been waiting for! _</p> Primarily part of the Gitter feature parity project</a> (congratulations to the team going all-in on Matrix</a>, by the way) to drive the Matrix Public Archive</a>, the new API</a> gives clients the ability to jump back in time to a nearby event. Being able to find something that was posted on a given day/week, but not being sure of which keywords to look for is a major usability improvement - many thanks to the Gitter team for making Matrix better!</p> MSC3706: Faster joins (part 1)</h2> Matrix is going voom</em></p> Synapse 1.76</a> enabled faster joins by default, and while there’s a lot of Python going into making joins as fast as possible, the specification side is a relatively small change at the moment: just don’t send as many events during joins</a> (omit_members</code>).</p> There’s potentially more work on the horizon for making faster joins even faster and more robust, and some of that might involve spec work: keep an eye on Synapse releases and TWIM</a> for updates as we make our way to faster joins in Matrix 2.0 :)</p> The full changelog</h2> MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. Check out the full changelog below, and the Spec Change Proposals</a> page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode</a> where Matthew covers the proposal process).</p> Client-Server API</h3> Backwards Compatible Changes</strong></p> Add information on standard error responses for unknown endpoints/methods, as per MSC3743</a>. (#1347</a>)</li> Add /rooms/<roomID>/timestamp_to_event</code> endpoint, as per MSC3030</a>. (#1366</a>)</li> Define hkdf-hmac-sha256.v2</code> MAC method for SAS verification, as per MSC3783</a>. (#1412</a>)</li> </ul> Spec Clarifications</strong></p> Clarify the power levels integer range. (#1169</a>, #1355</a>)</li> Clarify that /context</code> always returns event</code> even if limit</code> is zero. Contributed by @sumnerevans at @beeper. (#1239</a>)</li> Clarify what fields are required when deleting a pusher (#1321</a>)</li> Improve the presentation of push rule kinds and actions. (#1348</a>)</li> Add missing description to m.call.answer schema. (#1353</a>)</li> Fix various typos throughout the specification. (#1363</a>)</li> Clarify parts of the end-to-end encryption sections. (#1381</a>)</li> Move login API definitions to the right heading. Contributed by @HarHarLinks. (#1382</a>)</li> Clarify which events will be included in Stripped State. Contributed by @andybalaam. (#1409</a>)</li> Add links to the spec for the definition of 3PID medium</code>. (#1417</a>)</li> Correct the order of the default override pushrules in the spec. (#1421</a>)</li> Improve distinction between tags and their attributes in the rich text section. Contributed by Nico. (#1433</a>)</li> </ul> Server-Server API</h3> Breaking Changes</strong></p> Remove keyId</code> from the server /keys</code> endpoints, as per MSC3938</a>. (#1350</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add information on standard error responses for unknown endpoints/methods, as per MSC3743</a>. (#1347</a>)</li> Add /timestamp_to_event/<roomID></code> endpoint, as per MSC3030</a>. (#1366</a>)</li> Extend /_matrix/federation/v2/send_join</code> to allow omitting membership events, per MSC3706</a>. (#1393</a>, #1398</a>)</li> Note that /_matrix/federation/v2/send_join</code> should include heroes for nameless rooms, even when allowed to omit membership events, per MSC3943</a>. (#1425</a>)</li> </ul> Spec Clarifications</strong></p> Include examples inline instead of using a reference for invite endpoint definitions. (#1349</a>)</li> Fix POST _matrix/federation/v1/user/keys/claim</code> response schema. (#1351</a>)</li> Correct the default invite level definition in the "Checks performed on receipt of a PDU" section. (#1371</a>)</li> Clarify that CNAMEs are permissible for server names. (#1376</a>)</li> Fix edu_type</code> in EDU examples. (#1383</a>)</li> </ul> Application Service API</h3> Backwards Compatible Changes</strong></p> Add information on standard error responses for unknown endpoints/methods, as per MSC3743</a>. (#1347</a>)</li> </ul> Identity Service API</h3> Backwards Compatible Changes</strong></p> Add information on standard error responses for unknown endpoints/methods, as per MSC3743</a>. (#1347</a>)</li> </ul> Push Gateway API</h3> Backwards Compatible Changes</strong></p> Add information on standard error responses for unknown endpoints/methods, as per MSC3743</a>. (#1347</a>)</li> </ul> Room Versions</h3> Backwards Compatible Changes</strong></p> Update the default room version to 10, as per MSC3904</a>. (#1397</a>)</li> </ul> Spec Clarifications</strong></p> Clarify the grammar for room versions. (#1422</a>)</li> Fix various typos throughout the specification. (#1423</a>)</li> </ul> Appendices</h3> No significant changes.</p> Internal Changes/Tooling</h3> Spec Clarifications</strong></p> Add link to the unstable spec to the README. (#1357</a>)</li> Improve safety of the proposals retrieval script in the event of failure. (#1368</a>)</li> Rename <content></code> to content</code> in the OpenAPI files for content uploads. (#1370</a>)</li> Stop autogenerating examples where we already have an example. (#1384</a>)</li> Improve formatting of definitions in the Push Notifications section. (#1415</a>)</li> </ul> Matrix v1.5 release 2022-11-17T16:56:36+00:00 Hey all,</p> We’ve just released Matrix 1.5</a>, a largely maintenance update for the spec. We intentionally haven’t landed any major features in this release as Matrix 1.4, just shy of 2 months ago</a>, had introduced fairly large features for clients and servers to consider. As with all spec releases, we encourage implementations to gradually update over the next few months rather than expect them to have support for everything on release day.</p> Matrix 1.5 sees just 2 MSCs get merged, though this is to be expected from a maintenance release. We expect that the next release (in Q1 2023) will have a few more exciting features to it :)</p> We’ve covered both MSCs below, but read on to the full changelog for the full picture.</p> MSC3267: Reference relations</h2> Already supported implicitly by the spec up until now, reference relations</a> are a way to simply reference another event. Usually these sorts of relations are used for events which need to be related to each other, but a dedicated relationship type doesn’t make a lot of sense.</p> In-room verification</a> and MSC3381: Polls</a> are examples of how these relations get used.</p> MSC3905: Clarify appservice interest in user IDs</h2> MSC3905</a> fixes an issue in the specification where appservices (usually bridges) specifying a users regex without homeserver domain would end up receiving far more event traffic than they would have intended. With the MSC, appservices are now only considered interested in “local” users, regardless of how vague their users namespace is.</p> Overall this should have no effect on most bridges/appservices, however if an appservice in the wild really does need to listen to all users on all homeservers, it can specify a non-exclusive namespace on all rooms instead.</p> While writing this MSC into the spec we took some time to clarify the appservice registration requirements more generally: check them out here</a>.</p> The full changelog</h2> MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. Check out the full changelog below, and the Spec Change Proposals</a> page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode</a> where Matthew covers the proposal process).</p> Client-Server API</h3> Backwards Compatible Changes</strong></p> Add m.reference</code> relations, as per MSC3267</a>. (#1206</a>)</li> Add missing documentation for m.key.verification.request</code> msgtype for in-room verification. (#1271</a>)</li> </ul> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#1260</a>, #1265</a>, #1276</a>)</li> Fix naming of device_one_time_keys_count</code> in /sync</code>. (#1266</a>)</li> Improve display of event subtypes. (#1283</a>)</li> Improve documentation about ephemeral events. (#1284</a>)</li> Define a 400 response from /_matrix/client/v3/directory/rooms/{roomAlias}</code>. (#1286</a>)</li> Clarify parts of the end-to-end encryption sections. (#1294</a>, #1345</a>)</li> Various clarifications throughout the specification. (#1306</a>)</li> Replace set_sound</code> push rule action by set_tweak</code>. (#1318</a>)</li> Clarify the behavior of PUT /_matrix/client/v3/pushrules/{scope}/{kind}/{ruleId}</code>. (#1319</a>)</li> Clarify that .m.rule.master</code> has a higher priority than any push rule. (#1320</a>)</li> Require request field refresh_token</code> at endpoint POST /_matrix/client/v3/refresh</code>. (#1323</a>)</li> Fix a number of broken links in the specification. (#1330</a>)</li> Add example read receipt to GET /_matrix/client/v3/sync</code> response example. (#1341</a>)</li> </ul> Server-Server API</h3> Spec Clarifications</strong></p> Fix a number of broken links in the specification. (#1330</a>)</li> </ul> Application Service API</h3> Spec Clarifications</strong></p> Clarify that application services can only register an interest in local users, as per MSC3905</a>. (#1305</a>)</li> </ul> Identity Service API</h3> Spec Clarifications</strong></p> Fix a number of broken links in the specification. (#1330</a>)</li> </ul> Push Gateway API</h3> No significant changes.</p> Room Versions</h3> Spec Clarifications</strong></p> Reword the event auth rules to clarify that users cannot demote other users with the same power level. (#1269</a>)</li> Various clarifications to the text on event authorisation rules. (#1270</a>)</li> Fix a number of broken links in the specification. (#1330</a>)</li> </ul> Appendices</h3> No significant changes.</p> Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Update docsy theme to v0.5.0 + matrix.org modifications (https://github.com/matrix-org/docsy/commit/a0032f8db919a6c67ba6cdef2c455f105b6272a2). (#1295</a>)</li> </ul> Spec Clarifications</strong></p> Improve error messages emitted by resolve-additional-types</code> template. (#1303</a>)</li> Fix link to API viewer. (#1308</a>)</li> Stop rendering the subsections of the Client-Server API and Room Versions specs as their own separate pages. (#1317</a>)</li> Use a link checker to ensure that we do not have broken links. (#1329</a>, #1338</a>)</li> Update instructions to preview Swagger definitions. (#1331</a>)</li> Make definition anchors more unique. (#1339</a>)</li> Generate the unstable changelogs with towncrier, for consistency. (#1340</a>)</li> Update CONTRIBUTING.md to mention that non-content changes to this repo should have an "internal" changelog entry. (#1342</a>)</li> Update module summary table with new modules: Event Replacements, Threading and Reference Relations. (#1344</a>)</li> Disable RSS generation for the spec. (#1346</a>)</li> </ul> Matrix v1.4 release 2022-09-29T15:30:32+00:00 Hey all,</p> It’s finally here: threads</a>, edits</a>, and private read receipts</a>. v1.4 has been a little later than usual in the quarter because we wanted to make sure we nailed down all the core MSCs for threads before publishing the spec itself, but we’ve done that now and we’re excited about it.</p> </span> Matrix 1.3 was just over 3 months ago</a>, though with the relatively large features there and the colossal implementation effort of v1.4 we’re not expecting everyone to have implementations on day 1. Instead, as with all spec releases, we encourage implementations to gradually update over the next few months. We’re additionally planning to make v1.5 (Q4 2022) more of a maintenance update to help make the backlog a bit easier on everyone, though we might prioritize a couple cool features in there too :)</p> Matrix 1.4 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve instead focused on the 3 major features we’re excited about - check out the changelog at the end for the full picture.</p> 🧵 Threads</h2> Threads</a>, a critical feature in terms of parity with other chat systems, have landed thanks to a whopping 6 MSCs: MSC3440</a>, MSC3816</a>, MSC3856</a>, MSC3715</a>, MSC3771</a>, and MSC3773</a>. It’s been a lot of iteration on the reference implementations to get threads this far, and we’re excited to see how the client implementations evolve to provide more structured and less noisy communication for everyone - keep us updated with TWIM</a> posts, please!</p> Threads have involved changes to event relationships (which were fixed in v1.3</a>), read receipts, and notification counts, resulting in several different models and ways of solving the problem. We think we’ve reached a point that works for conversational threads, though there’s work on the horizon for threads-only rooms, Twitter-style free-form threads, etc to cover more needs of users.</p> Currently, the demonstration implementation of threads in Synapse and Element is working its way out of the proof-of-concept and beta stages (which were sufficient to validate the MSCs) and are on their way to exiting beta. Keep an eye on the respective blogs for news about production-ready threads!</p> 📝 Edits</h2> Similar to reactions, err, aggregations</a></em>, MSC2676</a> and its predecessors have been around for a long while. Edits have existed in the Element clients seemingly forever, and other clients have had troubles trying to implement the same feature: with it now in the spec, it should be a lot easier to bring edits into clients.</p> For edits, we’ve taken the route of making the MSC match reality, for better or worse. MSCs which improve or add functionality to the system are very much welcome - writing an MSC</a> is relatively easy and helps the whole community.</p> 👥 Private read receipts</h2> Not everyone wants to broadcast that they’ve read a message, but also with read receipts tied into notifications those same people also probably don’t want stuck notifications. To address the problem, we’ve added a new m.read.private receipt type</a> which behaves exactly like m.read, but is only visible to you.</p> We still have a rework of the notifications system in our long-term plan, but this should hopefully cover the privacy concerns for the time being :)</p> The full changelog</h2> MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals</a> page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode</a> where Matthew covers the proposal process).</p> Client-Server API</h3> Removed Endpoints</strong></p> Remove unused policy room sharing mechanism, as per MSC3844</a>. (#1196</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add a .m.rule.room.server_acl</code> push rule to match m.room.server_acl</code> events, as per MSC3786</a>. (#1190</a>, #1201</a>)</li> Add Cross-Origin-Resource-Policy</code> (CORP) headers to media repository, as per MSC3828</a>. (#1197</a>)</li> Copy a room's type</code> when upgrading it, as per MSC3818</a>. (#1198</a>)</li> Add room_types</code> filter and room_type</code> response to /publicRooms</code>, as per MSC3827</a>. (#1199</a>)</li> Add m.replace</code> relations (event edits), as per MSC2676</a>. (#1211</a>)</li> Add m.read.private</code> receipts, as per MSC2285</a>. (#1216</a>)</li> Make m.fully_read</code> optional on /read_markers</code>, as per MSC2285</a>. (#1216</a>)</li> Allow m.fully_read</code> markers to be set from /receipts</code>, as per MSC2285</a>. (#1216</a>)</li> Add threading via m.thread</code> relations, as per MSC3440</a>, MSC3816</a>, MSC3856</a>, and MSC3715</a>. (#1254</a>)</li> Add per-thread notifications and read receipts, as per MSC3771</a> and MSC3773</a>. (#1255</a>)</li> </ul> Spec Clarifications</strong></p> Mention that the /rooms/{roomId}/invite</code> endpoint will return a 200 response if the user is already invited to the room. (#1084</a>)</li> Fix various typos throughout the specification. (#1135</a>, #1161</a>, #1164</a>, #1170</a>, #1180</a>, #1215</a>, #1238</a>, #1243</a>)</li> Describe return codes for account data endpoints, and clarify that per-room data does not inherit from the global data. (#1155</a>)</li> Clarify that policy rule globs work like ACL globs. Contributed by Nico. (#1165</a>)</li> Clarify the format of some structures in the End-to-end encryption module. (#1166</a>)</li> Add HTML anchors for object definitions in the formatted specification. (#1174</a>)</li> Tweak the styling of <code></code> snippets in tables rendered from OpenAPI definitions. (#1179</a>)</li> Update "API Standards" section to clarify how JSON is used. (#1185</a>)</li> Clarify that the "device_id", "user_id" and "access_token" fields are required in the response body of POST /_matrix/client/v3/login</code>. (#1210</a>)</li> Reinforce the relationship of refreshed access tokens to transaction IDs. (#1236</a>)</li> Clarify enum values by separating possible values with commas. (#1240</a>)</li> </ul> Server-Server API</h3> Backwards Compatible Changes</strong></p> Add per-thread notifications and read receipts, as per MSC3771</a> and MSC3773</a>. (#1255</a>)</li> </ul> Spec Clarifications</strong></p> Add HTML anchors for object definitions in the formatted specification. (#1174</a>)</li> Tweak the styling of <code></code> snippets in tables rendered from OpenAPI definitions. (#1179</a>)</li> Update "API Standards" section to clarify how JSON is used. (#1185</a>)</li> </ul> Application Service API</h3> Breaking Changes</strong></p> Replace homeserver authorization approach with an Authorization</code> header instead of access_token</code> when talking to the application service, as per MSC2832</a>. (#1200</a>)</li> </ul> Spec Clarifications</strong></p> Add HTML anchors for object definitions in the formatted specification. (#1174</a>)</li> </ul> Identity Service API</h3> Spec Clarifications</strong></p> Add HTML anchors for object definitions in the formatted specification. (#1174</a>)</li> Update "API Standards" section to clarify how JSON is used. (#1185</a>)</li> </ul> Push Gateway API</h3> Spec Clarifications</strong></p> Add HTML anchors for object definitions in the formatted specification. (#1174</a>)</li> </ul> Room Versions</h3> Spec Clarifications</strong></p> For room versions 1 through 10, clarify that events with rejected auth_events</code> must be rejected. (#1137</a>)</li> For room versions 2–10: correct a mistaken clarification to the state resolution algorithm. (#1158</a>)</li> For room versions 7 through 10: Clarify that invite->knock</code> is actually a legal transition. (#1175</a>)</li> </ul> Appendices</h3> No significant changes.</p> Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p> Add internal changes changelog section. (#1194</a>)</li> </ul> Spec Clarifications</strong></p> Render HTML anchors for object definition tables. (#1191</a>)</li> Give rendered-data sections a background and some padding. (#1195</a>)</li> Fix rendering of shortcodes within the client-server API. (#1205</a>)</li> Fix the spacing of mapping types generated from the OpenAPI spec. (#1230</a>)</li> </ul> Matrix v1.3 release 2022-06-16T17:16:38+00:00 Hey all,</p> It’s another quarter and therefore another spec release</a>! Matrix 1.2 was released</a> back in February, and while a bit late in the quarter this time around we’ve still got some exciting additions coming to you in this release.</p> Like last time, the speed of these releases might feel a bit quick for developers: fret not if you’re still working on v1.1 or v1.2 implementations. We’re not expecting that implementations update as soon as a new spec release is published, but rather that the ecosystem gradually update over the course of the next few months. Implementations should be aiming for as close to realtime as they can get though, particularly considering v1.4 is expected to have some large features (more on that later on).</p> Matrix 1.3 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.</p> Aggregations and the relationships made along the way</h2> It’s no secret that MSC1849</a>-style server-side aggregation of related messages have been in the review backlog for a while. We ended up splitting MSC1849</a> down into more reviewable chunks like MSC2675</a>, allowing us to finally land the first pieces into Matrix 1.3 today.</p> In the spec there aren’t currently any defined relationships which make use of aggregations or even the rel_type</code> described by MSC2674</a>, but we do expect that v1.4 of the spec will have support for at least threads (MSC3440</a>) and edits (MSC2676</a>), filling the gap. For now, we’ve decided that holding aggregations back until v1.4 doesn’t make a lot of sense, so we have launched them into the world as-is for custom relations or for clients & servers to prepare for what’s expected to be coming in v1.4 of the spec.</p> To further prepare for threads, we’ve also removed some restrictions of rich replies through MSC3676</a>, thus allowing replies to be constructed with non-text messages like images. Check out the new rich replies module</a> for more information.</p> Join if you can, or just knock</h2> When we launched restricted rooms in Matrix 1.2 we noted</a> that we forgot to handle a case where someone might want to support both</em> knocking and restricted rooms at the same time. We’ve fixed that with a stop-gap join rule from MSC3787</a> in room version 10</a>.</p> The new knock_restricted</code> join rule allows the room to keep its desire to be restricted whilst also allowing members who do not meet the criteria to knock on the room instead. We’ll likely expand on this sort of mixing of join rules in proposals like MSC3386</a> down the line, however for now this should cover the gap in support. Next up: figuring out how to make encrypted room history available to these new joiners in a safe way.</p> A thread for next time</h2> Originally planned for this release, MSC3440</a>-style threads are anticipated to be ready for v1.4 (next quarter) with support for notifications and, of course, a whole new way to communicate in a room.</p> Threads are one of the more complicated features we’ve tried to land in recent history as it has a large impact on a wide variety of the spec: everything from event relationships (fixed in this release) to read receipts to push notifications needs to be worked out to build a system that not only users can understand, but also the developers trying to build it. With this massive surface area we just weren’t comfortable with adding threads to v1.3 as-is, given problems like notifications aren’t yet fully solved.</p> Alongside threads, we also anticipate that MSC2676</a>-style message editing will be landing in v1.4, finally specifying how to update an event’s contents without having to redact & re-send. Although message editing has been supported for a long time in some clients, we're excited that it will finally become part of the official specification, meaning it can be implemented more widely. Messaging clients are encouraged to give the proposal an early read and possibly even attempt implementation if not already done to help us ensure the system is in a reasonable state for inclusion in the spec, though we do note that feature requests for edits will likely be deferred to a future MSC.</p> Keep an eye on This Week In Matrix</a> for updates on what v1.4 is expected to include, and how things are progressing.</p> The full changelog</h2> MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals</a> page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode</a> where Matthew covers the proposal process).</p> Client-Server API</h3> Deprecations</strong></p> Deprecate the sender_key</code> and device_id</code> on m.megolm.v1.aes-sha2</code> events, and the sender_key</code> on m.room_key_request</code> to-device messages, as per MSC3700</a>. (#1101</a>)</li> </ul> Backwards Compatible Changes</strong></p> Make from</code> optional on GET /_matrix/client/v3/messages</code> to allow requesting events from the start or end of the room history, as per MSC3567</a>. (#1002</a>)</li> Add refresh tokens, per MSC2918</a>. (#1056</a>, #1113</a>)</li> Relax the restrictions on Rich Replies, as per MSC3676</a>. (#1062</a>)</li> Describe a structured system for event relationships, as per MSC2674</a>. (#1062</a>)</li> Describe how relationships between events can be "aggregated", as per MSC2675</a> and MSC3666</a>. (#1062</a>)</li> Add support for a new knock_restricted</code> join rule in supported room versions, as per MSC3787</a>. (#1099</a>)</li> </ul> Spec Clarifications</strong></p> Clarify that the url field in m.room.avatar</code> events is not required. (#987</a>)</li> Clarify that the type</code> in user-interactive authentication can be omitted. (#989</a>)</li> Adjust the OpenAPI specification so that the type Flow information</code> is explicitly defined when the client-server API is rendered. (#1003</a>)</li> Correct the default value for invite</code> where it is not specified in an m.room.power_levels</code> event. (#1021</a>)</li> Update various links which pointed to the old matrix-doc</code> github repository. (#1032</a>)</li> Removed m.room.message.feedback</code> per MSC3582</a>. (#1035</a>)</li> Fix various typos throughout the specification. (#1051</a>, #1054</a>, #1059</a>, #1081</a>, #1097</a>, #1110</a>, #1115</a>, #1126</a>, #1127</a>, #1128</a>, #1129</a>, #3681</a>, #3708</a>)</li> Clarify that state keys starting with @</code> are in fact reserved. Regressed from #3658</a>. (#1100</a>)</li> Remove unenforced size limit on the name</code> field of m.room.name</code> events. (#3669</a>)</li> Remove erroneous room_id</code> field from examples of m.read</code>, m.typing</code> in /sync</code> and m.fully_read</code> in room account data. (#3679</a>)</li> Clarify the behaviour of event_match</code> in push rule conditions. (#3690</a>)</li> Fix incorrectly referenced m.login.appservice</code> login identifier, instead using m.login.application_service</code>. (#3711</a>)</li> Fix membership state transitions to denote that invite->knock</code> and external->leave</code> are valid transitions. (#3730</a>)</li> </ul> Server-Server API</h3> Backwards Compatible Changes</strong></p> Add a destination</code> property to the Authorization header, as per MSC3383</a>. (#1067</a>)</li> </ul> Spec Clarifications</strong></p> Remove largely unused origin</code> field from PDUs. (#998</a>)</li> Update various links which pointed to the old matrix-doc</code> github repository. (#1032</a>)</li> Clarify the format for the Authorization header. (#1038</a>, #1067</a>)</li> Clarify what a "valid event" means when performing checks on a received PDU. (#1045</a>)</li> Clarify that valid_until_ts</code> is in milliseconds, like other timestamps used in Matrix. (#1055</a>)</li> Clarify that checks on PDUs should refer to the state before</em> an event. (#1070</a>)</li> Clarify the historical handling of non-integer power levels. (#1099</a>)</li> Fix various typos throughout the specification. (#1110</a>)</li> Correct misleading text for /send_join</code> response. (#3703</a>)</li> Clarify that the content</code> for X-Matrix</code> signature validation is the parsed JSON body. (#3727</a>)</li> </ul> Application Service API</h3> Backwards Compatible Changes</strong></p> Add timestamp massaging as per MSC3316</a>. (#1094</a>)</li> </ul> Identity Service API</h3> No significant changes.</p> Push Gateway API</h3> No significant changes.</p> Room Versions</h3> Backwards Compatible Changes</strong></p> Add room version 10 as per MSC3604</a>. (#1099</a>)</li> Enforce integer power levels in room version 10 as per MSC3667</a>. (#1099</a>)</li> Add a knock_restricted</code> join rule supported by room version 10 as per MSC3787</a>. (#1099</a>)</li> Update the default room version to 9 as per MSC3589</a>. (#3739</a>)</li> </ul> Spec Clarifications</strong></p> Improve readability and understanding of the state resolution algorithms. (#1037</a>, #1042</a>, #1043</a>, #1120</a>)</li> Improve readability of the authorization rules. (#1050</a>)</li> For room versions 8, 9, and 10: clarify which homeserver is required to sign the join event. (#1093</a>)</li> Clarify that room versions 1 through 9 accept stringy power levels, as noted by MSC3667</a>. (#1099</a>)</li> For all room versions: Add m.federate</code> to the authorization rules, as originally intended. (#1103</a>)</li> For room versions 2 through 10: More explicitly define the mainline of a power event and the mainline ordering of other events. (#1107</a>)</li> For room versions 7, 8, 9, and 10: fix join membership authorization rules when join_rule</code> is knock</code>. (#3737</a>)</li> </ul> Appendices</h3> No significant changes.</p> Matrix v1.2 release 2022-02-02T18:57:31+00:00 Hey all,</p> Welcome to the second installment of our quarterly spec releases. If it feels like it hasn’t been long since our last release, you’re not alone! Our last release</a> was just 3 months ago, introducing the new platform and world we build within.</p> This improvement in speed might seem too</em> fast, but fret not: implementations are not expected to update as soon as the new spec is published. Rather, it is more realistic to expect that the ecosystem gradually update over the course of the following few months/year. Particularly after the massive release that was v1.1.</p> So, what’s new in v1.2? With 18 MSCs merged there’s a lot to cover - we’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.</p> Rearchitecting with Spaces</h2> Spaces launched into beta last May</a>, redefining how we can use rooms on Matrix to represent different data structures. Described mostly as MSC1772</a>, Spaces are simply rooms with a specific type in their m.room.create event</a>. With state events being used to define which other rooms (meaning Spaces too) are part of that Space, the possibilities for tree-like structured data become endless.</p> There’s still quite a lot of work to do in the Spaces space (hah), though we’re excited to see it all land. For instance, MSC3216</a> and MSC2962</a> target power level syncing, MSC3219</a> aims for flair, and MSC3089</a> looks at file structures using Spaces. We might even be able to replace the public room directory with a server-wide space, making writing clients a little bit easier.</p> Public, but not too</em> public, join rules</h2> Restricted rooms</a> are new in this release from MSC3083</a>. In these rooms (and therefore Spaces too!</em>), the join rules can be configured such that a member of another room can join without needing an invite. In a typical setup, this means that a Space could be set as invite-only, but all the rooms and Spaces underneath that Space could allow joins for members of the parent Space. When someone wishes to explore the universe you’ve laid out in your Space they can simply join the interesting rooms without having to ask for invites constantly</em>.</p> This feature changes how membership events are authorized, so is only available in room versions 8 and 9 (both introduced in this release). Room version 9 fixes a relatively rare bug from version 8, so we’d recommend using v9 if you’re planning an upgrade for this functionality.</p> Further work in this area involves figuring out how to keep membership lists perfectly in sync between the rooms, which is currently done by external tooling. For example, evicting someone from the parent Space could (optionally) evict the user from all the subsequent rooms and Spaces too.</p> We also need to figure out how to support both knocking and restricted rooms at the same time (oops). MSC3613</a> and MSC3386</a> both tackle this problem in different ways and timescales.</p> Matrix: A URI</h2> A massive shoutout goes to kitsune and the whole community for working on MSC2312</a>, giving us a URI we can pass around outside of Matrix to bring us back in. The early work on this dates all the way back to 2014</a>, the very beginning of Matrix’s development, and has since been marked Provisional</a> by the IANA.</p> The full spec is available here</a> - feel free to discuss it at matrix:r/matrix-spec:matrix.org</a> ;)</p> The full changelog</h2> MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals</a> page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode</a> where Matthew covers the proposal process).</p> Client-Server API</h3> Breaking Changes</strong></p> The prev_content</code> field is now returned inside the unsigned</code> property of events, rather than at the top level, as per MSC3442</a>. (#3524</a>)</li> The aliases</code> property from the chunks returned by /publicRooms</code>, as per MSC2432</a>. (#3624</a>)</li> </ul> New Endpoints</strong></p> Add the Space Hierarchy API (GET /_matrix/client/v1/rooms/{roomId}/hierarchy</code>) as per MSC2946</a>. (#3610</a>)</li> Add /_matrix/client/v1/register/m.login.registration_token/validity</code> as per MSC3231</a>. (#3616</a>)</li> </ul> Backwards Compatible Changes</strong></p> Extend /_matrix/client/r0/login</code> to accept a m.login.appservice</code>, as per MSC2778</a>. (#3324</a>)</li> Add support for restricted</code> rooms as per MSC3083</a>, MSC3289</a>, and MSC3375</a>. (#3387</a>)</li> Add is_guest</code> to /account/whoami</code> as per MSC3069</a>. (#3605</a>)</li> Expand guest access to sending any room event and state event as per MSC3419</a>. (#3605</a>)</li> Add Spaces and room types as per MSC1772</a> and MSC2946</a>. (#3610</a>)</li> Add new m.set_displayname</code>, m.set_avatar_url</code>, and m.3pid_changes</code> capabilities as per MSC3283</a>. (#3614</a>)</li> Add support for fallback keys (optional keys used once one-time keys run out), as per MSC2732</a>. (#3615</a>)</li> Add token-authenticated registration support as per MSC3231</a>. (#3616</a>)</li> </ul> Spec Clarifications</strong></p> Make AesHmacSha2KeyDescription</code> consistent with KeyDescription</code> in marking name</code> as optional. (#3481</a>)</li> Fix various typos throughout the specification. (#3482</a>, #3495</a>, #3509</a>, #3535</a>, #3591</a>, #3601</a>, #3611</a>, #3671</a>, #3680</a>)</li> Explicitly mention RFC5870 in the definition of m.location</code> events (#3492</a>)</li> Add 403 M_FORBIDDEN</code> error code to /profile/{userId}</code> as per MSC3550</a>. (#3530</a>)</li> Clarify the description of the /sync</code> API, including a fix to an ASCII art diagram. (#3543</a>)</li> Clarify that base_url</code> in client well_known</code> may or may not include trailing slash. (#3562</a>)</li> Clarify which signature to check when decrypting m.olm.v1.curve25519-aes-sha2</code> messages. (#3573</a>)</li> Clarify what "Stripped State" is and what purpose it serves, as per MSC3173</a>. (#3606</a>)</li> Clarify how to interpret missing one-time key counts. (#3636</a>)</li> Correct the schema for the responses for various API endpoints. (#3650</a>)</li> Clarify that group mentions are no longer in the specification. (#3652</a>)</li> Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658</a>)</li> Fix the rendering of the responses for various API endpoints. (#3674</a>)</li> </ul> Server-Server API</h3> New Endpoints</strong></p> Add the Space Hierarchy API (GET /_matrix/federation/v1/hierarchy/{roomId}</code>) as per MSC2946</a>. (#3610</a>, #3660</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add support for restricted</code> rooms as per MSC3083</a>, MSC3289</a>, and MSC3375</a>. (#3387</a>)</li> </ul> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#3527</a>)</li> Clarify that GET /_matrix/federation/v1/event_auth/{roomId}/{eventId}</code> does not</em> return the auth chain for the full state of the room. (#3583</a>)</li> Fix the rendering of the responses for various API endpoints. (#3674</a>)</li> </ul> Application Service API</h3> Spec Clarifications</strong></p> Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658</a>)</li> Fix the rendering of the responses for various API endpoints. (#3674</a>)</li> Correct the documentation for the response value for GET /_matrix/app/v1/thirdparty/protocol/{protocol}</code>. (#3675</a>)</li> </ul> Identity Service API</h3> Backwards Compatible Changes</strong></p> Add the room_type</code> to stored invites as per MSC3288</a>. (#3610</a>)</li> </ul> Spec Clarifications</strong></p> Fix the rendering of the responses for various API endpoints. (#3674</a>)</li> </ul> Push Gateway API</h3> Spec Clarifications</strong></p> Fix the rendering of the responses for various API endpoints. (#3674</a>)</li> </ul> Room Versions</h3> Backwards Compatible Changes</strong></p> Add Room Version 8 as per MSC3289</a>. (#3387</a>)</li> Add Room Version 9 as per MSC3375</a>. (#3387</a>)</li> </ul> Spec Clarifications</strong></p> Fully specify room versions to indicate what exactly is carried over from parent versions. (#3432</a>, #3661</a>)</li> Clarifications to sections on event IDs and event formats. (#3501</a>)</li> Remove a number of fields which were incorrectly shown to form part of the unsigned</code> data of a Federation PDU. (#3522</a>)</li> Fix heading order of room version specifications to be consistent. (#3683</a>)</li> Add missing "Signing key validity period" section to room version 6. (#3683</a>)</li> Fix auth rules to allow membership of knock</code> -> leave</code> in v7, v8, and v9. (#3694</a>)</li> </ul> Appendices</h3> Backwards Compatible Changes</strong></p> Describe "Common Namespaced Identifier Grammar" as per MSC2758</a>. (#3171</a>)</li> Describe the matrix:</code> URI scheme as per MSC2312</a>. (#3608</a>)</li> </ul> Matrix v1.1 release 2021-11-09T21:28:29+00:00 Hey all,</p> Once again it's been a little while</a> since we've done a spec release (sorry; we're aiming for quarterly releases from here on out), but this time we have some pretty big news: we've got an all-new spec platform</a> and a new versioning scheme. The new spec platform has been needed for a long time to make better sense of what Matrix is, and as part of getting that out the door we reduced the number of "Matrix versions" to just one.</p> Huge thanks to Will Bamberg for building it out for us, anoa for working out the deployment details, and everyone for testing it all. They talk at length about what this specification even is and about the platform itself on Matrix Live S6E19</a>. It's the single greatest improvement to the spec we've seen to date.</p> The new versioning scheme presents the whole specification as a single document, making it easier to check compatibility between implementations and the spec itself. Previously, a grid would have to be drawn to show whether Server-Server r0.1.4 is compatible with Client-Server r0.6.1 - while obvious at release time, the historical context gets lost quite easily. Now, with a single version number, the entire specification is compatible across a single version number: servers implementing Matrix 1.1 will be compatible with clients implementing v1.1, and vice versa. For the specification itself, this means we no longer have to carefully point and update links between the APIs, as they'll instead be versioned together.</p> Changing the versioning of the specification does have an impact on the Client-Server API in particular, however. You may have noticed that Client-Server APIs are currently versioned at "r0". By removing rX.Y.Z versioning, all of the endpoints suddenly don't have a version to reference. All endpoints across the specification are now versioned individually to allow for breaking changes at the endpoint level. They no longer require the whole specification to be listed as a breaking change: a v1 endpoint can get additions/changes which are backwards compatible, but if we need to change format (for example) then it'll get bumped up to v2, leaving v1 in its last known state.</p> For the Client-Server API, a slight complication is that v1 and v2 (alpha) are already versions familiar to those that have been around for a while - to avoid confusing those people, existing Client-Server API endpoints will start at v3. New endpoints introduced after v1.1 will start at v1 instead.</p> It's been well over a year since the last release, which means there's a whole lot of features and changes to cover. Here we'll try to cover the things most clients/servers will have to worry about, but we do still recommend reading through the changelog included below. Overall, 28 MSCs have been merged through this release, but some have had to be excluded in the interest of getting the spec release out there. Many of them are expected to be in the next anticipated release (which should hopefully be next quarter).</p> Clients: There's a lot of stuff</h2> In Matrix 1.1, client developers get all sorts of new features to play with. Clients which support end-to-end encryption should explore key backups</a></strong>, cross-signing</a></strong>, SSSS</a></strong>, and breaking changes to verification</a></strong>. Quite a lot of this stuff has existed for a while, but has made it into the specification formally now. As an added bonus, the emoji for SAS verification have been translated</a> (contribute here</a>).</p> Knocking has also landed in the spec (thanks Sorunome for leading the charge on this!), opening up the ability for rooms to optionally allow people to request invites to join. This can be helpful for semi-private rooms where it can be easier to approve/deny requests compared to finding someone's MXID and manually inviting them. This does require a v7 room</a> to work, however.</p> Thanks again to Sorunome, Message Spoilers</a> have been officially included in Matrix. People can now safely discuss the ending to the latest movie without being banned for spoilers. Though, as a new feature, there's a chance that the spoiler text still gets included in the message: clients should update as soon as possible to avoid their users accidentally getting banned for spoiling the conclusion to the Spaces saga</a> ;)</p> There's a few other smaller improvements/additions, and of course the regular "various clarifications and bug fixes" to take a look at. For a sample checklist, check out element-web's issue</a> on the subject.</p> Servers: Knock knock, it's a new room version</h2> Room version 7</a> has landed, bringing forth the ability for users to knock on rooms (requesting an invite to join). The changes are largely scoped to using the reserved keywords for join rules and membership, and are described through the auth rules. Thankfully, the changes over v6 are minimally invasive so should be quick to implement.</p> Additionally, the cross-signing bits</a> have been included in the API responses and EDU definitions. Matthew's blog post</a> from last year (it really has been that long...) describes cross-signing and the history of its implementation.</p> As per usual, there's also various specification errors corrected to aid understanding. Synapse has an exhaustive issue</a> to detail what servers might need to do.</p> PS: Room versions 8 and 9 are also out there, but will be included in a future spec release.</em></p> The full changelog</h2> We haven't mentioned identity servers, bridges, etc in this post but they have changes too! Below is the whole changelog, the entire year and a bit of it. Thank you to everyone who has submitted MSCs, and congratulations on getting them released. If we forgot yours, please mention it in #matrix-spec:matrix.org</a> so we can apologize and correct.</p> PS: The MSC process is how changes to Matrix are made, and you (yes, you) can propose those changes too. Check out the Matrix Live episode</a> where Matthew talks about how this process works, and how we avoid blocking clients from implementing their proposals behind the relatively slow spec release cycles.</p> Client-Server API</h3> Breaking Changes</strong></p> Document curve25519-hkdf-sha256</code> key agreement method for SAS verification, and deprecate old method as per MSC2630</a>. (#2687</a>)</li> Add m.key.verification.ready</code> and m.key.verification.done</code> to key verification framework as per MSC2366</a>. (#3139</a>)</li> </ul> Deprecations</strong></p> Deprecate starting verifications that don't start with m.key.verification.request</code> as per MSC3122</a>. (#3199</a>)</li> </ul> New Endpoints</strong></p> Add key backup (/room_keys/*</code>) endpoints as per MSC1219</a>. (#2387</a>, #2639</a>)</li> Add POST /keys/device_signing/upload</code> and POST /keys/signatures/upload</code> as per MSC1756</a>. (#2536</a>)</li> Add /knock</code> endpoint as per MSC2403</a>. (#3154</a>)</li> Add /login/sso/redirect/{idpId}</code> as per MSC2858</a>. (#3163</a>)</li> </ul> Removed Endpoints</strong></p> Remove unimplemented m.login.oauth2</code> and m.login.token</code> user-interactive authentication mechanisms as per MSC2610</a> and MSC2611</a>. (#2609</a>)</li> </ul> Backwards Compatible Changes</strong></p> Document how clients can advise recipients that it is withholding decryption keys as per MSC2399</a>. (#2399</a>)</li> Add cross-signing properties to the response of POST /keys/query</code> as per MSC1756</a>. (#2536</a>)</li> Document Secure Secret Storage and Sharing as per MSC1946</a> and MSC2472</a>. (#2597</a>)</li> Add a device_id</code> parameter to login fallback as per MSC2604</a>. (#2709</a>)</li> Added a common set of translations for SAS Emoji. (#2728</a>)</li> Added support for reason</code> on all membership events and related endpoints as per MSC2367</a>. (#2795</a>)</li> Add a 404 M_NOT_FOUND</code> error to push rule endpoints as per MSC2663</a>. (#2796</a>)</li> Make reason</code> and score</code> parameters optional in the content reporting API as per MSC2414</a>. (#2807</a>)</li> Allow guests to get the list of members for a room as per MSC2689</a>. (#2808</a>)</li> Add support for spoilers as per MSC2010</a> and MSC2557</a>, and color</code> attribute as per MSC2422</a>. (#3098</a>)</li> Add <details></code> and <summary></code> to the suggested HTML subset as per MSC2184</a>. (#3100</a>)</li> Add key verification using in-room messages as per MSC2241</a>. (#3139</a>, #3150</a>)</li> Add information about using SSSS for cross-signing and key backup. (#3147</a>)</li> Add key verification method using QR codes as per MSC1544</a>. (#3149</a>)</li> Document how clients can simplify usage of Secure Secret Storage as per MSC2874</a>. (#3151</a>)</li> Add support for knocking, as per MSC2403</a>. (#3154</a>, #3254</a>)</li> Multiple SSO providers are possible through m.login.sso</code> as per MSC2858</a>. (#3163</a>)</li> Add device_id</code> to /account/whoami</code> response as per MSC2033</a>. (#3166</a>)</li> Downgrade identity server discovery failures to FAIL_PROMPT</code> as per MSC2284</a>. (#3169</a>)</li> Re-version all endpoints to be v3</code> as a starting point instead of r0</code> as per MSC2844</a>. (#3421</a>)</li> </ul> Spec Clarifications</strong></p> Fix issues with age</code> and unsigned</code> being shown in the wrong places. (#2591</a>)</li> Fix definitions for room version capabilities. (#2592</a>)</li> Fix various typos throughout the specification. (#2594</a>, #2599</a>, #2809</a>, #2878</a>, #2885</a>, #2888</a>, #3116</a>, #3339</a>)</li> Clarify link to OpenID Connect specification. (#2605</a>)</li> Clarify the behaviour of SSO login and UI-Auth. (#2608</a>)</li> Remove spurious room_id</code> from /sync</code> examples. (#2629</a>)</li> Reorganize information in Push Notifications module for clarity. (#2634</a>)</li> Improve consistency and clarity of event schema title</code>s. (#2647</a>)</li> Fix schema issues in m.key.verification.accept</code> and secret storage. (#2653</a>)</li> Reword "UI Authorization" to "User-Interactive Authentication" to be more clear. (#2667</a>)</li> Fix schemas for push rule actions to represent their alternative object form. (#2669</a>)</li> Fix usage of highlight</code> tweak for consistency. (#2670</a>)</li> Clarify the behaviour of state</code> for /sync</code> with lazy-loading. (#2754</a>)</li> Clarify description of m.room.redaction</code> event. (#2814</a>)</li> Mark messages</code> as a required JSON body field in PUT /_matrix/client/r0/sendToDevice/{eventType}/{txnId}</code> calls. (#2928</a>)</li> Correct examples of client_secret</code> request body parameters so that they do not include invalid characters. (#2985</a>)</li> Fix example MXC URI for m.presence</code>. (#3091</a>)</li> Clarify that event bodies are untrusted, as per MSC2801</a>. (#3099</a>)</li> Fix the maximum event size restriction (65535 bytes -> 65536). (#3127</a>)</li> Update Access-Control-Allow-Headers</code> recommendation to fit CORS specification. (#3225</a>)</li> Explicitly state that replacement_room</code> is a room ID in m.room.tombstone</code> events. (#3233</a>)</li> Clarify that all request bodies are required. (#3238</a>, #3332</a>)</li> Add missing titles to some scheams. (#3330</a>)</li> Add User-Interactive Authentication fields to cross-signing APIs as per MSC1756</a>. (#3331</a>)</li> Mention that a canonical alias event should be added when a room is created with an alias. (#3337</a>)</li> Add an 'API conventions' section to the Appendices. (#3350</a>)</li> Clarify the documentation around the pagination tokens used by /sync</code>, /rooms/{room_id}/messages</code>, /initialSync</code>, /rooms/{room_id}/initialSync</code>, and /notifications</code>. (#3353</a>)</li> Remove the inaccurate 'Pagination' section. (#3366</a>)</li> Clarify how redacted_because</code> is meant to work. (#3411</a>)</li> Remove extraneous mimetype</code> from EncryptedFile</code> examples, as per MSC2582</a>. (#3412</a>)</li> Describe how MSC2844</a> affects the /versions</code> endpoint. (#3420</a>)</li> Fix documentation errors around threepid_creds</code>. (#3471</a>)</li> </ul> Server-Server API</h3> New Endpoints</strong></p> Add /make_knock</code> and /send_knock</code> endpoints as per MSC2403</a>. (#3154</a>)</li> </ul> Backwards Compatible Changes</strong></p> Add cross-signing information to GET /user/keys</code> and GET /user/devices/{userId}</code>, m.device_list_update</code> EDU, and a new m.signing_key_update</code> EDU as per MSC1756</a>. (#2536</a>)</li> Add support for knocking, as per MSC2403</a>. (#3154</a>)</li> </ul> Spec Clarifications</strong></p> Specify that GET /_matrix/federation/v1/make_join/{roomId}/{userId}</code> can return a 404 if the room is unknown. (#2688</a>)</li> Fix various typos throughout the specification. (#2888</a>, #3116</a>, #3128</a>, #3207</a>)</li> Correct the /_matrix/federation/v1/user/devices/{userId}</code> response which actually returns "self_signing_key"</code> instead of "self_signing_keys"</code>. (#3312</a>)</li> Explain the reasons why <hostname></code> TLS certificate is needed rather than <delegated_hostname></code> for SRV delegation. (#3322</a>)</li> Tweak the example PDU diagram to better demonstrate situations with multiple prev_events</code>. (#3340</a>)</li> </ul> Application Service API</h3> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#2888</a>)</li> </ul> Identity Service API</h3> New Endpoints</strong></p> Add GET /_matrix/identity/versions</code> API as per MSC2320</a>. (#3101</a>)</li> </ul> Removed Endpoints</strong></p> The v1 identity service API has been removed in favour of the v2 API, as per MSC2713</a>. (#3170</a>)</li> </ul> Spec Clarifications</strong></p> Fix various typos throughout the specification. (#2888</a>)</li> Clarify that some identifiers must be case folded prior to processing, as per MSC2265</a>. (#3167</a>, #3176</a>)</li> Describe how MSC2844</a> affects the /versions</code> endpoint. (#3459</a>)</li> </ul> Push Gateway API</h3> Spec Clarifications</strong></p> Clarify where to get information about the various parameter values for the notify endpoint. (#2763</a>)</li> </ul> Room Version 6, Client-Server r0.6.1, and Federation r0.1.4 spec releases 2020-05-27T00:00:00+00:00 Room Version 6, Client-Server r0.6.1, and Federation r0.1.4 spec releases</h2> Hey all,</p> It's been a little while</a> since we've done a spec release, so here we are with Room Version 6</a>, Client-Server r0.6.1</a>, and Federation r0.1.4</a>.</p> Room Version 6 (and the associated Federation r0.1.4 release) is largely something for implementations to worry about. It contains new event authorisation rules, changes to the redaction algorithm, and stricter compliance for JSON.</p> Client-Server r0.6.1 contains a number of clarifications as well as SSO support for authorisation, "soft logout" to avoid needlessly destroying e2e history, and new ways to publish aliases within rooms.</p> If you're wondering where all the E2E-by-default related MSCs are - we're doing final iterations based on the real-world feedback from the E2E-by-default launch a few weeks ago, and they are then expected to land in the upcoming Client-Server r0.7.</p> Here's all the MSCs that got merged since the last release:</p> MSC2240</a>: Room version 6</li> MSC2457</a>: Invalidating devices during password modification</li> MSC2454</a>: Support UI auth for SSO</li> MSC2451</a>: Remove query_auth</code> federation endpoint</li> MSC2432</a>: Updated semantics for publishing room aliases</li> MSC2324</a>: Facilitating early releases of software dependent on spec</li> MSC2313</a>: Moderation policies as rooms</li> MSC1466</a>: Soft Logout</li> MSC2540</a>: Stricter event validation: JSON compliance</li> MSC2209</a>: Alter auth rules to check notifications in m.room.power_levels</li> MSC1802</a>: Remove the '200' value from some federation responses</li> </ul> Client-Server r0.6.1 changelog</h3> New Endpoints</h4> Added /rooms/{roomId}/aliases</code> for retrieving local aliases for a room. (#2562</a>)</li> </ul> Backwards Compatible Changes</h4> Added data structures for defining moderation policies in rooms per MSC2313</a>. (#2434</a>)</li> Optionally invalidate other access tokens during password modification per MSC2457</a>. (#2523</a>)</li> Add User-Interactive Authentication for SSO-backed homeserver per MSC2454</a>. (#2532</a>)</li> Add soft-logout support per MSC1466</a>. (#2546</a>)</li> Replaced legacy room alias handling with a more sustainable solution per MSC2432</a>. (#2562</a>)</li> </ul> Spec Clarifications</h4> List available enum values for the room versions capability. (#2245</a>)</li> Fix various spelling errors throughout the specification. (#2351</a>, #2415</a>, #2453</a>, #2524</a>, #2553</a>, #2569</a>)</li> Minor clarifications to token-based User-Interactive Authentication. (#2369</a>)</li> Minor clarification for what the user directory searches. (#2381</a>)</li> Fix key export format example to match the specification. (#2430</a>)</li> Clarify the IV data type for encrypted files. (#2492</a>)</li> Fix the .m.rule.contains_user_name</code> default push rule to set the highlight tweak. (#2519</a>)</li> Clarify that an event_id</code> is returned when sending events. (#2525</a>)</li> Fix some numbers in the specification to match their explanation text. (#2554</a>)</li> Move redaction algorithm into the room version specifications. (#2563</a>)</li> Clarify signature object structures for encryption. (#2566</a>)</li> Clarify which events are created as part of /createRoom</code>. (#2571</a>)</li> Remove claims that the homeserver is exclusively responsible for profile information in membership events. (#2574</a>)</li> </ul> Server-Server (Federation) r0.1.4 changelog</h3> New Endpoints</h4> Add new POST /publicRooms</code> endpoint for filtering the room directory. (#2305</a>)</li> Add new v2 /send_join</code> and /send_leave</code> endpoints per MSC1802</a>. (#2547</a>)</li> </ul> Removed Endpoints</h4> Remove the unused query_auth</code> API per MSC2451</a>. (#2470</a>)</li> </ul> Spec Clarifications</h4> Move auth event selection to a more obvious location. (#2392</a>)</li> Fix typo in Request Authentication python example. (#2510</a>)</li> Clarify which fields are required on the key server endpoints. (#2527</a>)</li> Clarify the limits of prev_events</code> and auth_events</code> for PDUs. (#2538</a>)</li> Clarify which events are targeted by backfill. (#2559</a>)</li> Fix the response format of the /send</code> endpoint. (#2560</a>)</li> Clarify signature object structures for encryption. (#2566</a>)</li> Clarify the server names to use when signing requests. (#2570</a>)</li> Clarify the state/auth chain requirements for /send_join</code>. (#2575</a>)</li> Fix various spelling errors throughout the specification. (#2577</a>)</li> </ul> Client-server r0.6.0 and Identity Service r0.3.0 releases 2019-11-08T00:00:00+00:00 Hey all,</p> For the last several months the team has been working on tightening up privacy in Matrix</a>, and with the 1.4 release of Synapse and Riot</a> quite a lot has been done in the area. One of the remaining pieces was to release all the specification changes to help other client/server implementations achieve the same goals, and now we've done that.</p> The Client-Server r0.6.0</a> and Identity Service r0.3.0</a> spec releases both cover the privacy improvements added through a number of MSCs in the last few months. Of particular note is that identity servers are now expected to support terms of service endpoints, which requires authentication that clients might need to worry about - check the spec changelogs for details.</p> The full changelog for the Client-Server r0.6.0 release is:</p> Breaking Changes</p> Add id_access_token</code> as a required request parameter to a few endpoints which require an id_server</code> parameter as part of MSC2140</a>. (#2255</a>)</li> </ul> </li> New Endpoints</p> Add POST /account/3pid/unbind</code> for removing a 3PID from an identity server. (#2282</a>)</li> </ul> </li> Backwards Compatible Changes</p> Add M_USER_DEACTIVATED</code> error code. (#2234</a>)</li> Remove bind_msisdn</code> and bind_email</code> from /register</code> now that the identity server's bind endpoint requires authentication. (#2279</a>)</li> Add m.identity_server</code> account data for tracking the user's preferred identity server. (#2281</a>)</li> Deprecate id_server</code> and make it optional in several places. (#2310</a>)</li> </ul> </li> Spec Clarifications</p> Add missing format fields to m.room.message$m.notice</code> schema. (#2125</a>)</li> Remove "required" designation from the url</code> field of certain m.room.message</code> msgtypes. (#2129</a>)</li> Fix various typos throughout the specification. (#2131</a>, #2136</a>, #2148</a>, #2215</a>)</li> Clarify the distinction between m.key.verification.start</code> and its m.sas.v1</code> variant. (#2132</a>)</li> Fix link to Olm signing specification. (#2133</a>)</li> Clarify the conditions for the .m.rule.room_one_to_one</code> push rule. (#2152</a>)</li> Clarify the encryption algorithms supported by the device of the device keys example. (#2157</a>)</li> Clarify that /rooms/:roomId/event/:eventId</code> returns a Matrix error. (#2204</a>)</li> Add a missing state_key</code> check on .m.rule.tombstone</code>. (#2223</a>)</li> Fix the m.room_key_request</code> action</code> value, setting it from cancel_request</code> to request_cancellation</code>. (#2247</a>)</li> Clarify that the submit_url</code> field is without authentication. (#2341</a>)</li> Clarify the expected phone number format. (#2342</a>)</li> Clarify that clients should consider not requesting URL previews in encrypted rooms. (#2343</a>)</li> Add missing information on how filters are meant to work with /context</code>. (#2344</a>)</li> Clarify what the keys are for rooms in /sync</code>. (#2345</a>)</li> </ul> </li> </ul> The full changelog for the Identity Service r0.3.0 release is:</p> New Endpoints</p> Add /account</code>, /account/register</code>, and /account/logout</code> to authenticate with the identity server. (#2255</a>)</li> Add endpoints for accepting and handling terms of service. (#2258</a>)</li> Add /hash_details</code> and a new /lookup</code> endpoint for performing hashed association lookups. (#2287</a>)</li> </ul> </li> Backwards Compatible Changes</p> Deprecate the v1 API in favour of an authenticated v2 API. (#2254</a>)</li> </ul> </li> </ul>

Matrix.org - Spec

Matrix v1.9 release

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> Client-Server API</h3> Backwards Compatible Changes</strong></p>

Client-Server API</h3> Backwards Compatible Changes</strong></p>

Server-Server API</h3> Spec Clarifications</strong></p>

Application Service API</h3> No significant changes.</p>

Identity Service API</h3> No significant changes.</p>

Push Gateway API</h3> No significant changes.</p>

Room Versions</h3> No significant changes.</p>

Appendices</h3> Spec Clarifications</strong></p>

Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p>

Matrix v1.8 release

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>

Client-Server API</h3> Backwards Compatible Changes</strong></p>

Server-Server API</h3> Deprecations</strong></p>

Application Service API</h3> Spec Clarifications</strong></p>

Identity Service API</h3> Spec Clarifications</strong></p>

Push Gateway API</h3> No significant changes.</p>

Room Versions</h3> Backwards Compatible Changes</strong></p>

Appendices</h3> Backwards Compatible Changes</strong></p>

Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p>

Matrix v1.7 release

Server-Server API</h3> Spec Clarifications</strong></p>

Application Service API</h3> New Endpoints</strong></p>

Identity Service API</h3> Spec Clarifications</strong></p>

Push Gateway API</h3> No significant changes.</p>

Room Versions</h3> Spec Clarifications</strong></p>

Appendices</h3> Spec Clarifications</strong></p>

Internal Changes/Tooling</h3> Spec Clarifications</strong></p>

Matrix v1.6 release

Server-Server API</h3> Breaking Changes</strong></p>

Application Service API</h3> Backwards Compatible Changes</strong></p>

Identity Service API</h3> Backwards Compatible Changes</strong></p>

Push Gateway API</h3> Backwards Compatible Changes</strong></p>

Room Versions</h3> Backwards Compatible Changes</strong></p>

Appendices</h3> No significant changes.</p>

Internal Changes/Tooling</h3> Spec Clarifications</strong></p>

Matrix v1.5 release

Server-Server API</h3> Spec Clarifications</strong></p>

Application Service API</h3> Spec Clarifications</strong></p>

Identity Service API</h3> Spec Clarifications</strong></p>

Push Gateway API</h3> No significant changes.</p>

Room Versions</h3> Spec Clarifications</strong></p>

Appendices</h3> No significant changes.</p>

Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p>

Matrix v1.4 release

Server-Server API</h3> Backwards Compatible Changes</strong></p>

Application Service API</h3> Breaking Changes</strong></p>

Identity Service API</h3> Spec Clarifications</strong></p>

Push Gateway API</h3> Spec Clarifications</strong></p>

Room Versions</h3> Spec Clarifications</strong></p>

Appendices</h3> No significant changes.</p>

Internal Changes/Tooling</h3> Backwards Compatible Changes</strong></p>

Matrix v1.3 release

Server-Server API</h3> Backwards Compatible Changes</strong></p>

Application Service API</h3> Backwards Compatible Changes</strong></p>

Identity Service API</h3> No significant changes.</p>

Push Gateway API</h3> No significant changes.</p>

Room Versions</h3> Backwards Compatible Changes</strong></p>

Appendices</h3> No significant changes.</p>

Matrix v1.2 release

Server-Server API</h3> New Endpoints</strong></p>

Application Service API</h3> Spec Clarifications</strong></p>

Identity Service API</h3> Backwards Compatible Changes</strong></p>

Push Gateway API</h3> Spec Clarifications</strong></p>

Room Versions</h3> Backwards Compatible Changes</strong></p>

Appendices</h3> Backwards Compatible Changes</strong></p>

Matrix v1.1 release

Server-Server API</h3> New Endpoints</strong></p>

Application Service API</h3> Spec Clarifications</strong></p>

Identity Service API</h3> New Endpoints</strong></p>

Push Gateway API</h3> Spec Clarifications</strong></p>

Room Version 6, Client-Server r0.6.1, and Federation r0.1.4 spec releases

Room Version 6, Client-Server r0.6.1, and Federation r0.1.4 spec releases</h2> Hey all,</p>

Client-Server r0.6.1 changelog</h3>

Server-Server (Federation) r0.1.4 changelog</h3>

Client-server r0.6.0 and Identity Service r0.3.0 releases

Application Service API</h3>
No significant changes.</p>

Identity Service API</h3>
No significant changes.</p>

Push Gateway API</h3>
No significant changes.</p>

Room Versions</h3>
No significant changes.</p>

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>

Push Gateway API</h3>
No significant changes.</p>

Push Gateway API</h3>
No significant changes.</p>

Appendices</h3>
No significant changes.</p>

Push Gateway API</h3>
No significant changes.</p>

Appendices</h3>
No significant changes.</p>

Appendices</h3>
No significant changes.</p>

Identity Service API</h3>
No significant changes.</p>

Push Gateway API</h3>
No significant changes.</p>

Appendices</h3>
No significant changes.</p>

Appendices</h3>
Backwards Compatible Changes</strong></p>
Describe "Common Namespaced Identifier Grammar" as per MSC2758</a>. (#3171</a>)</li>
Describe the `matrix:</code> URI scheme as per` `MSC2312</a>. (#3608</a>)</li> </ul>`

Push Gateway API</h3>
Spec Clarifications</strong></p>
Clarify where to get information about the various parameter values for the notify endpoint. (#2763</a>)</li> </ul>