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

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:

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.
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.
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.
However, the spec must never add dependencies on unspecified/nonstandardised 3rd party behaviour.

As a worked example:

Video conferencing is clearly a feature which would benefit the whole ecosystem, and so the spec should find a way to make it happen.
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.
A better experience could be achieved by embedding Jitsi natively into clients rather than using a widget…
…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.

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.

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.

Have an idea for a feature.
Implement the feature using unstable endpoints, vendor prefixes, and unstable feature flags as appropriate.
In parallel, or ahead of implementation, open an MSC and solicit review per above.
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.
The FCP process is completed, and assuming nothing is flagged the MSC lands.
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.
A spec PR is written to incorporate the changes into Matrix.
A spec release happens.
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	Author
4450	MSC4450: Identity Provider selection for User-Interactive Authentication with Legacy Single Sign-On	2026-04-14	2026-04-16	@reivilibre
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	@timedoutuk
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	@timedoutuk
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
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
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	2026-04-08	@turt2live
4086	MSC4086: Event media reference counting	2023-12-23	2023-12-26	@AndrewRyanChama
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

Proposal In Review

MSC	Title	Created at	Updated at	Docs	Author
4458	MSC4458: Handling incoming JSON in the server-server API	2026-04-28	2026-04-29		@richvdh
4457	MSC4457: Generic reporting API	2026-04-28	2026-04-28		@turt2live
4456	MSC4456: Harms taxonomy	2026-04-28	2026-04-28		@turt2live
4455	MSC4455: Catch-all property for spaces	2026-04-25	2026-04-27		@SpiritCroc
4454	MSC4454: Deprecating Spoiler Fallback In Media Repository	2026-04-22	2026-04-23		@dozro
4453	MSC4453: Deprecate old room versions	2026-04-21	2026-04-27		@timedoutuk
4451	MSC4451: Deprecate notifications endpoint	2026-04-16	2026-04-23		@JadedBlueEyes
4449	MSC4449: Updated /members filtering	2026-04-11	2026-04-13		@timedoutuk
4447	MSC4447: Move OpenID userinfo endpoint out of `/_matrix/federation`	2026-04-06	2026-04-06		@gingershaped
4446	MSC4446: Allow moving the fully read marker to older events	2026-04-02	2026-04-09		@SpiritCroc
4445	MSC4445: Clarify `/sync` timeline order	2026-04-01	2026-04-02		@MadLittleMods
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-26		@RoootTheFox
4439	MSC4439: Encryption key URIs in `/.well-known/matrix/support`	2026-03-26	2026-04-20		@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-04-07		@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
4421	MSC4421: Standardize the spec on US English	2026-02-17	2026-04-28		@Johennes
4418	MSC4418: Make `destination` a required server authentication field	2026-02-14	2026-04-20		@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-04-08		@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		@timedoutuk
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		@timedoutuk
4388	MSC4388: Secure out-of-band channel for sign in with QR	2025-12-10	2026-04-23		@hughns
4387	MSC4387: `M_SAFETY` error code	2025-12-09	2026-04-28		@turt2live
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
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	2026-04-16		@donprus
4354	MSC4354: Sticky Events	2025-09-16	2026-04-16		@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	2026-04-20		@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		@timedoutuk
4321	MSC4321: Policy Room Upgrade Semantics	2025-08-03	2026-02-28		@Gnuxie
4320	MSC4320: Rich Presence	2025-08-02	2026-04-10		@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-04-14		@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
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
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
4242	MSC4242: State DAGs	2024-12-17	2026-04-28		@kegsay
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
4141	MSC4141: Time based notification filtering	2024-05-08	2024-06-22		@hanadi92
4125	MSC4125: Specify servers to join via for federated invites	2024-04-09	2024-04-10		@Kladki
4119	MSC4119: Voluntary content flagging	2024-03-13	2024-09-01		@turt2live
4117	MSC4117: Reinstating Events (Reversible Redactions)	2024-03-04	2024-03-04		@turt2live
4114	MSC4114: Matrix as a password manager	2024-02-24	2024-06-06		@Johennes
4110	MSC4110: Fewer Features	2024-02-23	2025-06-15		@cloudrac3r
4108	MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code	2024-02-22	2026-04-27		@hughns
4103	MSC4103: Make threaded read receipts opt-in in /sync	2024-02-15	2024-02-20		@ara4n
4102	MSC4102: Clarifying precedence in threaded and unthreaded read receipts in EDUs	2024-02-15	2025-11-11		@kegsay
4101	MSC4101: Hashes for unencrypted media	2024-02-15	2025-11-17		@turt2live
4083	MSC4083: Delta-compressed E2EE file transfers	2023-12-16	2023-12-27		@ara4n
3917	MSC3917: Cryptographically Constrained Room Membership	2022-10-25	2026-03-25		@duxovni
3896	MSC3896: Appservice media	2022-09-24	2024-07-01		@tezlm
3892	MSC3892: Custom Emotes with Encryption	2022-09-14	2023-10-24		@nmscode
3890	MSC3890: Remotely silence local notifications	2022-09-13	2023-02-20		@kerryarchibald
3888	MSC3888: Voice Broadcast	2022-09-09	2023-06-05		@weeman1337
3884	MSC3884: Sliding Sync Extension: E2EE	2022-09-06	2025-11-27		@kegsay
3881	MSC3881: Remotely toggle push notifications for another client	2022-09-05	2022-11-21		@kerryarchibald
3880	MSC3880: dummy replies for Olm	2022-09-05	2022-09-07		@uhoreg
3879	MSC3879: Trusted key forwards	2022-09-05	2023-10-16		@uhoreg
3874	MSC3874: Filtering threads from the /messages endpoint	2022-08-23	2023-06-06		@justjanne
3871	MSC3871: Gappy timelines	2022-08-18	2026-03-31		@MadLittleMods
3869	MSC3869: Read event relations with the Widget API	2022-08-16	2022-11-09		@dhenneke
3866	MSC3866: `M_USER_AWAITING_APPROVAL` error code	2022-08-12	2022-09-29		@babolivier
3857	MSC3857: Welcome messages	2022-08-02	2022-08-14		@turt2live
3851	MSC3851: Allow custom room presets when creating a room	2022-07-21	2022-07-22		@anoadragon453
3848	MSC3848: Introduce errcodes for specific event sending failures	2022-07-19	2022-10-11		@Half-Shot
3202	MSC3202: Encrypted appservices	2021-05-18	2026-01-19		@turt2live
3174	MSC3174: An error code for spam rejections	2021-05-04	2022-05-05		@Yoric
2618	MSC2618: Helping others with mandatory implementation guides	2020-06-09	2022-05-05		@turt2live
2529	MSC2529: Proposal to use existing events as captions for images	2020-05-07	2022-07-17		@benparsons
3812	MSC1485: Hint buttons in messages	2018-08-04	2024-12-20	1	@tulir
3811	[WIP] MSC1453: Antivirus support	2018-07-26	2022-09-17		@ara4n
3809	Proposal to improve /createRoom	2018-06-22	2022-05-10	1	@turt2live
1316	Proposal to have the appservice registration `type` be optional	2018-06-18	2021-05-03	1	@turt2live
3807	Proposal for an application service management API	2018-06-14	2022-05-10	1	@turt2live
3806	Proposal to filter out traffic to Appservices based on filters	2018-06-14	2022-05-10	1	@Half-Shot
3803	Matrix Widget API v2	2018-05-13	2026-02-24	1	@rxl881
3802	Mitigating abuse of the event depth parameter over federation	2018-05-10	2022-05-20	1	@ara4n
3801	Bridging group membership with 3rd party group sources	2018-05-10	2022-07-19	1	@lukebarnard1
3800	Proposal for improved bot support	2018-05-10	2022-05-09	1	@turt2live
3799	Threading API	2018-05-10	2022-07-31	1	@Half-Shot
3798	Support for websockets	2018-03-06	2025-05-22	1, 2	@richvdh, @krombel
3797	Refine and clarify how presence works	2017-12-26	2022-05-09	1	@ara4n
3796	Auth/linking for content repo (and enforcing GDPR erasure)	2016-08-20	2025-12-09	1	@ara4n
3795	Extensible Profiles. (SPEC-93)	2015-01-19	2025-12-25	1	@erikjohnston
3794	Federation API for canonicalising MXIDs	2014-10-27	2022-05-16	1	@ara4n

