Matrix.org - Releases

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> Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0 2023-03-28T00:00:00+00:00 Today we are issuing security releases of matrix-js-sdk and matrix-react-sdk to patch a pair of High severity vulnerabilities (CVE-2023-28427</a> / GHSA-mwq8-fjpf-c2gr</a> for matrix-js-sdk and CVE-2023-28103</a> / GHSA-6g43-88cp-w5gv</a> for matrix-react-sdk).</p> Affected clients include those which depend on the affected libraries, such as Element Web/Desktop and Cinny. Releases of the affected clients should follow shortly. We advise users of those clients to upgrade at their earliest convenience.</p> The issues involve prototype pollution via events containing special strings in key locations, which can temporarily disrupt normal functioning of matrix-js-sdk and matrix-react-sdk, potentially impacting the consumer's ability to process data safely.</p> Although we have only demonstrated a denial-of-service-style impact, we cannot completely rule out the possibility of a more severe impact due to the relatively extensive attack surface. We have therefore classified this as High severity and strongly recommend upgrading as a precautionary measure.</p> We found these issues during a codebase audit that we had previously announced</a> in an earlier security release of matrix-js-sdk and matrix-react-sdk. The earlier release had already addressed a set of similar vulnerabilities that were assigned CVE-2022-36059</a> / GHSA-rfv9-x7hh-xc32</a> and CVE-2022-36060</a> / GHSA-2x9c-qwgf-94xr</a>, which we had initially decided not to disclose until the completion of the audit. Now that the audit is finished, we are disclosing those previous advisories as well.</p> Synapse 1.78 released 2023-02-28T00:00:00+00:00 Greetings Matrix fans! We've published Synapse version 1.78</a> as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience. Please take a look at the upgrade notes</a> for any important information about upgrading.</p> </span> Announcements</h2> Please note that Synapse 1.78.0 replaces the /_synapse/admin/v1/media/<server_name>/delete</code> admin API with an identical endpoint at /_synapse/admin/v1/media/delete</code>. Please update your tooling to use the new endpoint. The deprecated version will be removed in a future release.</p> The new stuff</h2> In case you were unaware, Synapse has a command line export data command which allows administrators to export data for a specific user (you can read more about this command here</a>). Synapse 1.78.0 updates this command adding account data to the user information that is returned by the export data command.</p> This version of Synapse also features a few changes to push rules, with implementations for MSC3758</a>: Add event_property_is push</code> rule condition kind, MSC3966</a>: event_property_contains</code> push rule condition, and the removal of the spurious dont_notify</code> action from the defaults for the .m.rule.reaction</code> pushrule. These changes empower end users to more fully customise their notification rules - MSC3758 allows users to ask to be notified when a field in an event contains any type of value, rather than only matching on strings, and MSC3966 provides crucial scaffolding for MSC3952</a>: Intentional Mentions, which aims to eliminate unintentional mentions and improve the experience of mentions in general.</p> Synapse v1.78.0 includes some fixes for faster-joins related bugs as we work out the kinks. Some of these include a fix for a bug introduced in Synapse 1.76.0 where partially-joined rooms could not be deleted using the purge room API</a>, and a fix for a bug introduced in Synapse 1.75 where the portdb script</a> would fail to run after a room had been faster-joined. We continue to work to polish faster joins, and thank everyone who filed an issue.</p> Finally, for those deployments using workers, v1.78.0 fixed a bug introduced in Synapse 1.76 where 5s delays would occasionally occur.</p> Everything else</h2> See the full changelog</a> for a complete list of changes in the release. Also please have a look at the upgrade notes</a>.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order): jahway603, williamkray, 999lakhisidhu, hari01584, saddfox, dklimpel, realtyem V02460, and thezaidbintariq.</p> We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p> Synapse 1.77 released 2023-02-16T00:00:00+00:00 Greetings Matrix fans! We've published Synapse version 1.77</a> as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience.</p> </span> The new stuff</h2> Experimental support for intentional mentions (MSC3952)</h3> Mentioning other users on Matrix is difficult: it is not possible to know if mentioning a user by display name or Matrix ID will count as a mention, but is also too easy to mistakenly mention a user.</p> MSC3952</a> proposes a solution. Its idea is to make the mentioning explicit in the protocol using a dedicated event property, instead of relying on searching the body of the message as before.</p> Synapse now implements this as an experimental feature.</p> Experimental support to suppress notifications from message edits (MSC3958)</h3> Have you ever been annoyed by a noisy notification that keep coming back, but you can't pinpoint where it's coming from? This is usually because edits to a message where you are mentioned (or that mention @room</code>) will retrigger a noisy notification. That can be pretty annoying when the message is edited 10 times!</p> MSC3958</a> is here to solve that, and Synapse now implements it as an experimental feature.</p> The quest for speed continues!</h3> Some iterative optimizations have been implemented that should make joining or leaving</a> large rooms even faster, and should also improve sending message</a>.</p> Everything else</h2> See the full changelog</a>, for a complete list of changes in the release.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to these releases, including (in no particular order) icp1994, dklimpel, Fizzadar and realtyem.</p> We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p> 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> Synapse 1.76 released 2023-01-31T00:00:00+00:00 Greetings Matrix fans! We've published Synapse version 1.76</a> as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience. Please take a look at the upgrade notes</a> for any important information about upgrading.</p> </span> Announcements</h2> The big news is that faster joins for all has arrived! When joining a room for the first time, Synapse 1.76.0 will request a partial join from the other server by default. Previously, server admins had to opt-in to this using an experimental config flag.</p> Server admins can opt out of this feature for the time being by setting</p> experimental: </span> faster_joins: false </span></code></pre> in their server config.</p> For everyone else, after a faster join Synapse considers that room "partially joined". In this state, you should be able to</p> read incoming messages (on clients which support lazy-loaded members in /sync);</li> see incoming state changes, e.g. room topic changes; and</li> send messages, if the room is unencrypted.</li> </ul> Synapse has to spend more effort to complete the join in the background. Once this finishes, you will be able to</p> send messages, if the room is encrypted;</li> retrieve room history from before your join, if permitted by the room settings; and</li> access the full list of room members.</li> </ul> Practically, this means that the experience of joining a large room over federation should be greatly improved. In past versions of Synapse, joining a large room such as Matrix HQ over federation could take up to 30 mins. This time has been cut to ~20-30 seconds to partially join in the new release. Those of you who have been watching this know this has been a huge undertaking, big shout out to the team for getting it over the line! We're excited the community to try it, as always if you encounter any problems you are encouraged to file an issue</a>.</p> Changes to the account data replication streams</h3> Please note that Synapse has changed the format of the account data and devices replication streams (between workers). This is a forwards- and backwards-incompatible change: v1.75 workers cannot process account data replicated by v1.76 workers, and vice versa.</p> Once all workers are upgraded to v1.76 (or downgraded to v1.75), account data and device replication will resume as normal.</p> The new stuff</h2> The default room version has now been updated to v10</a></h3> Room version 10 is now the default room version in Synapse 1.76.0. This room version builds on v9 to introduce a new knock_restricted</code> join rule, allowing prospective members to more easily join such a room. The knock_restricted</code> join rule allows for prospective members of a room to join either through knocking or through join_restrictions</code>, which allows prospective members to join a restricted room based on whether they are a joined member of another room. You can read more about restricted rooms here</a>.</p> Synapse now implements experimental support for MSC3930</a> Push rules for Polls</h3> Synapse has added some new, default push rules for MSC3881</a>-esque event types.</p> This allows for notifications from polls, ie when a poll starts or ends.</p> Everything else</h2> See the full changelog</a>, for a complete list of changes in the release.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to these releases, including: katlol, thezaidbintariq, dklimpel, FSG-Cat, tjay27, emgrav, villepeh.</p> We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p> Synapse 1.75 released 2023-01-19T15:38:49+00:00 We published Synapse version 1.75</a> as the new stable release this week. Synapse admins are encouraged to upgrade to it at their convenience. It seems like the blog post for version 1.74</a> was eaten by Santa's reindeer, so this post will also cover changes from it.</p> </span> Announcements</h2> There were no special announcements for the 1.75 release.</p> Synapse 1.74: ICU dependency for improved user search</h3> Synapse's search functionality has long been poor when searching for non-English terms. Synapse 1.74 introduced</a> support for an optional improved user search experience which has a better awareness of Unicode. To do so, we use the ICU library</a> when Synapse is installed alongside the binding library PyICU</a>.</p> Synapse installations using Matrix.org docker images or debian packages will automatically have the new search mode enabled.</p> From-source installations will need to include the user-search</code> extra when pip install</code> Synapse, e.g. pip install matrix-synapse[user-search]</code>. NB:</strong> because PyICU is not distributed as source-only on PyPI, you will need to ensure the ICU development headers are available on your system. See the upgrade notes</a> for more info.</p> Please try out the new search mode and let us know how you find it in practice.</p> The new stuff</h2> Support RFC7636</a> Proof Key for Code Exchange for OAuth single sign-on</h3> Synapse 1.75 adds support for RFC7636 code challenges in the OAuth 2.0 flow.</p> This is required by Twitter SSO and enabling it can protect against the "authorization code interception attack".</p> Experimental support for removing account data (MSC3391</a>)</h3> Experimental support for removing account data has landed in Synapse. It was previously possible to create or update account data but not remove them, this is now possible.</p> The support is experimental and needs to be enabled with a configuration flag since the MSC hasn't landed yet.</p> More faster remote room joins fixes and improvements</h3> In case you missed it we are working on dramatically improve performance of remote room joins, you can refer to this blog post</a> for more details.</p> The last two Synapse releases brings that a lot closer to a proper release; in particular they contain a lot of work to support faster joins in deployments with multiple workers. The project continues in earnest; we hope to have more to show off in the coming weeks.</p> Everything else</h2> See the full changelog</a>, for a complete list of changes in the release. Also please have a look at the upgrade notes</a> for 1.74 version.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to these releases, including (in no particular order): Ashish Kumar, Dirk Klimpel, Jeremy Kescher, Jeyachandran Rathnam, Nick Mills-Barrett, Jason Little, Villepeh and Vertux. We are also grateful to anyone helping us make Synapse better by sharing their feedback and reporting issues, or helping with community support questions.</p> Synapse 1.73 released 2022-12-07T00:00:00+00:00 And here is another update to your beloved Matrix homeserver implementation, Synapse 1.73</a>.</p> Announcements</h2> Legacy Prometheus metric names removed</h3> When releasing Synapse 1.69</a> a couple of months ago, we also announced the removal of old Prometheus metrics that have been replaced by more aptly named ones. he list of these metrics can be found here</a>.</p> Synapse 1.73 implements the final phase of this plan and entirely removes support for those metrics. As a result, the enable_legacy_metrics</code> configuration option, which was introduced in Synapse 1.71</a>, has also been removed.</p> Server administrators who are still relying on these legacy metric names are encouraged to update their dashboards at their earliest convenience. For more information, please refer to the upgrade notes</a>.</p> The new stuff</h2> Performance</h3> A bunch of performance improvements have been included in this release, specifically around the /messages</code></a> endpoint.</p> Improvements to event filtering on the client-server API</a> gave the matrix.org homeserver a first nice bump as visible on this graph:</p> </p> Various optimizations around fetching</a> bundled</a> aggregations</a> resulted in yet another nice improvement:</p> </a></p> Note that the graph from the first image, and the second graph from the second image are apdexes</a>, which is a measure that shows improvement when it goes up (as opposed to e.g. response times, which improve when they go down).</p> Extensible Events experimental support</h3> Experimental support for Extensible Events has landed in Synapse.</p> This is exciting since this global rework of events presentation has been in talks for a while</a>, and having an implementation to experiment with greatly helps bringing the feature closer to completion.</p> Note that this support is still very much experimental as the related MSCs are still under review and could change at any time, and therefore not recommended for use in production.</p> Everything else</h2> See the full changelog</a>, for a complete list of changes in the release. Also please have a look at the upgrade notes</a> for this version.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) schmop</a>, Ashish Kumar</a>, realtyem</a>, and Brennan Chapman</a> as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.</p> Synapse 1.72 released 2022-11-22T00:00:00+00:00 It's not Christmas yet, but it's time for a new release! Say hello to Synapse 1.72</a>.</p> It seems like this blog didn't self update through AI for the 2 preceding updates so this post will cover 1.70 to 1.72, sorry if this is a bit long but it's been a while :)</p> Announcements</h2> Dropping support for PostgreSQL 10</h3> PostgreSQL 10 has reached End Of Life: Synapse will no longer support it beginning with version 1.72 so please upgrade your database if you have not already done so.</p> Legacy Prometheus metric names disabled and to be removed</h3> In previous versions of Synapse, some Prometheus metrics were emitted under two different names, an older name that was non-compliant with OpenMetrics and Prometheus conventions and a new compliant name.</p> Synapse 1.71 and later have the old metric names switched off by default.</p> For now it's still possible to get them by using enable_legacy_metrics: true</code>, however server administrators still using legacy metric names are highly encouraged to migrate, as they will be removed in 1.73.</p> You can find the full list of renamed metrics here</a>.</p> Changes to the events received by application services (interest)</h3> Following the implementation of MSC3905</a>, Synapse now only considers local users to be interesting to application services. In other words, the users namespace regex in an app service's registration file is only applied against local users of the homeserver.</p> Please note, this probably doesn't affect the expected behavior of your application service, since an interesting local user in a room still means all messages in the room (from local or remote users) will still be considered interesting.</p> You can find a bit more info in the MSC and in the upgrade notes</a>.</p> The new stuff</h2> Threads, threads, threads!</h3> Several MSCs related to threads got implemented:</p> MSC3856</a> provide an API to fetch threads and related metadata.</li> MSC3771</a> and MSC3773</a> implementing per thread read receipts and per thread notification counts.</li> MSC3874</a> allows to filter out messages belonging to threads from the main timeline (still considered experimental). Along with MSC3856, this should noticeably improve performance of rooms that use threads heavily.</li> </ul> This should significantly improve user experience related to threads, being through behavior or performance impact.</p> Linking events together</h3> Relationships are great, even more between events than humans!</p> MSC3664</a> allows Matrix clients to be notified in real time of related events, so you can now be made quickly aware of this cat emoji reaction that your cat photo clearly deserved.</p> Additionally, Synapse 1.72 includes an implementation of MSC3912</a>, allowing users to redact the relations of a message alongside the message itself. This is particularly helpful in cases like edits, where users usually want to see their edits redacted at the same time as the original message. Note that this implementation is currently incomplete and still experimental, though, so watch this space!</p> Faster joins, continued</h3> We continue our journey to get everything going as transparently as possible when doing fast remote room joins.</p> If you missed it you can refer to this previous blog post</a> to get a lot more infos, and feel free to grep Synapse changelog and the numerous related issues/PRs for all the gory details.</p> Everything else</h2> See the full changelogs (1.70</a>, 1.71</a>, 1.72</a>) for a complete list of changes in the releases. Also please have a look at the upgrade notes</a> for this version.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Nico</a>, sando38</a>, realtyem</a>, aceArt GmbH</a>, Tuomas Ojamies</a>, Ashish Kumar</a>, asymmetric</a>, Beeper</a>, Ryan Miguel</a>, Paul Tötterman</a>, Abdullah Osama</a>, Finn</a>, Ivan Shapovalov</a>, Dirk Klimpel</a>, Jonathan de Jong</a>, MichaIng</a> and Aaron Raimist</a> as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.</p> 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> Synapse 1.69 released 2022-10-17T18:52:11+00:00 Hey everyone, it's time for a new Synapse release! Synapse 1.69</a> is out, fresh out of the oven. But before we take a look at it, here's a quick announcement:</p> We have recently disclosed a moderate severity security vulnerability, which was fixed in Synapse 1.62</a> (released on July 5th 2022). This issue affects all homeservers running a version of Synapse older than 1.62 with open federation. If this is the case for your deployment, please update to a more recent version of Synapse at your earliest convenience.</p> See advisory GHSA-jhjh-776m-4765</a> and CVE-2022-31152</a> for more information.</p> </blockquote> Now let's see what's new in Synapse 1.69!</p> </span> Caching in modules</h2> Synapse modules allow third-party developers to extend Synapse's feature range to include very custom features.</p> Synapse 1.69 includes tools modules can use to interact with Synapse's caching system, which includes features such as synchronising caches across multiple Synapse workers.</p> Starting with this version, modules can import the @cache()</code> decorator from synapse.module_api</code>, to decorate functions which results must be cached. Cached functions need to be registered with ModuleApi.register_cached_function</code></a> at the module's initialisation. Invalidating a cached function's result for a given set of arguments can be done using ModuleApi.invalidate_cache</code></a>.</p> Upcoming removal of deprecated Prometheus metric names</h2> Back in Synapse 1.2</a>, we deprecated a number of Prometheus metrics, to replace them with more aptly named equivalents that fit existing naming conventions better.</p> With Synapse 1.69, we're announcing the plan for the removal for these deprecated metrics. Synapse 1.71 (due to be released on November 8) will turn these metrics off by default (though it will still be possible to enable them back). Synapse 1.73 (due to be released on November 22) will remove them altogether.</p> Server administrators using metrics dashboards that rely on the deprecated metrics are encouraged to update their dashboards with the new metric names. See the upgrade notes</a> for more information.</p> Everything else</h2> Synapse 1.69 also deprecates the generate_short_term_login_token</code> module API method in favour of the asynchronous create_login_token</code> one. The deprecated method will be removed in Synapse 1.71. See the upgrade notes</a> for more information.</p> Additionally, Synapse 1.69 introduces a forwards- and backwards-incompatible change to the replication of read receipts. This means that read receipts replicated by workers running Synapse 1.68 will not be able to be processed by workers running Synapse 1.69 and vice-versa. Once all workers are made to run Synapse 1.69 (or 1.68), replication of read receipts will resume as normal. See the upgrade notes</a> for more information.</p> See the full changelog</a> for a complete list of changes in this release. Also please have a look at the upgrade notes</a> for this version.</p> Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) lukasdenk</a>, Dirk Klimpel</a>, Ashish Kumar</a>, Famedly</a> and Beeper</a>, as well as anyone helping us make Synapse better by sharing their feedback and reporting issues.</p> 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> Announcing Third Room Tech Preview 1 2022-09-27T17:53:52+00:00 We're excited to announce the first tech preview of Third Room</a>, an open, standards-based, decentralised vision of the metaverse for the open Web, built entirely on Matrix… without cryptocurrencies, NFTs or walled gardens.</p> To see what it's all about, head over to https://thirdroom.io/preview</a> - or come chat in #thirdroom-dev:matrix.org</a> to learn more!</p>

