You're looking at an unstable version of this specification. Unstable specifications may change at any time without notice.

Switch to the current stable release.

Spec Change Proposals

If you are interested in submitting a change to the Matrix Specification, please take note of the following guidelines.

Most changes to the Specification require a formal proposal. Bug fixes, typos, and clarifications to existing behaviour do not need proposals - see the contributing guide for more information on what does and does not need a proposal.

The proposal process involves some technical writing, having it reviewed by everyone, having the proposal being accepted, then actually having your ideas implemented as committed changes to the Specification repository.

Meet the members of the Core Team, a group of individuals tasked with ensuring the spec process is as smooth and painless as possible. Members of the Spec Core Team will do their best to participate in discussion, summarise when things become long-winded, and generally try to act towards the benefit of everyone. As a majority, team members have the ability to change the state of a proposal, and individually have the final say in proposal discussion.

Guiding Principles

Proposals must act to the greater benefit of the entire Matrix ecosystem, rather than benefiting or privileging any single player or subset of players -and must not contain any patent encumbered intellectual property. Members of the Core Team pledge to act as a neutral custodian for Matrix on behalf of the whole ecosystem.

For clarity: the Matrix ecosystem is anyone who uses the Matrix protocol. That includes client users, server admins, client developers, bot developers, bridge and application service developers, users and admins who are indirectly using Matrix via 3rd party networks which happen to be bridged, server developers, room moderators and admins, companies/projects building products or services on Matrix, spec contributors, translators, and those who created it in the first place.

“Greater benefit” could include maximising:

  • the number of end-users reachable on the open Matrix network
  • the number of regular users on the Matrix network (e.g. 30-day retained federated users)
  • the number of online servers in the open federation
  • the number of developers building on Matrix
  • the number of independent implementations which use Matrix
  • the number of bridged end-users reachable on the open Matrix network
  • the signal-to-noise ratio of the content on the open Matrix network (i.e. minimising spam)
  • the ability for users to discover content on their terms (empowering them to select what to see and what not to see)
  • the quality and utility of the Matrix spec (as defined by ease and ability with which a developer can implement spec-compliant clients, servers, bots, bridges, and other integrations without needing to refer to any other external material)

In addition, proposal authors are expected to uphold the following values in their proposed changes to the Matrix protocol:

  • Supporting the whole long-term ecosystem rather than individual stakeholder gain
  • Openness rather than proprietary lock-in
  • Interoperability rather than fragmentation
  • Cross-platform rather than platform-specific
  • Collaboration rather than competition
  • Accessibility rather than elitism
  • Transparency rather than stealth
  • Empathy rather than contrariness
  • Pragmatism rather than perfection
  • Proof rather than conjecture

Please see MSC1779 for full details of the project’s Guiding Principles.

Technical notes

Proposals must develop Matrix as a layered protocol: with new features building on layers of shared abstractions rather than introducing tight vertical coupling within the stack. This ensures that new features can evolve rapidly by building on existing layers and swapping out old features without impacting the rest of the stack or requiring substantial upgrades to the whole ecosystem. This is critical for Matrix to rapidly evolve and compete effectively with centralised systems, despite being a federated protocol.

For instance, new features should be implemented using the highest layer abstractions possible (e.g. new event types, which layer on top of the existing room semantics, and so don’t even require any API changes). Failing that, the next recourse would be backwards-compatible changes to the next layer down (e.g. room APIs); failing that, considering changes to the format of events or the DAG; etc. It would be a very unusual feature which doesn’t build on the existing infrastructure provided by the spec and instead created new primitives or low level APIs.

Backwards compatibility is very important for Matrix, but not at the expense of hindering the protocol’s evolution. Backwards incompatible changes to endpoints are allowed when no other alternative exists, and must be versioned under a new major release of the API. Backwards incompatible changes to the room algorithm are also allowed when no other alternative exists, and must be versioned under a new version of the room algorithm.

There is sometimes a dilemma over where to include higher level features: for instance, should video conferencing be formalised in the spec, or should it be implemented via widgets? Should reputation systems be specified? Should search engine behaviour be specified?

There is no universal answer to this, but the following guidelines should be applied:

  1. If the feature would benefit the whole Matrix ecosystem and is aligned with the guiding principles above, then it should be supported by the spec.
  2. If the spec already makes the feature possible without changing any of the implementations and spec, then it may not need to be added to the spec.
  3. However, if the best user experience for a feature does require custom implementation behaviour then the behaviour should be defined in the spec such that all implementations may implement it.
  4. However, the spec must never add dependencies on unspecified/nonstandardised 3rd party behaviour.

As a worked example:

  1. Video conferencing is clearly a feature which would benefit the whole ecosystem, and so the spec should find a way to make it happen.
  2. Video conferencing can be achieved by widgets without requiring any compulsory changes to clients nor servers to work, and so could be omitted from the spec.
  3. A better experience could be achieved by embedding Jitsi natively into clients rather than using a widget…
  4. …except that would add a dependency on unspecified/nonstandardised 3rd party behaviour, so must not be added to the spec.

Therefore, our two options in the specific case of video conferencing are either to spec SFU conferencing semantics for WebRTC (or refer to an existing spec for doing so), or to keep it as a widget-based approach (optionally with widget extensions specific for more deeply integrating video conferencing use cases).

As an alternative example: it’s very unlikely that “how to visualise Magnetic Resonance Imaging data over Matrix” would ever be added to the Matrix spec (other than perhaps a custom event type in a wider standardised Matrix event registry) given that the spec’s existing primitives of file transfer and extensible events (MSC1767) give excellent tools for transferring and visualising arbitrary rich data.

Supporting public search engines are likely to not require custom spec features (other than possibly better bulk access APIs), given they can be implemented as clients using the existing CS API. An exception could be API features required by decentralised search infrastructure (avoiding centralisation of power by a centralised search engine).

Features such as reactions, threaded messages, editable messages, spam/abuse/content filtering (and reputation systems), are all features which would clearly benefit the whole Matrix ecosystem, and cannot be implemented in an interoperable way using the current spec; so they necessitate a spec change.

Process