Proposed Final Comment Period

MSC	Title	Created at	Updated at	Author
4452	MSC4452: Preview URL capabilities API	2026-04-21	2026-04-28	@Half-Shot
4436	MSC4436: Make server ACLs case insensitive	2026-03-17	2026-04-15	@turt2live
4402	MSC4402: Consistent redirects for .well-known-files	2026-01-15	2026-04-15	@derhagen
4319	MSC4319: Room member events for invite and knock rooms in the `/sync` response	2025-08-01	2026-04-28	@zecakeh
4278	MSC4278: Media preview controls	2025-03-25	2026-04-28	@Half-Shot
4186	MSC4186: Simplified Sliding Sync	2024-08-30	2026-04-28	@erikjohnston
4174	MSC4174: Web push	2024-08-01	2026-04-28	@p1gp1g

Final Comment Period

MSC	Title	Created at	Updated at	Docs	Author	Shepherd
2545	MSC2545: Image Packs (Emoticons & Stickers)	2020-05-15	2026-04-28		@Sorunome	@anoadragon453

Finished Final Comment Period

MSC	Title	Created at	Updated at	Docs	Author	Shepherd
4294	MSC4294: Ignore and mass ignore invites	2025-05-29	2025-12-08		@grinapo

Spec PR Missing

MSC	Title	Created at	Updated at	Docs	Author
4381	MSC4381: Remove plaintext sender key	2025-11-20	2026-01-27		@tulir
2666	MSC2666: Get rooms in common with another user	2020-07-05	2026-03-16		@Half-Shot, @ShadowJonathan
3810	Widget API extension: Always-on-screen	2018-07-03	2026-02-24	1	@dbkr