Matrix.org - Releases

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>

Security releases: matrix-js-sdk 24.0.0 and matrix-react-sdk 3.69.0

Synapse 1.78 released

Synapse 1.77 released

Experimental support for intentional mentions (MSC3952)</h3> Mentioning other users on Matrix is difficult: it is not possible to know if mentioning a user by display name or Matrix ID will count as a mention, but is also too easy to mistakenly mention a user.</p>

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>

Synapse 1.76 released

The new stuff</h2>

Synapse 1.75 released

Synapse 1.73 released

Synapse 1.72 released

Dropping support for PostgreSQL 10</h3> PostgreSQL 10 has reached End Of Life: Synapse will no longer support it beginning with version 1.72 so please upgrade your database if you have not already done so.</p>

The new stuff</h2> Threads, threads, threads!</h3> Several MSCs related to threads got implemented:</p>

Threads, threads, threads!</h3> Several MSCs related to threads got implemented:</p>

Linking events together</h3> Relationships are great, even more between events than humans!</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>

Synapse 1.69 released

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>

Announcing Third Room Tech Preview 1

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>

Dropping support for PostgreSQL 10</h3>
PostgreSQL 10 has reached End Of Life: Synapse will no longer support it beginning with version 1.72 so please upgrade your database if you have not already done so.</p>

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

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

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