The process for submitting a Matrix Spec Change (MSC) Proposal in detail is as follows:

  • Create a first draft of your proposal using GitHub-flavored Markdown
    • In the document, clearly state the problem being solved, and the possible solutions being proposed for solving it and their respective trade-offs.
    • Proposal documents are intended to be as lightweight and flexible as the author desires; there is no formal template; the intention is to iterate as quickly as possible to get to a good design.
    • However, a template with suggested headers is available to get you started if necessary.
    • Take care in creating your proposal. Specify your intended changes, and give reasoning to back them up. Changes without justification will likely be poorly received by the community.
    • At the time of creating your draft you will not yet know the PR number, so you should use a placeholder number to name your file and edit that after PR submission. The suggested steps are described in detail in the proposals guide.
  • Fork and make a PR to the matrix-spec-proposals repository. The ID of your PR will become the MSC ID for the lifetime of your proposal.
    • The proposal must live in the proposals/ directory with a filename that follows the format 1234-my-new-proposal.md where 1234 is the MSC ID.
    • Your PR description must include a link to the rendered Markdown document and a summary of the proposal.
    • It is often very helpful to link any related MSCs or matrix-spec issues to give context for the proposal.
    • Additionally, please be sure to sign off your proposal PR as per the guidelines listed on CONTRIBUTING.rst.
  • Gather feedback as widely as possible.
    • The aim is to get maximum consensus towards an optimal solution. Sometimes trade-offs are required to meet this goal. Decisions should be made to the benefit of all major use cases.
    • A good place to ask for feedback on a specific proposal is #matrix-spec:matrix.org. If preferred, an alternative room can be created and advertised in #matrix-spec:matrix.org. Please also link to the room in your PR description.
    • For additional discussion areas, know that #matrix-dev:matrix.org is for developers using existing Matrix APIs, #matrix:matrix.org is for users trying to run Matrix apps (clients & servers) and #matrix-architecture:matrix.org is for cross-cutting discussion of Matrix’s architectural design.
    • The point of the spec proposal process is to be collaborative rather than competitive, and to try to solve the problem in question with the optimal set of trade-offs. The author should neutrally gather the various viewpoints and get consensus, but this can sometimes be time-consuming (or the author may be biased), in which case an impartial ‘shepherd’ can be assigned to help guide the proposal through this process instead. A shepherd is typically a neutral party from the Spec Core Team or an experienced member of the community. There is no formal process for assignment. Simply ask for a shepherd to help get your proposal through and one will be assigned based on availability. Having a shepherd is not a requirement for proposal acceptance.
  • Members of the Spec Core Team and community will review and discuss the PR in the comments and in relevant rooms on Matrix. Discussion outside of GitHub should be summarised in a comment on the PR.
  • When a member of the Spec Core Team believes that no new discussion points are being made, and the proposal has suitable evidence of working (see implementing a proposal below), they will propose a motion for a final comment period (FCP), along with a disposition of either merge, close or postpone. This FCP is provided to allow a short period of time for any invested party to provide a final objection before a major decision is made. If sufficient reasoning is given, an FCP can be cancelled. It is often preceded by a comment summarising the current state of the discussion, along with reasoning for its occurrence.
  • A concern can be raised by a Spec Core Team member at any time, which will block an FCP from beginning. An FCP will only begin when 75% of the members of the Spec Core Team agree on its outcome, and all existing concerns have been resolved.
  • The FCP will then begin and last for 5 days, giving anyone else some time to speak up before it concludes. If sufficient reasoning against the disposition is provided, a member of the Spec Core Team can raise a concern and block FCP from completing. This will not reset or pause the 5 day FCP timer, but FCP will not conclude until all concerns have been resolved. If sufficient change in the MSC is required to resolve those concerns, FCP might be cancelled and reproposed. Once FCP has concluded, the disposition of the FCP will be carried out.
  • Once the proposal has been accepted and merged, it is time to submit the actual change to the Specification that your proposal reasoned about. This is known as a spec PR. However in order for the spec PR to be accepted, an implementation must be shown to prove that it works well in practice. A link to the implementation should be included in the PR description. In addition, any significant unforeseen changes to the original idea found during this process will warrant another MSC. Any minor, non-fundamental changes are allowed but must be documented in the original proposal document. This ensures that someone reading a proposal in the future doesn’t assume old information that wasn’t merged into the spec.
    • Similar to the proposal PR, please sign off the spec PR as per the guidelines on CONTRIBUTING.rst.
  • Your PR will then be reviewed and hopefully merged on the grounds it is implemented sufficiently. If so, then give yourself a pat on the back knowing you’ve contributed to the Matrix protocol for the benefit of users and developers alike :)

The process for handling proposals is shown visually in the following diagram. Note that the lifetime of a proposal is tracked through the corresponding labels for each stage on the matrix-spec-proposals pull request trackers.

                           +                          +
         Proposals         |          Spec PRs        |  Additional States
         +-------+         |          +------+        |  +---------------+
                           |                          |
 +----------------------+  |         +---------+      |    +-----------+
 |                      |  |         |         |      |    |           |
 |      Proposal        |  |  +------= Spec PR |      |    | Postponed |
 | Drafting and Initial |  |  |      | Missing |      |    |           |
 |  Feedback Gathering  |  |  |      |         |      |    +-----------+
 |                      |  |  |      +----+----+      |
 +----------+-----------+  |  |           |           |    +----------+
            |              |  |           v           |    |          |
            v              |  |  +-----------------+  |    |  Closed  |
  +-------------------+    |  |  |                 |  |    |          |
  |                   |    |  |  | Spec PR Created |  |    +----------+
  |    Proposal PR    |    |  |  |  and In Review  |  |
  |     In Review     |    |  |  |                 |  |
  |                   |    |  |  +--------+--------+  |
  +---------+---------+    |  |           |           |
            |              |  |           v           |
            v              |  |     +-----------+     |
 +----------------------+  |  |     |           |     |
 |                      |  |  |     |  Spec PR  |     |
 |    Proposed Final    |  |  |     |  Merged!  |     |
 |    Comment Period    |  |  |     |           |     |
 |                      |  |  |     +-----------+     |
 +----------+-----------+  |  |                       |
            |              |  |                       |
            v              |  |                       |
 +----------------------+  |  |                       |
 |                      |  |  |                       |
 | Final Comment Period |  |  |                       |
 |                      |  |  |                       |
 +----------+-----------+  |  |                       |
            |              |  |                       |
            v              |  |                       |
 +----------------------+  |  |                       |
 |                      |  |  |                       |
 | Final Comment Period |  |  |                       |
 |       Complete       |  |  |                       |
 |                      |  |  |                       |
 +----------+-----------+  |  |                       |
            |              |  |                       |
            +-----------------+                       |
                           |                          |
                           +                          +