Spec PR In Review

MSC	Title	Created at	Updated at	Docs	Author	Shepherd
4287	MSC4287: Sharing key backup preference between clients	2025-05-08	2026-04-10		@andybalaam

Merged

MSC	Title	Created at	Updated at	Docs	Author	Shepherd
4380	MSC4380: Invite blocking	2025-11-18	2026-02-04		@richvdh
4376	MSC4376: Remove /v1/send_join and /v1/send_leave	2025-10-31	2026-02-24		@Johennes
4356	MSC4356: Recently used emoji	2025-09-16	2026-01-14		@Johennes
4341	MSC4341: Support for RFC 8628 Device Authorization Grant	2025-09-03	2026-03-17		@hughns
4335	MSC4335: M_USER_LIMIT_EXCEEDED error code	2025-08-29	2026-03-10		@hughns
4326	MSC4326: Device masquerading for appservices	2025-08-12	2025-10-08		@turt2live
4323	MSC4323: User suspension & locking endpoints	2025-08-06	2026-02-16		@timedoutuk
4313	MSC4313: Require HTML `<ol>` `start` Attribute support	2025-07-15	2026-02-03		@HarHarLinks
4312	MSC4312: Resetting cross-signing keys in the OAuth world	2025-07-15	2025-11-24		@Johennes
4311	MSC4311: Ensuring the create event is available on invites	2025-07-11	2025-09-12		@turt2live
4307	MSC4307: Validate that `auth_events` are in the correct room	2025-07-08	2025-08-14		@richvdh
4304	MSC4304: Room Version 12	2025-07-03	2025-08-14		@turt2live
4297	MSC4297: State Resolution 2.1	2025-06-06	2025-08-15		@kegsay
4291	MSC4291: Room IDs as hashes of the create event	2025-05-20	2026-01-13		@ara4n
4289	MSC4289: Explicitly privilege room creators	2025-05-20	2026-01-13		@ara4n
4284	MSC4284: Policy Servers	2025-04-07	2026-03-18		@turt2live
4277	MSC4277: Harmonizing the reporting endpoints	2025-03-21	2026-03-03		@Johennes
4267	MSC4267: Automatically forgetting rooms on leave	2025-02-17	2026-01-28		@Johennes
4254	MSC4254: Usage of RFC7009 Token Revocation for Matrix client logout	2025-01-17	2025-08-21		@sandhose
4115	MSC4115: membership information on events	2024-02-26	2024-06-18		@richvdh
3904	MSC3904: Room version 10 as the default room version	2022-10-09	2025-02-16		@FSG-Cat
3882	MSC3882: Allow an existing session to sign in a new session	2022-09-05	2024-06-18		@hughns
3873	MSC3873: event_match dotted keys	2022-08-21	2024-06-18		@Johennes
3861	MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC	2022-08-04	2025-06-20		@hughns
3860	MSC3860: Media Download Redirects	2022-08-04	2025-05-17		@Fizzadar
3827	MSC3827: Filtering of `/publicRooms` by room type	2022-05-27	2024-11-20		@SimonBrandner
3375	MSC3375: Room version 9	2021-09-02	2023-05-17		@clokep
2998	MSC2998: Room Version 7	2021-02-08	2021-04-30		@anoadragon453
2966	MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix	2021-01-14	2025-08-21		@sandhose
2965	MSC2965: OAuth 2.0 Authorization Server Metadata discovery	2021-01-14	2025-08-21		@sandhose
2758	MSC2758: Proposal for a common identifier grammar	2020-09-01	2021-12-29		@richvdh
2689	MSC2689: Fix E2EE for guests	2020-07-15	2020-10-07		@awesome-michael
2663	MSC2663: Errors for dealing with non-existent push rules	2020-07-03	2020-10-07		@reivilibre
2630	MSC2630: checking public keys in SAS verification	2020-06-11	2021-05-01		@uhoreg
2611	MSC2611: Remove `m.login.token` User-Interactive Authentication type from the specification	2020-06-05	2022-03-01		@richvdh
2610	MSC2610: Remove `m.login.oauth2` User-Interactive Authentication type from the specification	2020-06-05	2022-02-21		@richvdh
2604	MSC2604: Accept device information for the login fallback endpoint	2020-06-04	2023-05-17		@clokep
2540	MSC2540: Stricter event validation: JSON compliance	2020-05-13	2023-05-17		@clokep
2530	MSC2530: Body field as media caption	2020-05-07	2024-02-26		@tulir
2472	MSC2472: Symmetric SSSS	2020-03-24	2023-04-12		@uhoreg
2457	MSC2457: Invalidating devices during password modification	2020-03-12	2023-05-17		@clokep
2454	MSC2454: Support UI auth for SSO	2020-03-09	2023-05-17		@clokep
2451	MSC2451: Remove `query_auth` federation endpoint.	2020-03-03	2020-04-22		@clokep
2432	MSC2432: Updated semantics for publishing room aliases	2020-02-10	2023-07-28		@richvdh
2422	MSC2422: Allow color on font tag	2020-01-23	2021-04-06		@deepbluev7
2399	MSC2399: Reporting that decryption keys are withheld	2020-01-02	2022-07-15		@uhoreg
2367	MSC2367: Add reason field to all membership events	2019-11-26	2020-10-07		@erikjohnston
2334	MSC2334 - Change default room version to v5	2019-10-30	2020-04-20		@aaronraimist
2324	MSC2324: Facilitating early releases of software dependent on spec	2019-10-18	2020-05-21		@turt2live
2313	MSC2313: Moderation policies as rooms (ban lists)	2019-10-05	2020-11-14		@ara4n
2290	MSC2290: Separate Endpoints for Threepid Binding	2019-09-12	2020-04-20		@anoadragon453
2284	MSC2284: Making the identity server optional during discovery	2019-09-06	2021-05-02		@turt2live
2265	MSC2265: Proposal for mandating case folding when processing e-mail address localparts	2019-08-30	2021-07-12		@babolivier
2264	MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support	2019-08-29	2020-04-20		@turt2live
2263	MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets	2019-08-29	2020-04-20		@turt2live
2241	MSC2241: Key verification in DMs	2019-08-22	2021-07-05		@uhoreg
2240	MSC2240: Room version 6	2019-08-22	2020-07-29		@turt2live
2230	MSC2230: Store Identity Server in Account Data	2019-08-13	2020-04-20		@dbkr
2209	MSC2209: Alter auth rules to check notifications in m.room.power_levels	2019-08-01	2020-07-29		@lucavb
2197	MSC2197: Search Filtering in Federation /publicRooms	2019-07-29	2021-10-30		@reivilibre
2181	MSC2181: Add an Error Code for Signaling a Deactivated User	2019-07-16	2020-04-20		@anoadragon453
2140	MSC2140: Terms of Service for ISes and IMs	2019-06-20	2022-03-01		@dbkr
2134	MSC2134: Identity Hash Lookups	2019-06-15	2020-04-20		@anoadragon453
2078	MSC2078: Sending Third-Party Request Tokens via the Homeserver	2019-06-05	2020-04-20		@anoadragon453
2033	MSC2033: Adding a device_id to /account/whoami	2019-05-27	2021-05-03		@turt2live
2010	MSC2010: Add client-side spoilers	2019-05-22	2022-03-01		@Sorunome
2002	MSC2002: Proposal for adopting MSC1884 as v4 rooms	2019-05-17	2020-04-20		@ara4n
1983	MSC1983: Supporting a reason for leaving rooms	2019-04-30	2021-05-01		@turt2live
1954	MSC1954: Proposal to remove prev_content from the essential keys list	2019-04-05	2020-04-20		@neilisfragile
1946	MSC1946: Secure Secret Storage and Sharing	2019-03-28	2023-04-12		@uhoreg
1930	MSC1930: Add a push rule for m.room.tombstone events	2019-03-15	2022-08-31		@turt2live
1915	MSC 1915 - Add a 3PID unbind API	2019-03-06	2020-04-20		@erikjohnston
1884	MSC1884: Proposal to replace slashes in event IDs	2019-02-13	2020-04-20		@richvdh
1866	Add proposal for invite error code for unsupported room version	2019-02-08	2020-04-20		@erikjohnston
1831	MSC1831: Change the order of .well-known and SRV discovery techniques	2019-01-31	2020-04-20		@turt2live
1819	MSC:1819 Remove Presence Lists	2019-01-28	2020-04-20		@neilisfragile
1813	MSC 1813 - Federation Make Membership Room Version	2019-01-22	2020-04-20		@erikjohnston
1804	MSC1804: Advertising capable room versions to clients	2019-01-17	2020-04-20		@turt2live
1802	MSC1802: Remove the '200' value from some federation responses	2019-01-14	2020-05-19		@babolivier
1794	MSC 1794 - Federation v2 Invite API	2019-01-10	2021-09-22		@erikjohnston
1759	Room v2 proposal	2018-12-17	2020-04-20		@erikjohnston
1756	MSC1756: cross-signing devices using a master identity key	2018-12-14	2020-12-15		@uhoreg
1753	MSC1753: client-server capabilities API	2018-12-12	2020-04-20		@richvdh
1730	MSC1730: Mechanism for redirecting to an alternative server during login	2018-11-23	2020-04-20		@richvdh
1717	MSC1717: common definitions for key verification methods	2018-11-13	2020-04-20		@uhoreg
1711	MSC1711: X.509 certificate verification for federation connections	2018-11-07	2022-03-01		@richvdh
1708	MSC1708: .well-known support for server name resolution	2018-11-05	2022-12-17		@richvdh
1704	MSC1704: Adding ?via= to matrix.to permalinks to help with routing	2018-10-26	2020-04-20		@turt2live
1693	MSC1693: Specify how to handle rejected events in new state res	2018-10-08	2020-04-20		@erikjohnston
1659	MSC 1659 Proposal: Change Event IDs to Hashes	2018-09-05	2020-04-21		@erikjohnston
1504	Homeserver resource limiting error codes	2018-08-13	2020-04-21	1	@neilisfragile
1501	Room version upgrades	2018-08-10	2020-04-21	1	@richvdh
1497	MSC1497: Advertising support of experimental features in the CS API	2018-08-08	2020-04-21	1	@ara4n
1466	MSC1466: Soft Logout	2018-08-01	2020-05-26	1	@erikjohnston
1452	Homeserver Warning Messages	2018-07-25	2020-04-21	1	@dbkr
1442	State Resolution: Reloaded	2018-07-20	2020-04-21	1	@erikjohnston
1426	Proposal for clarifying and improving review process for MSCs	2018-07-17	2020-04-21	1	@ara4n
1425	Room Versioning	2018-07-17	2020-04-21	1	@richvdh
1383	Proposal for ACLing servers from rooms	2018-07-05	2020-04-21	1	@richvdh, @ara4n
1339	Proposal to add a GET method to read account data	2018-06-24	2020-04-21		@ananace
1323	AS traffic rate-limiting	2018-06-20	2018-08-28	1	@anoadragon453
1304	Proposal to simplify the auth rules of m.room.power_level events.	2018-06-14	2020-04-21	1	@richvdh, @ara4n
1267	MSC 1267: Interactive key verification using short authentication strings	2018-05-28	2020-04-21	1	@uhoreg
1234	Rich Replies format	2018-05-12	2020-04-21	1	@t3chguy
1233	A proposal for organising spec proposals	2018-05-10	2020-04-21	1	@ara4n
1232	Media limits API	2018-05-10	2020-04-21	1	@Half-Shot
1230	Temporary mitigation for depth parameter abuse	2018-05-10	2020-04-21	1	@ara4n
1227	Proposal for lazy-loading room members to improve initial sync speed and client RAM usage	2018-05-10	2020-04-21	1	@ara4n
1219	Proposal for storing megolm keys serverside	2018-05-10	2020-06-02	1	@ara4n, @uhoreg
1212	Device List Update Stream	2018-05-10	2020-04-21	1	@richvdh
1211	Megolm session export format	2018-05-10	2020-04-21	1	@richvdh
1208	Encrypted attachment format	2018-05-10	2020-04-21	1	@NegativeMjark
1207	Publishing Room Lists for 3rd party networks	2018-05-10	2020-04-21	1	@erikjohnston
1205	Proposal for multi-device deletion API	2018-05-10	2020-04-21	1	@richvdh
1204	Access Token Semantics (refresh and macaroons) - aka Auth Sept 2016 Edition	2018-05-10	2020-04-21	1	@richvdh
1203	3rd Party Entity lookup API	2018-05-10	2020-04-21	1	@leonerd
1201	Device Management API	2018-05-10	2020-04-21	1	@richvdh
1200	Configuration of E2E encryption in a room	2018-05-10	2020-04-21	1	@richvdh
1199	Notifications API	2018-05-10	2018-06-25	1	@dbkr
1197	Ignoring Users	2018-05-10	2020-04-21	1	@erikjohnston
1183	Document key-share requests	2018-04-30	2020-04-21	1	@richvdh
1067	Spec @mentions	2017-11-14	2020-04-21	1	@lukebarnard1
1033	Doc @room notifications	2017-10-23	2020-04-21	1	@dbkr
953	Add /user_directory/search API	2017-07-18	2020-04-21	1	@erikjohnston
910	Add new Read Marker API to docs	2017-05-08	2020-04-21	1	@lukebarnard1
855	spec m.login.msisdn UI auth type	2017-03-24	2020-04-21	1	@dbkr
829	Need to spec msisdn login API	2017-03-08	2020-04-21	1	@dbkr
739	Reporting inappropriate content in Matrix	2016-11-21	2020-04-21	1	@ara4n
688	Room Summaries (was: Calculate room names server-side)	2016-07-12	2022-03-01	1	@ara4n
433	Support for discovering API endpoints via .well-known URIs (SPEC-121)	2015-03-08	2022-03-01	1, 2	@maxidor, @thers	@uhoreg

