Matrix 1.13 adds account suspension and room reporting features

Matrix 1.13 shipped nine new MSCs, marking the final scheduled release for 2024 before the next update lands around FOSDEM 2025. I see this version as a decisive step toward maturing the protocol’s safety and security architecture, moving beyond basic connectivity to address account management and content moderation with greater precision. The release closes gaps that have existed since the early days of the specification, providing server administrators with tools that were previously missing or ambiguous. For anyone running a homeserver, these changes are not just cosmetic; they alter how you handle user abuse and data integrity at the core level. The focus is clearly on stability and clarity, ensuring that independent implementations can rely on the spec without guessing at edge cases.

Account controls and reporting

The most significant addition is "Account Suspension," which complements the "Account Locking" feature introduced in the previous release. While locking prevents access entirely, often for security reasons, suspension aims to disrupt activity while retaining a mostly read-only experience for the user. Both actions are reversible, giving safety teams alternatives to deactivation, which remains a destructive and irreversible action. Clients must continue calling /sync to detect when a lock or suspension is lifted or converted to deactivation, ensuring users are informed of their status changes without manual intervention. This distinction matters because it allows servers to manage problematic accounts without immediately destroying user data, a nuance that previous versions lacked.

Event reporting has also been upgraded to fill a notable gap in functionality. Users could previously report specific events to their homeserver administrators, but they could not report whole rooms from the public room directory or out-of-band contexts. Matrix 1.13 addresses this with a new report room endpoint, allowing moderators to flag entire spaces rather than individual messages. The T&S team is currently designing a replacement for reporting in general, considering features like appeals and report-to-moderators flows. These improvements aim to reduce the burden on administrators by providing more structured ways to handle complaints. However, the current implementation still relies on manual review, which can be slow for large networks.

Spec clarifications and future outlook

Beyond security features, the release includes numerous clarifications and improvements to the existing specification. Error codes were added to requestToken endpoints per MSC4178, and reply fallbacks were removed per MSC2781. The allowed HTTP methods in CORS responses were clarified, and the M_USER_SUSPENDED error code behavior was defined. These changes ensure that developers implementing the API have a clear understanding of expected behaviors and error states. The removal of distinctions between StateFilter and RoomEventFilter simplifies the filtering logic, reducing complexity for client developers.

Looking ahead, Matrix 1.14 is expected to land around FOSDEM 2025 in early February. Many Matrix 2.0 features, such as OIDC and Simplified Sliding Sync, are approaching the proposed-FCP state needed to become part of the spec. We expect these features to land in either Matrix 1.14 or Matrix 1.15, potentially converting the applicable release to Matrix 2.0 as a specification version. This timeline is highly dependent on the MSCs progressing through FCP, so delays are possible. The Foundation continues to prioritize features based on community input, with an administrative break until January 8th, 2025. Will the transition to Matrix 2.0 happen smoothly, or will technical hurdles cause further delays?