Lifetime States

Note: All labels are to be placed on the proposal PR.

Name GitHub Label Description
Proposal Drafting and Feedback Draft pull request A proposal document which is still work-in-progress but is being shared to incorporate feedback. Please prefix your proposal’s title with [WIP] to make it easier for reviewers to skim their notifications list.
Proposal In Review No label A proposal document which is now ready and waiting for review by the Spec Core Team and community
Proposed Final Comment Period proposed-final-comment-period Currently awaiting signoff of a 75% majority of team members in order to enter the final comment period
Final Comment Period final-comment-period A proposal document which has reached final comment period either for merge, closure or postponement
Final Comment Period Complete finished-final-comment-period The final comment period has been completed. Waiting for a demonstration implementation
Spec PR Missing spec-pr-missing The proposal has been agreed, and proven with a demonstration implementation. Waiting for a PR against the Spec
Spec PR In Review spec-pr-in-review The spec PR has been written, and is currently under review
Spec PR Merged merged A proposal with a sufficient working implementation and whose Spec PR has been merged!
Postponed proposal-postponed A proposal that is temporarily blocked or a feature that may not be useful currently but perhaps sometime in the future
Abandoned abandoned A proposal where the author/shepherd is not responsive
Obsolete obsolete A proposal which has been made obsolete by another proposal or decision elsewhere.

Categories

We use category labels on MSCs to place them into a track of work. The Spec Core Team decides which of the tracks they are focusing on for the next while and generally makes an effort to pull MSCs out of that category when possible.

The current categories are:

Name GitHub Label Description
Core kind:core Important for the protocol’s success.
Feature kind:feature Nice to have additions to the spec.
Maintenance kind:maintenance Fixes or clarifies existing spec.

Some examples of core MSCs would be aggregations, cross-signing, and groups/communities. These are the sorts of things that if not implemented could cause the protocol to fail or become second-class. Features would be areas like enhanced media APIs, new transports, and bookmarks in comparison. Finally, maintenance MSCs would include improving error codes, clarifying what is required of an API, and adding properties to an API which makes it easier to use.

The Spec Core Team assigns a category to each MSC based on the descriptions above. This can mean that new MSCs get categorized into an area the team isn’t focused on, though that can always change as priorities evolve. We still encourage that MSCs be opened, even if not the focus for the time being, as they can still make progress and even be merged without the Spec Core Team focusing on them specifically.

Implementing a proposal

As part of the proposal process the Spec Core Team will require evidence of the MSC working in order for it to move into FCP. This can usually be a branch/pull request to whichever implementation of choice that proves the MSC works in practice, though in some cases the MSC itself will be small enough to be considered proven. Implementations do not need to be merged or released, but must be of sufficient quality to show that the MSC works. Where it’s unclear if an MSC will require an implementation proof, ask in #matrix-spec:matrix.org. Proposals may require both server-side and client-side implementations.

Proposals that have not yet been implemented will have the needs-implementation label. After an implementation has been made, add a comment in the GitHub issue indicating so. After an implementation has been made, we will check it to verify that it implements the MSC. Proposals that have implementations that have not yet been checked will have the implementation-needs-checking label.

Early release of an MSC/idea

To help facilitate early releases of software dependent on a spec release, implementations are required to use the following process to ensure that the official Matrix namespace is not cluttered with development or testing data.

Note: Unreleased implementations (including proofs-of-concept demonstrating that a particular MSC works) do not have to follow this process.

  1. Have an idea for a feature.
  2. Implement the feature using unstable endpoints, vendor prefixes, and unstable feature flags as appropriate.
  3. In parallel, or ahead of implementation, open an MSC and solicit review per above.
  4. Before FCP can be called, the Spec Core Team will require evidence of the MSC working as proposed. A typical example of this is an implementation of the MSC, though the implementation does not need to be shipped anywhere and can therefore avoid the forwards/backwards compatibility concerns mentioned here.
  5. The FCP process is completed, and assuming nothing is flagged the MSC lands.
  6. Implementations can now switch to using stable prefixes, assuming that the change is backwards compatible with older implementations. In the rare occasion where backwards compatibility is not possible without a new spec release, implementations should continue to use unstable prefixes.
  7. A spec PR is written to incorporate the changes into Matrix.
  8. A spec release happens.
  9. A transition period of about 2 months starts immediately after the spec release, before implementations start to encourage other implementations to switch to stable endpoints. For example, a server implementation should start asking client implementations to support the stable endpoints 2 months after the spec release, if they haven’t already. The same applies in the reverse: if clients cannot switch to stable prefixes because server implementations haven’t started supporting the new spec release, some noise should be raised in the general direction of the implementation.

In summary:

  • Implementations MUST NOT use stable endpoints before the MSC has completed FCP. Once that has occurred, implementations are allowed to use stable endpoints, but are not required to.
  • Implementations are able to ship features that are exposed to users by default before an MSC has been merged to the spec, provided they follow the process above.
  • Implementations SHOULD be wary of the technical debt they are incurring by moving faster than the spec.
  • The vendor prefix is chosen by the developer of the feature, using the Java package naming convention.
  • The vendor prefixes, unstable feature flags, and unstable endpoints should be included in the MSC, though the MSC MUST be written in a way that proposes new stable endpoints. Typically this is solved by a small table at the bottom mapping the various values from stable to unstable.

Unstable endpoints, features and vendor prefixes

Unstable endpoints MUST use /unstable as the endpoint version and a vendor prefix in Java package naming format. For example: /_matrix/client/unstable/com.example.mscxxxx/login.

Proposal authors operating with a Matrix.org Foundation mandate SHOULD use a vendor prefix within the org.matrix namespace. This namespace is otherwise restricted. Authors who don’t own a domain MAY use the io.github namespace instead.

Note that unstable namespaces do not automatically inherit endpoints from stable namespaces: for example, the fact that /_matrix/client/v3/sync exists does not imply that /_matrix/client/unstable/com.example.mscxxxx/sync exists.