Postponed

No MSCs are currently in this state.

Abandoned

MSC	Title	Created at	Updated at	Docs	Author
4415	MSC4415: Make `/_matrix/client/v3/admin/whois/{userId}` only available to admins	2026-02-04	2026-02-04		@velikopter
4113	MSC4113: Image hashes in Policy Lists	2024-02-24	2025-06-17		@MTRNord
4098	MSC4098: Use the SCIM protocol for provisioning	2024-02-09	2025-11-24		@azmeuk
3978	MSC3978: Deprecate room tagging	2023-03-15	2023-03-16		@uhoreg
3523	MSC3523: Timeboxed/ranged relations endpoint	2021-11-23	2023-06-01		@turt2live
3137	MSC3137: Define space room type, subset of MSC1772	2021-04-20	2021-04-29		@t3chguy
3125	MSC3125: Limits API — Part 5: per-Instance limits	2021-04-15	2021-08-27		@erkinalp
3074	MSC3074: Proposal for URIs conforming to RFC 3986 syntax.	2021-03-25	2021-03-29		@alexmingoia
3068	[WIP] MSC3068: Compliance tiers	2021-03-18	2021-03-23		@erkinalp
3053	MSC3053: Limits API — Part 2: per-Room limits	2021-03-07	2021-08-27		@erkinalp
3007	MSC3007: Forced insertion and room blocking by self-banning	2021-02-14	2021-02-20		@erkinalp
3005	MSC3005: Streaming Federation Events	2021-02-10	2022-10-21		@ShadowJonathan
2912	MSC2912: Setting cross-signing keys during registration	2020-12-15	2020-12-17		@uhoreg
2810	MSC2810: Consistent globs specification	2020-10-08	2022-03-01		@turt2live
2773	MSC2773: Room kinds	2020-09-11	2021-02-27		@turt2live
2771	MSC2771: Bookmarks	2020-09-10	2022-05-23		@MTRNord
2631	MSC2631: Add `default_payload` to PusherData	2020-06-12	2020-07-07		@ismailgulek
2625	MSC2625: Add `mark_unread` push rule action	2020-06-10	2020-07-01		@richvdh
2579	MSC2579: Improved tagging support	2020-05-25	2020-07-24		@turt2live
2376	MSC2376: Disable URL Previews	2019-12-03	2021-01-14		@Sorunome
2314	MSC2314: A Method to Backfill Room State	2019-10-07	2022-04-14		@hawkowl
2233	MSC2233: Unauthenticated Capabilities API	2019-08-15	2020-04-20		@anoadragon453
1935	MSC1935: Key validity enforcement	2019-03-20	2020-04-20		@turt2live
1722	MSC1722: Support for displaying math(s) in messages	2018-11-15	2020-10-19		@uhoreg
1714	MSC1714: using the TLS private key to sign federation-signing keys	2018-11-09	2022-03-01		@richvdh
1700	MSC1700: Improving .well-known discovery	2018-10-19	2022-04-14		@turt2live
1680	MSC1680: cross-signing of devices to simplify key verification	2018-09-20	2020-04-20	1	@uhoreg
1489	Suggested Mentions Proposal	2018-08-06	2020-04-21		@Half-Shot
1217	Visibility of groups to group members and their non-members	2018-05-10	2020-08-21	1	@lampholder
1213	Set defaults for m.federate	2018-05-10	2020-08-26	1	@psaavedra
1209	Server Side Profile API	2018-05-10	2020-08-21	1	@erikjohnston
531	Homeservers as OAuth authorization endpoints (resource owners) (SPEC-206)	2015-07-25	2020-08-21	1	@Kegsay