Vendor prefixes MUST also be used for:

  • New parameters on existing endpoints. For example: /_matrix/client/v3/publicRooms?com.example.mscxxxx.ordered_by=member_count.

  • New properties in existing JSON objects. For example:

    {
  "avatar_url": "mxc://matrix.org/SDGdghriugerRg",
  "displayname": "Alice Margatroid",
  "com.example.mscxxxx.phone": [{
    "type": "landline",
    "number": "+1-206-555-7000"
  }],
  ...
}

  • New values for existing parameters or properties. For example:

    {
  "errcode": "COM.EXAMPLE.MSCXXXX.M_INVALID_EMAIL",
  "error": "The email address you provided is invalid."
}

If the client needs to be sure the server supports the feature, an unstable feature flag that MUST also be vendor prefixed is to be used. This flag shows up in the unstable_features section of /_matrix/client/versions as, for example, com.example.mscxxxx.new_login.

MSCs MUST still describe what the stable endpoints/feature looks like with a note towards the bottom for what the unstable feature flag/prefixes are. For example, an MSC would propose /_matrix/client/v1/new/endpoint, not /_matrix/client/unstable/com.example.mscxxxx/new/endpoint.

When using this approach correctly, the implementation can release the feature at any time, so long as the implementation is able to accept the technical debt that results from needing to provide adequate backwards and forwards compatibility. The implementation MUST support the flag (and server-side implementation) disappearing and be generally safe for users. Note that implementations early in the MSC review process may also be required to provide backwards compatibility with earlier editions of the proposal.

If the implementation cannot support the technical debt (or if it’s impossible to provide forwards/backwards compatibility - e.g. a user authentication change which can’t be safely rolled back), the implementation should not attempt to implement the feature and should instead wait for a spec release.

If at any point after early release, the idea changes in a backwards-incompatible way, the feature flag should also change so that implementations can adapt as needed.

Placeholder MSCs

Some proposals may contain security-sensitive or private context which can’t be publicly disclosed until a later stage in the idea or solution process. Typically, the initial idea is validated using some amount of implementation or experimentation and may require an MSC number to make that implementation easier.

Placeholder MSCs are used to represent proposals in a state where implementation is ongoing, but the MSC details can’t yet be disclosed. Authors which feel as though their MSC could be highly sensitive MUST get in contact with the Spec Core Team or Security Team prior to opening their MSC. If either team determines that a placeholder MSC is required, it may be opened as such.

There are a few expectations attached to placeholder MSCs:

  • They have a title which marks them WIP, and are in the “draft” state.
  • They have the following labels: [proposal-placeholder, action-required, needs-implementation].
    • Notably, not proposal.
  • They are relatively short-lived (ideally less than 6-12 months in placeholder).
  • They propose solutions which are reasonably likely to be accepted. If a placeholder needs to be closed because the idea won’t work, isn’t needed, etc, then the MSC’s content MUST be published ahead of that closure.
    • Note: the MSC’s publication (and therefore closure) may be delayed until an appropriate point in the security disclosure cycle. For example, an alternative MSC being published, or a stream of work being completed.
  • When they are updated to receive real content, the following happens:
    1. The Spec Core Team or the author leaves a comment to cause a notification that the MSC has been replaced with real content.
    2. The proposal label (or its equivalent) is added to trigger chat notifications in the public Matrix rooms. The proposal-placeholder and action-required labels should be removed at this stage as well. Other labels are removed/applied per normal process.
  • The Spec Core Team is aware of the intended MSC’s title and purpose. This is especially important if the Security Team approved the use of a placeholder MSC.

Proposal Tracking

This is a living document generated from the list of proposals on the issue and pull request trackers of the matrix-spec-proposals repo.

We use labels and some metadata in MSC PR descriptions to generate this page. Labels are assigned by the Spec Core Team whilst triaging the proposals based on those which exist in the matrix-spec-proposals repo already.

It is worth mentioning that a previous version of the MSC process used a mixture of GitHub issues and PRs, leading to some MSC numbers deriving from GitHub issue IDs instead. A useful feature of GitHub is that it does automatically resolve to an issue, if an issue ID is placed in a pull URL. This means that https://github.com/matrix-org/matrix-spec-proposals/pull/$MSCID will correctly resolve to the desired MSC, whether it started as an issue or a PR.

Other metadata:

  • The MSC number is taken from the GitHub Pull Request ID. This is carried for the lifetime of the proposal. These IDs do not necessarily represent a chronological order.
  • The GitHub PR title will act as the MSC’s title.
  • Please link to the spec PR (if any) by adding a “PRs: #1234” line in the issue description.
  • The creation date is taken from the GitHub PR, but can be overridden by adding a “Date: yyyy-mm-dd” line in the PR description.
  • Updated Date is taken from GitHub.
  • Author is the creator of the MSC PR, but can be overridden by adding a “Author: @username” line in the body of the issue description. Please make sure @username is a GitHub user (include the @!)
  • A shepherd can be assigned by adding a “Shepherd: @username” line in the issue description. Again, make sure this is a real GitHub user.

Work In Progress