Obsolete

MSC	Title	Created at	Updated at	Docs	Author	Shepherd
4384	MSC4384: Supporting alternative room directory sorting	2025-11-26	2026-02-17		@turt2live
4347	MSC4347: Emoji verification images	2025-09-09	2026-01-22		@andybalaam
4324	MSC4324: Fixing MSC4289's power level for tombstones	2025-08-06	2025-08-07		@turt2live
4301	MSC4301: Event capability negotiation between clients	2025-06-16	2026-02-09		@Johennes
4281	MSC4281: Mitigating Membership Mistakes, or "Invisible" Cryptography	2025-04-01	2025-04-02		@uhoreg
4276	MSC4276: Soft unfailure for self redactions	2025-03-20	2025-06-28		@matrix-org/trust-safety	@matrix-org/trust-safety
4124	MSC4124: Simple Server Authorization	2024-04-09	2025-12-11		@Gnuxie
4052	MSC4052: Hiding read receipts UI in certain rooms	2023-09-06	2023-10-06		@cloudrac3r
3903	MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients	2022-10-04	2024-04-30		@hughns
3886	MSC3886: Simple client rendezvous capability	2022-09-07	2024-04-30		@hughns
3862	MSC3862: event_match (almost) anything	2022-08-05	2023-02-06		@Johennes
3859	MSC3859: Add well known media domain proposal	2022-08-04	2022-08-17		@Fizzadar
3517	MSC3517: "Mention" Pushrule	2021-11-21	2023-01-08		@ShadowJonathan
3510	MSC3510: Let users kick/ban/demote each other	2021-11-20	2022-10-24		@ara4n
3282	MSC3282: Expose enable_set_displayname in capabilities response	2021-07-13	2021-07-19		@JonasKress
3226	MSC3226: Per-room spell check	2021-05-31	2021-08-30		@afranke
3067	MSC3067: Prevent/remove legacy groups from being in the spec	2021-03-18	2021-05-01		@turt2live
2876	MSC2876: Allowing widgets to read events in a room	2020-11-24	2021-05-14		@turt2live
2775	MSC2775: Lazy loading over federation	2020-09-14	2022-10-18		@ara4n
2703	MSC2703: Media ID grammar	2020-07-28	2022-10-12		@turt2live
2589	MSC2589: Improve replies	2020-05-29	2022-03-01		@turt2live
2516	MSC2516: Add a new message type for voice messages	2020-04-27	2021-12-27		@ludwigbald
2475	MSC2475: API versioning	2020-03-27	2021-09-20		@turt2live
2390	MSC2390: On the EDU-to-PDU transition.	2019-12-18	2022-04-26		@jevolk
2389	MSC2389: Toward the EDU-to-PDU transition: Typing.	2019-12-18	2022-04-26		@jevolk
2261	MSC2261: Allow `m.room.aliases` events to be redacted by room admins	2019-08-29	2020-04-20		@richvdh
2260	MSC2260: Update the auth rules for `m.room.aliases` events	2019-08-29	2022-03-01		@richvdh
2229	MSC2229: Allowing 3PID Owners to Rebind	2019-08-12	2020-04-20		@anoadragon453
1943	MSC1943: Set default room as v3	2019-03-27	2020-04-20		@neilisfragile
1888	[WIP] MSC1888: Proposal to send EDUs to appservices	2019-02-15	2022-03-01		@Half-Shot
1849	MSC1849: Proposal for m.relates_to aggregations	2019-02-04	2022-11-08		@ara4n
1777	[WIPish] MSC1777: peeking over federation (via server pseudousers)	2019-01-06	2020-10-28		@ara4n
1776	[WIPish] MSC1776: Implementing peeking via /sync	2019-01-06	2020-09-05		@ara4n
1731	MSC1731: Mechanism for redirecting to an alternative server during SSO login	2018-11-24	2020-04-20		@richvdh
1703	MSC1703: encrypting recovery keys for online megolm backups	2018-10-23	2021-06-08		@dbkr
3793	Future Proposal for Cryptographic Challenge Login Flow and E2E Key Backup Recovery	2018-10-18	2022-07-19	1	@ara4n
1695	MSC1695 Message Edits	2018-10-12	2022-03-01		@Half-Shot
1687	MSC1687: Encrypting recovery keys for online megolm backups	2018-09-26	2022-11-08	1	@ara4n
1421	Make a Discourse forum the canonical location for spec discussions	2018-07-16	2020-04-21	1	@non-Jedi
1410	Proposal for Rich Bridging	2018-07-12	2020-04-21	1	@Half-Shot
1324	Custom protocol definitions for application services	2018-06-20	2018-08-30	1	@anoadragon453
3808	Mechanism to communicate 3PID binding updates or deletions to homeservers	2018-06-20	2023-05-13	1	@babolivier
1318	Proposal for Open Governance of Matrix.org	2018-06-20	2020-04-21	1	@ara4n
1310	Proposal for a media information API	2018-06-17	2022-03-01	1	@turt2live
1308	Proposal for speeding up review of simple spec changes	2018-06-14	2022-05-09		@ara4n
3805	Proposal for improving authorization for the matrix profile API	2018-06-13	2024-08-14	1	@turt2live
3804	Mechanisms for communicating erasure requests to bots and federated homeservers	2018-06-05	2022-07-19	1	@richvdh
1270	Proposal Add /_matrix/media/v1/resolve_url to Client-Server API: download and preview urls in the clients despite CORS	2018-05-31	2022-03-01	1	@oivoodoo
1256	Custom emoji and sticker packs in matrix	2018-05-23	2021-07-28	1	@turt2live
1231	Handling Consent for Privacy Policy	2018-05-10	2022-03-01	1	@neilisfragile
1226	State Reset mitigation proposal	2018-05-10	2020-04-21	1	@richvdh
1225	Extensible event types & fallback in Matrix	2018-05-10	2019-01-03	1	@ara4n
1224	Replies - next steps	2018-05-10	2020-04-21	1	@t3chguy
1223	Replies event format	2018-05-10	2020-04-21	1	@t3chguy
1222	Pushing updates about Groups (Communities) to clients	2018-05-10	2021-04-11	1	@ara4n
1220	Rich quoting proposal	2018-05-10	2020-04-21	1	@t3chguy
1215	Groups as Rooms	2018-05-10	2020-04-21	1	@ara4n
1214	Related Groups (i.e. flair)	2018-05-10	2021-05-01	1	@lukebarnard1
1202	Profile Personae	2018-05-10	2020-04-21	1	@erikjohnston
1196	Matrix Escape Hatch (Versioned Rooms)	2018-05-10	2020-04-21	1	@leonerd
1194	A way for HSes to remove bindings from ISes (aka unbind)	2018-05-09	2020-04-21	1	@dbkr
1116	Spec a format for calendar events in rooms.	2018-02-06	2022-03-02		@Half-Shot
971	Add groups stuff to spec	2017-08-10	2022-11-08		@erikjohnston
441	Support for Reactions / Aggregations	2015-03-29	2020-04-21	1	@pik	@ara4n
455	Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5)	2014-09-15	2020-04-21	1	@KitsuneRal

Spec Change Proposals

Guiding Principles

Technical notes

Process

Lifetime States

Categories

Implementing a proposal

Early release of an MSC/idea

Unstable endpoints, features and vendor prefixes

Placeholder MSCs

Proposal Tracking

Work In Progress

Proposal In Review

Proposed Final Comment Period

Final Comment Period

Finished Final Comment Period

Spec PR Missing

Spec PR In Review

Merged

Postponed

Abandoned

Obsolete