MSC Title Created at Updated at Docs Author Shepherd
4446 MSC4446: Allow moving the fully read marker to older events 2026-04-02 2026-04-02 @SpiritCroc
4411 MSC4411: Widget State Event 2026-01-30 2026-03-27 @toger5
4396 [WIP] MSC4396: Inline linked media 2026-01-06 2026-02-03 @turt2live
4375 [WIP] MSC4375: Admin Room Management 2025-10-29 2025-12-18 @nexy7574
4362 MSC4362: Simplified Encrypted State Events 2025-09-25 2026-03-13 @kaylendog
4358 MSC4358: Out of room server discovery 2025-09-17 2025-12-11 @Gnuxie
4340 MSC4340: Prompts and partial commands for in room commands. 2025-09-02 2025-09-02 @Gnuxie
4310 MSC4310: MatrixRTC decline `m.rtc.decline` 2025-07-10 2025-09-05 @toger5
4309 MSC4309: Finalised delayed event on sync 2025-07-10 2025-08-20 @toger5
4299 [WIP] MSC4299: trusted users 2025-06-12 2025-06-13 @nexy7574
4298 [WIP] MSC4298: Room version components for 'Redact on ban' 2025-06-10 2025-06-10 @turt2live
4296 MSC4296: Mentions for device IDs 2025-06-04 2025-06-17 @Johennes
4269 MSC4269: Unambiguous mentions in body 2025-02-25 2025-03-03 @heftig
4257 MSC4257: Profiles Arent Auth: Move profile contents to a separate event 2025-01-27 2025-01-27 @TheArcaneBrony
4244 [WIP] MSC4244: RFC 9420 MLS for Matrix 2024-12-21 2025-02-03 @turt2live
4232 MSC4232: Attribute-Based Access Control (ABAC) 2024-11-27 2024-11-27 @turt2live
4196 MSC4196: MatrixRTC voice and video calling application `m.call` 2024-09-19 2026-01-23 @hughns
4192 MSC4192: Comparison of proposals for ignoring invites 2024-09-13 2025-05-30 @Johennes
4179 MSC4179: Moderation event hiding 2024-08-19 2024-09-14 @tranquillity-codes
4157 MSC4157: Delayed Events (widget api) 2024-06-19 2026-02-19 @toger5
4152 [WIP] MSC4152: Room labeling and filtering 2024-06-05 2024-06-10 @turt2live
4145 MSC4145: Simple verified accounts 2024-05-14 2024-05-30 @turt2live
4139 MSC4139: Bot buttons & conversations 2024-05-06 2025-08-27 @turt2live
4109 MSC4109: Appservices & soft-failed events 2024-02-23 2024-02-23 @turt2live
4107 MSC4107: Feature-focused versioning 2024-02-19 2024-02-23 @turt2live
4106 MSC4106: Join as Muted 2024-02-19 2026-02-05 @FSG-Cat
4104 MSC4104: Auth Lock: Soft-failure-be-gone! 2024-02-19 2025-07-09 @Gnuxie
4100 MSC4100: Scoped signing keys 2024-02-14 2024-02-15 @turt2live
4094 [WIP] MSC4094: Sync Server and Client Times with endpoint 2024-01-29 2024-08-05 @toger5
4089 MSC4089: Delivery Receipts 2024-01-12 2025-06-17 @turt2live
4086 MSC4086: Event media reference counting 2023-12-23 2023-12-26 @AndrewRyanChama
4080 MSC4080: Cryptographic Identities (Client-Owned Identities) 2023-11-15 2024-05-29 @devonh
4060 MSC4060: Accept room rules before speaking 2023-10-14 2023-11-16 @turt2live
4059 [WIP] MSC4059: Mutable event content 2023-10-14 2024-05-30 @turt2live
4058 [WIP] MSC4058: Additive events 2023-10-14 2023-10-14 @turt2live
4056 MSC4056: Role-Based Access Control (mk II) 2023-09-15 2025-04-12 @turt2live
4049 MSC4049: Sending events as a server or room 2023-08-24 2024-05-30 @turt2live
4047 MSC4047: Send Keys 2023-08-23 2024-05-30 @turt2live
4046 MSC4046: Make & send PDU endpoints 2023-08-22 2023-08-23 @turt2live
4044 MSC4044: Enforcing user ID grammar in rooms 2023-08-12 2023-08-18 @turt2live
4038 MSC4038: Key backup for MLS 2023-07-19 2023-07-19 @uhoreg
4031 MSC4031: Pre-generating invites and room invite codes 2023-06-18 2023-06-29 @mdnwvn
4029 MSC4029: [WIP] Fixing `X-Matrix` request authentication 2023-06-14 2024-06-10 @turt2live
4021 MSC4021: Archive client controls 2023-05-28 2023-07-05 @jonaharagon
4011 MSC4011: Thumbnail media negotiation 2023-05-04 2023-12-16 @clokep, @Half-Shot
4002 MSC4002: Walkie talkie 2023-04-25 2023-04-28 @tajo48
3995 MSC3995: [WIP] Linearized Matrix 2023-04-10 2023-08-19 @turt2live
3994 MSC3994: Display why an event caused a notification 2023-04-06 2023-04-11 @kerryarchibald
3964 MSC3964: Notifications for room tags 2023-02-03 2023-02-03 @clokep
3956 [WIP] MSC3956: Extensible Events - Encrypted Events 2023-01-13 2023-04-18 @turt2live
3948 MSC3948: Repository room for Thirdroom 2022-12-14 2023-06-28 @ajbura
3944 MSC3944: Dropping stale send-to-device messages 2022-12-06 2026-01-26 @uhoreg
3935 MSC3935: Cute Events against social distancing 2022-11-16 2024-04-01 @TheOneWithTheBraid
3909 MSC3909: Membership based mutes 2022-10-13 2026-02-05 @FSG-Cat
3901 MSC3901: Deleting state 2022-09-28 2024-09-01 @andybalaam
3898 [WIP] MSC3898: Native Matrix VoIP signalling for cascaded foci (SFUs, MCUs...) 2022-09-25 2023-01-03 @SimonBrandner
3895 MSC3895: Federation API Behaviour of Partial-State Resident Servers 2022-09-22 2022-09-30 @reivilibre
3883 MSC3883: Fundamental state changes 2022-09-06 2022-09-09 @timokoesters
3872 MSC3872: Order of rooms in Spaces 2022-08-20 2022-08-25 @amytimed
3868 [WIP] MSC3868: Room Contribution 2022-08-15 2022-08-18 @jae1911
3865 [WIP] MSC3865: User-given attributes for users 2022-08-09 2024-07-17 @Zocker1999NET
3864 [WIP] MSC3864: User-given attributes for rooms 2022-08-07 2024-03-31 @Zocker1999NET
3849 MSC3849: Observations and Reinforcement 2022-07-19 2024-05-21 @Gnuxie
3842 [WIP] MSC3842: Placeholder for power levels & extensible events 2022-07-02 2023-07-25 @turt2live
3839 MSC3839: primary-identity-as-key 2022-06-26 2025-02-15 @zander
3815 [WIP] MSC3815: 3D Worlds 2022-05-13 2023-06-28 @robertlong
3814 [WIP] MSC3814: Dehydrated devices with SSSS 2022-05-12 2025-11-26 @uhoreg
3813 MSC3813: Obfuscated events 2022-05-10 2022-07-21 @tusooa
3775 MSC3775: Markup Locations for Audiovisual Media 2022-04-17 2022-09-16 @gleachkr
3755 MSC3755: Member pronouns 2022-03-18 2023-06-02 @Gnuxie
3752 MSC3752: Markup locations for text 2022-03-09 2022-08-09 @gleachkr
3726 [WIP] MSC3726: Safer Password-based Authentication with BS-SPEKE 2022-02-15 2022-03-27 @cvwright
3662 [WIP] MSC3662: Allow Widgets to share user mxids to the client 2022-01-20 2022-01-20 @Half-Shot
3647 [WIP] MSC3647: Bring Your Own Bridge - Decentralising Bridges 2022-01-14 2022-01-23 @ShadowJonathan
3639 [WIP] MSC3639: Matrix for the social media use case 2022-01-12 2023-01-02 @henri2h
3592 MSC3592: Markup locations for PDF documents 2021-12-23 2022-05-18 @gleachkr
3414 [WIP] MSC3414: Encrypted state events 2021-09-27 2025-10-21 @turt2live
3385 [WIP] MSC3385: Bulk small improvements to room upgrades 2021-09-07 2022-01-21 @turt2live
3361 [WIP] MSC3361: Opportunistic Direct Push 2021-08-25 2023-03-03 @lukaslihotzki
3359 [WIP] MSC3359: Delayed Push 2021-08-25 2023-07-14 @jcgruenhage
3269 MSC3269: An error code for busy servers 2021-07-06 2021-08-30 @Yoric
3262 [WIP] MSC3262 aPAKE authentication 2021-07-02 2022-07-26 @mvgorcum
3219 [WIP] MSC3219: Space Flair 2021-05-27 2022-10-21 @turt2live
3215 Draft: MSC3215: Aristotle - Moderation in all things 2021-05-24 2024-05-20 @Yoric
3192 MSC3192: Batch state endpoint 2021-05-12 2024-05-20 @clokep
3189 MSC3189: Per-room/per-space profiles 2021-05-11 2023-04-15 @robintown
3184 MSC3184: Challenges Messages 2021-05-10 2024-09-25 @BillCarsonFr
3089 MSC3089: File tree structures 2021-04-02 2021-09-10 @turt2live
3088 MSC3088: Room subtyping 2021-04-01 2022-01-22 @turt2live
3062 MSC3062: Bot verification 2021-03-12 2024-02-23 @uhoreg
3032 MSC3032: Thoughts on updating presence 2021-02-25 2021-08-30 @dbkr
3020 MSC3020: WIP proposal for better supporting private federations 2021-02-21 2024-01-15 @ara4n
2923 MSC2923: Connect Matrix room to another Matrix room 2020-12-22 2023-06-29 @MadLittleMods
2883 MSC2883: [WIP] Matrix-flavoured MLS 2020-11-27 2024-07-26 @uhoreg
2882 MSC2882: [WIP] Tempered Transitive Trust 2020-11-27 2022-10-05 @uhoreg
2812 [WIP] MSC2812: Role-based power/permissions 2020-10-08 2025-08-12 @turt2live
2802 [WIP] MSC2802: Full Room Abstraction 2020-10-05 2021-08-30 @ShadowJonathan
2787 MSC2787: Portable Identities 2020-09-23 2025-01-13 @neilalexander
2706 [WIP] MSC2706: IPFS as a media repository for Matrix 2020-07-28 2023-06-04 @turt2live
2438 [WIP] MSC2438: Local and Federated User Erasure Requests 2020-02-19 2023-06-02 @anoadragon453
2370 [WIP] MSC2370: Resolve URL API 2019-11-29 2021-08-30 @uhoreg
1228 [WIP] MSC1228: Removing MXIDs from events 2018-05-10 2024-06-05 @benparsons
2301 [WIP] MSC2301: server info endpoint 2019-09-23 2021-08-30 @ara4n
2300 [WIP] MSC2300: /ping endpoint 2019-09-23 2021-10-15 @ara4n
1956 [WIP] MSC1956: Integrations API (base) 2019-04-08 2025-05-17 @turt2live
1781 [WIP] MSC1781: Proposal for associations for DIDs and DID names 2019-01-07 2022-12-13 @friedger
1780 [WIP] MSC1780: Add DIDs and DID names as admin accounts to HS 2019-01-07 2021-08-30 @friedger
1769 WIPish: MSC1769: Extensible profiles as rooms 2019-01-03 2025-08-12 @ara4n
1768 [WIP] MSC1768: Proposal to authenticate with public keys 2019-01-03 2021-08-30 @friedger
1762 [WIP] MSC1762: Support user-owned identifiers as new 3PID type 2018-12-28 2021-08-30 @friedger
1607 MSC1607: Proposal for room alias grammar 2018-08-29 2021-08-30 @richvdh

Proposal In Review

MSC Title Created at Updated at Docs Author Shepherd
4447 MSC4447: Move OpenID userinfo endpoint out of `/_matrix/federation` 2026-04-06 2026-04-06 @gingershaped
4445 MSC4445: Clarify `/sync` timeline order 2026-04-01 2026-04-02 @MadLittleMods
4444 MSC4444: Malicious PDUs 2026-04-01 2026-04-02 @velikopter
4441 MSC4441: Encrypted User Profile Annotations via Account Data 2026-03-30 2026-04-02 @thetayloredman
4440 MSC4440: Profile Biography via Global Profiles 2026-03-27 2026-04-05 @RoootTheFox
4439 MSC4439: Encryption key URIs in `/.well-known/matrix/support` 2026-03-26 2026-04-03 @thetayloredman
4438 MSC4438: Message bookmarks via account data 2026-03-24 2026-04-01 @smokku
4435 MSC4435: Room slowmode 2026-03-17 2026-04-06 @velikopter
4433 MSC4433: Image Packs and Room Upgrades 2026-03-12 2026-03-23 @anoadragon453
4432 MSC4432: Server-wide room name overrides 2026-03-09 2026-03-25 @Johennes
4431 MSC4431: Personalised room name overrides 2026-03-09 2026-03-23 @Johennes
4430 MSC4430: Member Keys 2026-03-06 2026-03-23 @kegsay
4429 MSC4429: Profile Updates for Legacy Sync 2026-03-05 2026-03-31 @anoadragon453
4428 MSC4428: Stable identifiers for Room Members 2026-03-04 2026-03-14 @kegsay
4427 MSC4427: Custom banners for user profiles 2026-02-25 2026-03-28 @cyrneko
4426 MSC4426: User Status Profile Fields 2026-02-25 2026-03-19 @anoadragon453
4425 MSC4425: Ephemeral media 2026-02-24 2026-03-04 @turt2live
4421 MSC4421: Standardize the spec on US English 2026-02-17 2026-04-01 @Johennes
4420 MSC4420: Duplicate one-time key error response for /keys/upload 2026-02-17 2026-02-17 @Johennes
4418 MSC4418: Make `destination` a required server authentication field 2026-02-14 2026-03-23 @velikopter
4417 MSC4417: URL Previews via Appservices 2026-02-12 2026-03-03 @Half-Shot
4416 MSC4416: Optionally requiring policy server signatures in a room 2026-02-06 2026-04-02 @turt2live
4414 MSC4414: Design decision - Errors 2026-02-03 2026-02-13 @turt2live
4413 MSC4413: remove `private` join_rule 2026-02-02 2026-02-03 @ara4n
4412 MSC4412: Widget Base postMessage API 2026-02-02 2026-02-03 @dbkr
4409 MSC4409: Clarify thumbnailing behavior in E2EE 2026-01-23 2026-01-26 @stefanceriu
4407 MSC4407: Sticky Events (widget-api) 2026-01-21 2026-01-24 @toger5
4406 MSC4406: `M_SENDER_IGNORED` error code 2026-01-21 2026-03-18 @nexy7574
4405 MSC4405: Deprecate the emoji method for SAS verification 2026-01-20 2026-01-27 @uhoreg
4403 MSC4403: Forbid `event_id` on PDUs received over federation 2026-01-15 2026-03-12 @velikopter
4401 MSC4401: Publishing client capabilities via profiles 2026-01-15 2026-03-11 @Johennes
4400 MSC4400: Remove the depth field from PDUs 2026-01-14 2026-03-12 @velikopter
4397 MSC4397: Tags as spaces 2026-01-07 2026-01-07 @ara4n
4392 MSC4392: Encrypted reactions and replies 2025-12-26 2026-03-10 @tulir
4391 MSC4391: Simplified in-room bot commands 2025-12-24 2026-03-16 @Gnuxie
4390 MSC4390: Room Blocking API 2025-12-17 2026-01-19 @nexy7574
4389 MSC4389: Image ordering within packs 2025-12-13 2025-12-13 @tulir
4388 MSC4388: Secure out-of-band channel for sign in with QR 2025-12-10 2026-04-01 @hughns
4387 MSC4387: `M_SAFETY` error code 2025-12-09 2026-01-13 @turt2live
4386 MSC4386: Automatically sharing secrets after device verification 2025-12-08 2026-03-12 @uhoreg
4385 MSC4385: Pushing secrets to other devices 2025-12-03 2026-03-12 @uhoreg
4383 MSC4383: Client-Server Discovery of Server Version 2025-11-21 2025-11-25 @jevolk
4382 MSC4382: Peppered hash verification for E2EE content moderation 2025-11-20 2025-11-21 @seuros
4377 MSC4377: Clarify Image Pack Ordering 2025-11-03 2025-11-08 @Enovale
4373 MSC4373: Server opt-out of specific EDU types 2025-10-22 2026-03-12 @velikopter
4371 MSC4371: On the elimination of federation transactions. 2025-10-21 2025-10-24 @jevolk
4370 MSC4370: Federation endpoint for retrieving current extremities 2025-10-17 2026-03-05 @turt2live
4369 MSC4369: M_CAPABILITY_NOT_ENABLED error code for when capability is not enabled on an API endpoint 2025-10-17 2025-11-06 @hughns
4368 MSC4368: Combine definitions of M_RESOURCE_LIMIT_EXCEEDED error code and m.server_notice.usage_limit_reached server notice type 2025-10-15 2025-10-21 @hughns
4367 MSC4367: via routes in the published room directory 2025-10-14 2025-11-26 @Johennes
4366 MSC4366: Resident servers in and around the room directory 2025-10-14 2025-10-21 @Johennes
4365 MSC4365: Canonical ignore list rooms 2025-10-13 2025-10-23 @TheArcaneBrony
4363 MSC4363: OAuth step up authentication 2025-09-30 2025-11-05 @Johennes
4361 MSC4361: Non-federating Membership Authorization Rule Amendments 2025-09-23 2025-12-21 @jevolk
4360 MSC4360 Sliding Sync threads extension 2025-09-17 2025-10-31 @devonh
4359 MSC4359: "Do not Disturb" notification settings 2025-09-17 2025-10-07 @Johennes
4357 MSC4357: Live Messages via Event Replacement 2025-09-16 2025-10-23 @donprus
4354 MSC4354: Sticky Events 2025-09-16 2026-04-01 @kegsay
4353 MSC4353: Per-origin linear chain 2025-09-15 2025-09-16 @Gnuxie
4352 MSC4352: Customizable HTTPS permalink base URLs via server discovery 2025-09-15 2025-09-24 @DonPrus
4351 MSC4351: Odd Context Limits 2025-09-13 2025-09-23 @jevolk
4350 MSC4350: Permitting encryption impersonation for appservices 2025-09-10 2025-09-11 @tulir
4349 MSC4349: Causal barriers and enforcement 2025-09-10 2025-10-07 @Gnuxie
4348 MSC4348: Portable and serverless accounts in rooms 2025-09-09 2025-12-16 @Gnuxie
4345 MSC4345: Server key identity and room membership 2025-09-08 2026-02-04 @Gnuxie
4344 MSC4344: Strike deprecated SRV service name. 2025-09-08 2025-09-08 @jevolk
4343 MSC4343: Making mass redactions use a new event type 2025-09-06 2025-09-12 @turt2live
4342 MSC4342: Limiting the number of devices per user ID 2025-09-05 2025-09-12 @kegsay
4339 MSC4339: Allow the user directory to return full profiles 2025-09-02 2025-12-18 @Half-Shot
4337 MSC4337: Appservice API to supplement user profiles 2025-09-01 2025-09-02 @Half-Shot
4334 MSC4334: Add `m.room.language` state event. 2025-08-29 2025-09-26 @dragonfly1033
4333 MSC4333: Room state API for moderation bots 2025-08-27 2025-10-23 @turt2live
4332 MSC4332: In-room bot commands 2025-08-27 2026-03-07 @turt2live
4331 MSC4331: Device Account Data 2025-08-26 2025-09-23 @jevolk
4330 MSC4330: specify HTTP and TLS versions which must be supported 2025-08-17 2025-08-18 @famfo
4325 MSC4325: Presence privacy 2025-08-09 2026-01-24 @HarHarLinks
4322 MSC4322: Simple Media Self-Redaction 2025-08-06 2026-01-27 @nexy7574
4321 MSC4321: Policy Room Upgrade Semantics 2025-08-03 2026-02-28 @Gnuxie
4320 MSC4320: Rich Presence 2025-08-02 2026-02-16 @88572
4308 MSC4308: Thread Subscriptions extension to Sliding Sync 2025-07-09 2025-12-02 @reivilibre
4306 MSC4306: Thread Subscriptions 2025-07-08 2025-09-23 @reivilibre
4305 MSC4305: Pushed Authorization Requests (PARs) for OAuth authentication 2025-07-04 2025-07-04 @Johennes
4303 MSC4303: Disallowing non-compliant user IDs in rooms 2025-06-27 2025-07-08 @tulir
4302 MSC4302: Exchanging FHIR resources via Matrix events 2025-06-20 2026-03-06 @Johennes
4300 MSC4300: Processing status requests & responses 2025-06-16 2026-01-26 @Johennes
4295 MSC4295: Bot bounce limit - a better loop prevention mechanism 2025-05-31 2025-06-02 @m13253
4293 MSC4293: Redact on kick/ban 2025-05-27 2026-03-12 @turt2live
4292 MSC4292: Handling incompatible room versions in clients 2025-05-26 2026-02-19 @turt2live
4286 MSC4286: App store compliant handling of payment links within events 2025-05-06 2025-06-14 @hughns
4283 MSC4283: Distinction between Ignore and Block 2025-04-02 2025-05-26 @turt2live
4282 MSC4282: Interactive /rooms/ROOM_ID/messages (Client-Server API) 2025-04-02 2025-11-18 @bnjbvr
4279 MSC4279: Server notice rooms 2025-03-27 2025-04-06 @turt2live
4274 MSC4274: Inline media galleries via msgtypes 2025-03-18 2026-03-31 @Johennes
4273 MSC4273: Approve and Disapprove ratings for moderation policies 2025-03-12 2025-03-23 @Gnuxie
4271 MSC4271: Recommended enabled-ness for default push rules 2025-03-03 2025-03-04 @Johennes
4270 MSC4270: Matrix Glossary 2025-02-26 2025-03-04 @turt2live
4266 MSC4266: Policies in /.well-known/matrix/support 2025-02-14 2025-10-29 @Johennes
4265 MSC4265: Data Protection Officer contact in /.well-known/matrix/support 2025-02-14 2025-05-20 @Johennes
4264 MSC4264: Tokens for Contacting Accounts or Joining Semi-Public Rooms 2025-02-11 2025-05-29 @thomasfiala
4263 MSC4263: Preventing MXID enumeration via key queries 2025-02-04 2025-02-21 @Johennes
4262 MSC4262: Sliding Sync Extension: Profile Updates 2025-02-03 2025-02-14 @tcpipuk
4261 MSC4261: "Do not encrypt for device" flag 2025-02-01 2025-09-12 @uhoreg
4259 MSC4259: Profile Update EDUs for Federation 2025-01-30 2026-02-26 @tcpipuk
4258 MSC4258: Federated User Directory 2025-01-29 2025-12-11 @MatMaul
4256 MSC4256: RFC 9420 MLS mode Matrix 2025-01-24 2026-02-08 @dklimpel
4255 MSC4255: Bulk Profile Updates 2025-01-23 2025-01-23 @tcpipuk
4253 MSC4253: Modifying or rejecting accepted MSCs 2025-01-15 2025-01-16 @turt2live
4252 MSC4252: Extensible Events modification: State event handling 2025-01-15 2025-01-15 @turt2live
4250 MSC4250: Authenticated media v2 (Cookie authentication for Client-Server API) 2025-01-11 2025-01-13 @turt2live
4249 MSC4249: Removal of legacy media endpoints 2025-01-02 2025-01-02 @turt2live
4247 MSC4247: User Pronouns 2024-12-27 2026-02-27 @88572
4246 MSC4246: Sending to-device messages as/to a server 2024-12-21 2024-12-21 @turt2live
4245 MSC4245: Immutable encryption algorithm 2024-12-21 2025-02-18 @turt2live
4243 MSC4243: User ID localparts as Account Keys 2024-12-17 2026-02-05 @kegsay
4242 MSC4242: State DAGs 2024-12-17 2026-03-10 @kegsay
4238 MSC4238: Pinned events read marker 2024-12-10 2025-01-24 @ajbura
4235 MSC4235: `via` query param for hierarchy endpoint 2024-12-02 2025-02-25 @ajbura
4234 MSC4234: Update app badge counts when rooms are read 2024-11-29 2024-12-02 @ara4n
4233 MSC4233: Remembering which server a user knocked through 2024-11-28 2025-01-20 @turt2live
4228 MSC4228: Search Redirection 2024-11-18 2025-02-19 @turt2live
4227 MSC4227: Audio based quick login 2024-11-15 2024-12-28 @albertotirla
4226 MSC4226: Reports as rooms 2024-11-12 2024-11-13 @Gnuxie
4224 MSC4224: CBOR Serialization 2024-11-06 2025-11-01 @Saiv46
4223 MSC4223: Error code for disallowing threepid unbinding 2024-10-30 2024-10-30 @turt2live
4221 MSC4221: Room Banners 2024-10-26 2024-11-06 @88572
4220 MSC4220: Local call rejection (m.call.reject_locally) 2024-10-23 2024-10-28 @ara4n
4218 MSC4218: Improving performance of profile changes 2024-10-20 2024-10-31 @kegsay
4211 MSC4211: WebXDC on Matrix