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.
  • 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. Where it’s unclear if an MSC will require an implementation proof, ask in #matrix-spec:matrix.org.

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.
    • When using unstable endpoints, they MUST include a vendor prefix. For example: /_matrix/client/unstable/com.example/login. Vendor prefixes throughout Matrix always use the Java package naming convention. The MSC for the feature should identify which preferred vendor prefix is to be used by early adopters.
    • Note that unstable namespaces do not automatically inherit endpoints from stable namespaces: for example, the fact that /_matrix/client/r0/sync exists does not imply that /_matrix/client/unstable/com.example/sync exists.
    • If the client needs to be sure the server supports the feature, an unstable feature flag that MUST be vendor prefixed is to be used. This kind of flag shows up in the unstable_features section of /versions as, for example, com.example.new_login. The MSC for the feature should identify which preferred feature flag is to be used by early adopters.
    • When using this approach correctly, the implementation can ship/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.
  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 (for example, for an endpoint, moving from /unstable/org.matrix.mscxxxx/frobnicate to /v1/frobnicate), 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 foundation’s preferred vendor prefix is org.matrix.
  • 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.

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 necessary 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
3981 MSC3981: `/relations` recursion 2023-03-19 2023-03-21 @justjanne
3975 MSC3975: rel_type for Replies 2023-03-08 2023-03-09 @imbev
3964 MSC3964: Notifications for room tags 2023-02-03 2023-02-03 @clokep
3956 [WIP] MSC3956: Extensible Events - Encrypted Events 2023-01-13 2023-02-12 @turt2live
3953 MSC3953: Server capability DAG 2023-01-07 2023-01-08 @Gnuxie
3948 MSC3948: Repository room for Thirdroom 2022-12-14 2022-12-15 @ajbura
3944 MSC3944: Dropping stale send-to-device messages 2022-12-06 2023-02-27 @uhoreg
3935 MSC3935: Cute Events against social distancing 2022-11-16 2023-02-20 @TheOneWithTheBraid
3924 MSC3924: Capability-style access control for Matrix media 2022-11-03 2022-11-15 @cvwright
3909 MSC3909: Membership based mutes 2022-10-13 2023-03-21 @FSG-Cat
3902 MSC3902: Faster remote room joins over federation (overview) 2022-10-03 2023-03-13 @richvdh
3901 MSC3901: Deleting state 2022-09-28 2023-03-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
3888 MSC3888: Voice Broadcast 2022-09-09 2022-12-27 @weeman1337
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 @aMySour
3870 MSC3870: Async media upload extension: upload to URL 2022-08-17 2022-08-31 @Fizzadar
3868 [WIP] MSC3868: Room Contribution 2022-08-15 2022-08-18 @jae1911
3865 [WIP] MSC3865: User-given attributes for users 2022-08-09 2022-08-16 @Zocker1999NET
3864 [WIP] MSC3864: User-given attributes for rooms 2022-08-07 2022-08-09 @Zocker1999NET
3861 MSC3861: Matrix architecture change to delegate authentication via OIDC 2022-08-04 2023-03-16 @hughns
3849 MSC3849: Observations and Reinforcement 2022-07-19 2022-10-18 @Gnuxie
3842 [WIP] MSC3842: Placeholder for power levels & extensible events 2022-07-02 2022-07-02 @turt2live
3839 MSC3839: primary-identity-as-key 2022-06-26 2022-12-15 @zander
3821 MSC3821: Update the redaction rules, again 2022-05-20 2022-06-29 @turt2live
3820 MSC3820: Room version 11 2022-05-20 2022-05-20 @turt2live
3815 [WIP] MSC3815: 3D Worlds 2022-05-13 2022-05-17 @robertlong
3814 [WIP] MSC3814: Dehydrated devices with SSSS 2022-05-12 2023-02-16 @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
3761 MSC3761: State event change control 2022-03-31 2022-04-05 @turt2live
3755 MSC3755: Member pronouns 2022-03-18 2022-11-15 @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
3588 WIP: MSC3588: Encrypted Stories As Rooms 2021-12-23 2022-08-11 @krillefear
3414 [WIP] MSC3414: Encrypted state events 2021-09-27 2023-03-01 @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 2021-12-29 @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 2023-03-17 @Yoric
3192 MSC3192: Batch state endpoint 2021-05-12 2021-08-30 @clokep
3189 MSC3189: Per-room/per-space profiles 2021-05-11 2022-11-20 @robintown
3184 MSC3184: Challenges Messages 2021-05-10 2021-08-30 @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 2021-08-30 @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 2022-03-03 @ara4n
2967 [WIP] MSC2967: OIDC API scopes 2021-01-14 2023-03-03 @sandhose
2966 [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix 2021-01-14 2023-03-03 @sandhose
2964 [WIP] MSC2964: Delegation of auth from homeserver to OpenID Provider 2021-01-14 2023-03-20 @sandhose
2957 [WIP] MSC2957: Cryptographically Concealed Credentials 2021-01-11 2022-03-28 @uhoreg
2923 MSC2923: Connect Matrix room to another Matrix room 2020-12-22 2021-10-13 @MadLittleMods
2883 MSC2883: [WIP] Matrix-flavoured MLS 2020-11-27 2021-08-30 @uhoreg
2882 MSC2882: [WIP] Tempered Transitive Trust 2020-11-27 2022-10-05 @uhoreg
2812 [WIP] MSC2812: Role-based power/permissions 2020-10-08 2022-11-12 @turt2live
2802 [WIP] MSC2802: Full Room Abstraction 2020-10-05 2021-08-30 @ShadowJonathan
2787 MSC2787: Portable Identities 2020-09-23 2023-03-02 @neilalexander
2783 MSC2783: Homeserver Migration Data Format 2020-09-19 2022-03-01 @ShadowJonathan
2745 [WIP] MSC2745 : Add hCaptcha as captcha provider 2020-08-20 2022-03-01 @Morpheus0x
2706 [WIP] MSC2706: IPFS as a media repository for Matrix 2020-07-28 2022-07-08 @turt2live
2697 [WIP] MSC2697: Device dehydration 2020-07-24 2022-10-26 @uhoreg
2438 [WIP] MSC2438: Local and Federated User Erasure Requests 2020-02-19 2021-08-30 @anoadragon453
2370 [WIP] MSC2370: Resolve URL API 2019-11-29 2021-08-30 @uhoreg
2306 [WIP] MSC2306: Removing MSISDN password resets 2019-09-24 2022-03-01 @turt2live
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
2271 [WIP] MSC2271 TOTP 2FA login 2019-08-31 2021-08-30 @ara4n
1956 [WIP] MSC1956: Integrations API (base) 2019-04-08 2022-10-16 @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 2022-10-10 @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
1228 [WIP] MSC1228: Removing MXIDs from events 2018-05-10 2023-01-19 @benparsons

Proposal In Review

MSC Title Created at Updated at Docs Author Shepherd
3982 MSC3982: Limit maximum number of events sent to an AS 2023-03-21 2023-03-21 @Half-Shot
3979 MSC3979: Revised feature profiles 2023-03-15 2023-03-16 @uhoreg
3977 MSC3977: Matrix as a Messaging Framework (IETF/MIMI) 2023-03-13 2023-03-13 @turt2live
3973 MSC3973: Search users in the user directory with the Widget API 2023-03-01 2023-03-16 @dhenneke
3972 MSC3972: Lexicographical strings as an ordering mechanism 2023-02-26 2023-03-02 @Dominaezzz
3971 MSC3971: Sharing image packs 2023-02-25 2023-03-11 @AndrewRyanChama
3970 MSC3970: Scope transaction IDs to devices 2023-02-23 2023-03-14 @hughns
3969 MSC3969: Size limits 2023-02-18 2023-03-04 @progval
3968 MSC3968: Poorer features 2023-02-18 2023-03-13 @progval
3963 MSC3963: Oblivious Matrix over HTTPS 2023-02-03 2023-03-10 @ghost-amnesiac
3961 MSC3961: Sliding Sync Extension: Typing Notifications 2023-01-30 2023-02-27 @kegsay
3960 MSC3960: Sliding Sync Extension: Receipts 2023-01-30 2023-02-28 @kegsay
3959 MSC3959: Sliding Sync Extension: Account Data 2023-01-30 2023-02-28 @kegsay
3955 MSC3955: Extensible Events - Automated event mixin (notices) 2023-01-13 2023-02-20 @turt2live
3954 MSC3954: Extensible Events - Text Emotes 2023-01-13 2023-01-13 @turt2live
3949 MSC3949: Power Level Tags 2022-12-14 2022-12-26 @ajbura
3947 MSC3947: Allow Clients to Request Searching the User Directory Constrained to Only Homeserver-Local Users 2022-12-11 2022-12-14 @marcusmueller
3946 MSC3946: Dynamic room predecessor 2022-12-09 2023-03-17 @MadLittleMods
3939 MSC3939: Account locking 2022-11-24 2022-11-28 @babolivier
3934 MSC3934: Bulk push rules change endpoint 2022-11-15 2022-12-12 @turt2live
3933 MSC3933: Core push rules for Extensible Events 2022-11-15 2023-01-17 @turt2live
3932 MSC3932: Extensible events room version push rule feature flag 2022-11-15 2023-02-28 @turt2live
3931 MSC3931: Push rule condition for room version features 2022-11-15 2022-11-15 @turt2live
3930 MSC3930: Polls push rules/notifications 2022-11-14 2023-01-20 @turt2live
3927 MSC3927: Extensible Events - Audio 2022-11-13 2022-11-18 @turt2live
3926 MSC3926: Disable server-default notifications for bot users by default 2022-11-08 2022-11-10 @Half-Shot
3922 MSC3922: Removing SRV records from homeserver discovery 2022-11-01 2023-03-06 @turt2live
3919 MSC3919: Matrix Message Format (IETF/MIMI) 2022-10-28 2022-10-28 @turt2live
3918 MSC3918: Matrix Message Transport (IETF/MIMI) 2022-10-28 2022-10-28 @turt2live
3917 MSC3917: Cryptographically Constrained Room Membership 2022-10-25 2022-12-27 @duxovni
3916 MSC3916: Authentication for media 2022-10-23 2023-03-10 @richvdh
3915 MSC3915: Owner power level 2022-10-23 2022-12-11 @ara4n
3914 MSC3914: Matrix native group call push rule 2022-10-20 2022-11-11 @SimonBrandner
3912 MSC3912: Relation-based redactions 2022-10-18 2023-03-20 @babolivier
3911 MSC3911: Linking media to events 2022-10-16 2023-03-10 @richvdh
3908 MSC3908: Expiring Policy List Recommendations 2022-10-13 2022-10-18 @FSG-Cat
3907 MSC3907: Mute Policy Recommendation 2022-10-13 2022-10-13 @FSG-Cat
3906 MSC3906: Mechanism to allow sign in and E2EE set up via QR code 2022-10-13 2023-03-16 @hughns
3903 MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients 2022-10-04 2023-03-15 @hughns
3896 MSC3896: Appservice media 2022-09-24 2022-11-27 @tezlm
3892 MSC3892: Custom Emotes with Encryption 2022-09-14 2022-09-23 @nmscode
3890 MSC3890: Remotely silence local notifications 2022-09-13 2023-02-20 @kerryarchibald
3886 MSC3886: Simple client rendezvous capability 2022-09-07 2023-03-15 @hughns
3885 MSC3885: Sliding Sync Extension: To-Device messages 2022-09-07 2023-03-01 @kegsay
3884 MSC3884: Sliding Sync Extension: E2EE 2022-09-06 2023-03-01 @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-01-18 @uhoreg
3874 MSC3874: Filtering threads from the /messages endpoint 2022-08-23 2022-12-09 @justjanne
3871 MSC3871: Gappy timelines 2022-08-18 2023-03-16 @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
3860 MSC3860: Add media download redirect proposal 2022-08-04 2022-10-27 @Fizzadar
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
3847 MSC3847: Ignoring invites with policy rooms 2022-07-13 2022-12-04 @Yoric
3846 MSC3846: Allowing widgets to access TURN servers 2022-07-13 2022-08-01 @robintown
3845 MSC3845: Draft: Expanding policy rooms to reputation 2022-07-12 2022-12-22 @Yoric
3843 MSC3843: Reporting content over federation 2022-07-11 2023-03-03 @turt2live
3840 MSC3840: Ignore invites 2022-06-28 2022-07-13 @Yoric
3837 MSC3837: Cascading profile tags for push rules 2022-06-23 2023-03-03 @Johennes
3834 MSC3834: Opportunistic user key pinning (TOFU) 2022-06-14 2022-09-30 @duxovni
3825 MSC3825: Obvious relation fallback location 2022-05-24 2022-10-12 @deepbluev7
3824 MSC3824: OIDC aware clients 2022-05-24 2023-03-03 @hughns
3823 MSC3823: A code for account suspension 2022-05-23 2022-12-21 @Yoric
3819 MSC3819: Allowing widgets to send/receive to-device messages 2022-05-19 2023-02-21 @turt2live
3817 MSC3817: Allow widgets to create rooms 2022-05-17 2022-08-05 @dhenneke
3784 MSC3784: Using room type of `m.policy` for policy rooms 2022-04-25 2022-11-27 @FSG-Cat
3782 MSC3782: Matrix public key login spec 2022-04-21 2022-10-21 @tak-hntlabs
3780 MSC3780: Knocking on `action=join` 2022-04-20 2022-08-05 @ShadowJonathan
3779 MSC3779: "Owned" State Events 2022-04-20 2022-05-29 @andybalaam
3768 MSC3768: Push rule action for in-app notifications 2022-04-08 2023-03-03 @Johennes
3767 MSC3767: Time based notification filtering 2022-04-07 2022-05-05 @kerryarchibald
3765 MSC3765: Rich text in room topics 2022-04-03 2023-02-28 @Johennes
3759 MSC3759: Leave event metadata for deactivated users 2022-03-31 2022-04-24 @Half-Shot
3757 MSC3757: Restricting who can overwrite a state event 2022-03-25 2023-02-12 @andybalaam
3754 MSC3754: Removing profile information 2022-03-12 2022-05-05 @zecakeh
3751 MSC3751: Allowing widgets to read account data 2022-03-05 2022-05-05 @AndrewRyanChama
3746 MSC3746: Render image data in reactions 2022-02-25 2022-09-05 @AndrewRyanChama
3744 MSC3744: Support for flexible authentication 2022-02-24 2022-05-05 @cvwright
3741 MSC3741: Revealing the useful login flows to clients after a soft logout 2022-02-23 2022-05-05 @turt2live
3735 MSC3735: Add device information to m.room_key.withheld message 2022-02-18 2022-05-05 @uhoreg
3725 MSC3725: Content warnings 2022-02-14 2022-10-07 @robintown
3723 MSC3723: Federation `/versions` 2022-02-11 2022-07-14 @ShadowJonathan
3720 MSC3720: Account status 2022-02-09 2022-09-01 @babolivier
3713 MSC3713: Alleviating ACL exhaustion with ACL Slots 2022-02-06 2022-05-05 @FSG-Cat
3682 MSC3682: Sending Account Data to Application Services 2022-01-28 2022-11-18 @reivilibre
3673 MSC3673: Encrypted ephemeral data units 2022-01-25 2022-05-06 @stefanceriu @anoadragon453
3672 MSC3672: Sharing ephemeral streams of location data 2022-01-25 2022-05-09 @stefanceriu @anoadragon453
3664 MSC3664: Pushrules for relations 2022-01-21 2022-12-07 @deepbluev7
3659 MSC3659: Invite Rules 2022-01-19 2022-11-19 @joshqou
3644 MSC3644: Extensible Events: Edits and replies 2022-01-14 2022-05-05 @turt2live
3635 MSC3635: Early Media for VoIP 2022-01-10 2022-05-05 @dbkr
3618 MSC3618: Add proposal to simplify federation `/send` response 2022-01-04 2022-05-05 @neilalexander
3593 MSC3593: Safety Controls through a generic Administration API 2021-12-25 2022-05-16 @ShadowJonathan
3575 MSC3575 Sliding Sync (aka Sync v3) 2021-12-20 2023-03-16 @kegsay
3574 MSC3574: Marking up resources 2021-12-18 2022-06-07 @gleachkr
3572 MSC3572: Relation aggregation cleanup 2021-12-16 2022-05-05 @bwindels
3571 MSC3571: Relation aggregation pagination 2021-12-16 2022-05-05 @bwindels
3570 MSC3570: Room history visibility changes for relations 2021-12-15 2022-05-05 @bwindels
3554 MSC3554: Extensible Events - Translatable Text 2021-12-07 2023-02-10 @turt2live
3553 MSC3553: Extensible Events - Videos 2021-12-07 2022-11-14 @turt2live
3552 MSC3552: Extensible Events - Images and Stickers 2021-12-07 2023-01-21 @turt2live
3551 MSC3551: Extensible Events - Files 2021-12-07 2023-03-16 @turt2live
3548 MSC3547: Allow appservice bot user to read any rooms the appservice is part of 2021-12-06 2022-05-05 @Half-Shot
3531 MSC3531: Letting moderators hide messages pending moderation 2021-11-26 2023-03-20 @Yoric
3523 MSC3523: Timeboxed/ranged relations endpoint 2021-11-23 2022-05-05 @turt2live
3489 MSC3489: Sharing streams of location data with history 2021-11-14 2023-01-05 @ara4n
3488 MSC3488: Extending events with location data 2021-11-14 2022-07-08 @ara4n
3480 MSC3480: Make device names private 2021-11-09 2023-01-02 @uhoreg
3469 MSC3469: Mandate HTTP Range on Content Repository Endpoints 2021-11-03 2022-05-05 @ShadowJonathan
3468 MSC3468: MXC to Hashes 2021-11-03 2022-05-05 @ShadowJonathan
3464 MSC3464: Allow Users to Post on Behalf of Other Users 2021-10-29 2022-05-05 @sumnerevans
3417 MSC3417: Call room room type 2021-09-30 2022-07-05 @SimonBrandner
3401 MSC3401: Native Group VoIP Signalling 2021-09-19 2023-02-06 @ara4n
3395 MSC3395: Synthetic appservice events 2021-09-14 2021-12-14 @Half-Shot
3394 MSC3394: New auth rule that only allows someone to post a message in relation to another message 2021-09-12 2022-05-05 @frandavid100
3391 MSC3391: API to delete account data 2021-09-09 2023-02-28 @ShadowJonathan
3389 MSC3389: Relation redactions 2021-09-09 2022-12-19 @bwindels
3386 MSC3386: Unified Join Rules 2021-09-07 2022-05-10 @kevincox
3382 MSC3382: Inline message Attachments 2021-09-07 2022-11-28 @MurzNN
3381 MSC3381: Polls (mk II) 2021-09-07 2023-03-17 @turt2live
3368 MSC3368: Message Content Tags 2021-08-28 2021-11-26 @0x1a8510f2
3360 MSC3360: Server Status 2021-08-25 2022-05-05 @daenney
3356 MSC3356: Add additional OpenID user info fields 2021-08-24 2022-11-17 @jkanefendt
3338 MSC3338: Adding iframe specifics to preview json 2021-08-13 2022-05-05 @srdjan-catalyst
3325 MSC3325: Upgrading invite-only rooms 2021-08-10 2021-08-30 @uhoreg
3309 MSC3309: Simple counters 2021-08-03 2022-07-15 @erikjohnston
3291 MSC3291: Muting in VoIP calls 2021-07-22 2023-01-10 @SimonBrandner
3277 WIP: MSC3277: Scheduled messages 2021-07-10 2023-01-05 @ara4n
3270 MSC3270: Symmetric megolm backup 2021-07-07 2022-12-28 @uhoreg
3266 MSC3266: Room summary API 2021-07-04 2022-12-31 @deepbluev7
3255 MSC3255: Use SRV record for homeservers discovery by clients 2021-06-21 2022-07-31 @Berbe
3246 MSC3246: Audio waveform for extensible events 2021-06-15 2022-11-14 @turt2live
3245 MSC3245: Voice messages (using extensible events) 2021-06-15 2022-11-13 @turt2live
3244 MSC3244: Room version capabilities 2021-06-15 2022-07-12 @BillCarsonFr
3230 MSC3230: Spaces top level order 2021-06-03 2023-03-02 @BillCarsonFr
3217 MSC3217: Soft kicks 2021-05-25 2022-05-05 @Half-Shot
3216 MSC3216: Synchronized access control for Spaces 2021-05-24 2022-05-05 @joepie91
3214 MSC3214: Allow overriding `m.room.power_levels` using `initial_state` 2021-05-24 2022-05-05 @tulir
3202 MSC3202: Encrypted appservices 2021-05-18 2023-01-13 @turt2live
3174 MSC3174: An error code for spam rejections 2021-05-04 2022-05-05 @Yoric
3160 MSC3160: Message timezone markup 2021-04-30 2022-05-05 @bwindels
3144 MSC3144: Allow Widgets By Default in Private Rooms 2021-04-23 2022-05-05 @dbkr
3131 MSC3131: Verifying with QR codes v2 2021-04-16 2022-05-05 @uhoreg
3124 MSC3124: Handling spoilers in plain-text message fallback 2021-04-15 2022-05-05 @xenofem
3105 MSC3105: Previewing UIA flows 2021-04-06 2022-05-05 @turt2live
3086 MSC3086: Asserted identity on VoIP calls 2021-04-01 2022-05-05 @dbkr
3079 MSC3079: Low Bandwidth CS API 2021-03-30 2023-02-15 @kegsay
3077 MSC3077: Support for multi-stream VoIP 2021-03-29 2022-07-29 @SimonBrandner
3061 MSC3061: Sharing room keys for past messages 2021-03-12 2023-01-24 @uhoreg
3060 MSC3060: Room labels 2021-03-12 2022-05-05 @babolivier
3051 MSC3051: A scalable relation format 2021-03-05 2022-05-05 @deepbluev7
3038 MSC3038: Typed typing notifications 2021-03-02 2022-07-11 @turt2live
3026 MSC3026: "busy" presence state 2021-02-23 2023-03-03 @babolivier
3015 MSC3015: Room state personal overrides 2021-02-19 2023-03-06 @MurzNN
3014 MSC3014: HTTP Pushers for the full event with extra rooms information 2021-02-18 2022-05-05 @Sorunome
3012 MSC3012: Post-registration terms of service API 2021-02-17 2022-05-05 @turt2live
3009 MSC3009: Websocket transport for client <--> widget communications 2021-02-15 2022-05-05 @turt2live
3008 MSC3008: Scoped access for widgets 2021-02-15 2022-05-05 @turt2live
2997 MSC2997: Add t-shirt 2021-02-07 2022-10-01 @Sorunome
2974 MSC2974: Widgets: Capabilities re-exchange 2021-01-19 2022-05-05 @turt2live
2970 MSC2970: Remove pusher path requirement 2021-01-17 2022-05-05 @Sorunome
2965 MSC2965: OIDC Provider discovery 2021-01-14 2023-03-03 @sandhose
2962 MSC2962: Managing power levels via Spaces 2021-01-14 2022-05-05 @ara4n
2961 MSC2961: External Signatures 2021-01-13 2022-05-05 @Sorunome
2949 MSC2949: Proposal to clarify "Requires auth" and "Rate-limited" in the spec 2021-01-07 2022-05-05 @tulir
2943 MSC2943: Return an event ID for membership endpoints 2021-01-07 2022-07-19 @turt2live
2938 MSC2938: Report content to moderators 2021-01-05 2022-07-17 @Yoric
2931 MSC2931: Allow widgets to navigate with matrix.to URIs 2020-12-29 2022-05-05 @turt2live
2895 MSC2895: Proposal to improve /members and /joined_rooms 2020-12-07 2022-05-05 @turt2live
2881 MSC2881: Message Attachments 2020-11-27 2022-10-13 @MurzNN
2873 MSC2873: Identifying clients and user settings in widgets 2020-11-23 2022-05-05 @turt2live
2872 MSC2872: Move the widget title to the top level of the definition 2020-11-23 2022-05-05 @turt2live
2871 MSC2871: Give widgets an indication of which capabilities they were approved for 2020-11-20 2022-05-05 @turt2live
2870 MSC2870: Protect server ACLs from redaction 2020-11-20 2022-05-05 @turt2live
2867 MSC2867: Marking rooms as unread 2020-11-17 2022-05-05 @Bubu
2855 MSC2855: Server-Initiated Client Clear-Cache & Reload 2020-11-08 2022-05-05 @jevolk
2848 MSC2848: Globally unique event IDs 2020-11-04 2022-05-05 @turt2live
2846 MSC2846: Decentralizing media through CIDs 2020-11-02 2022-05-05 @jcgruenhage
2845 MSC2845: Phone number lookups using third party API 2020-11-02 2022-05-05 @dbkr
2839 MSC2839: Dynamic User-Interactive Authentication 2020-10-29 2022-05-05 @Sorunome
2836 MSC2836: Twitter-style Threading 2020-10-28 2022-10-28 @kegsay
2835 MSC2835: Add UIA to the /login endpoint 2020-10-28 2022-05-05 @Sorunome
2828 MSC2828: Proposal to restrict allowed user IDs over federation 2020-10-20 2022-05-05 @tulir
2815 MSC2815: Proposal to allow room moderators to view redacted event content 2020-10-10 2022-05-05 @tulir
2813 MSC2813: Widget API error handling and validation 2020-10-09 2022-05-05 @turt2live
2790 MSC2790: Modal widgets (acquiring user input from a widget) 2020-09-24 2022-05-05 @turt2live
2785 MSC2785: Event notification attributes and actions 2020-09-20 2022-05-05 @richvdh
2782 MSC2782: Pushers with the full event content 2020-09-19 2022-05-05 @Sorunome
2781 MSC2781: Remove the reply fallbacks from the specification 2020-09-18 2023-03-10 @deepbluev7
2772 MSC2772: Notifications for Jitsi Calls 2020-09-11 2022-05-05 @dbkr
2762 MSC2762: Allowing widgets to send/receive events 2020-09-02 2023-02-13 @turt2live
2757 MSC2757: Sign Events 2020-09-01 2022-05-05 @Sorunome
2755 MSC2755: Lazy load rooms 2020-08-31 2022-05-05 @deepbluev7
2753 MSC2753: Peeking via sync (take 2) 2020-08-29 2022-05-22 @ara4n
2749 MSC2749: Per-user E2EE on/off setting 2020-08-25 2022-05-05 @KB1RD
2747 MSC2747: VoIP call transfers 2020-08-21 2023-02-06 @dbkr
2730 MSC2730: Verifiable forwarded events 2020-08-12 2022-05-05 @tulir
2723 MSC2723: Forwarded message metadata 2020-08-12 2022-12-22 @hummlbach
2716 MSC2716: Incrementally importing history into existing rooms 2020-08-04 2023-03-16 @ara4n
2705 MSC2705: Animated thumbnails for media (and thumbnail content-type requirements) 2020-07-28 2022-05-05 @turt2live
2704 MSC2704: Explicitly allow alternative origins in MXC URIs and specify deduplication requirements on uploads 2020-07-28 2022-05-05 @turt2live
2702 MSC2702: Specifying semantics for Content-Disposition on media 2020-07-28 2022-05-05 @turt2live
2701 MSC2701: Clarifying `Content-Type` usage in the media repo 2020-07-28 2022-05-05 @turt2live
2700 MSC2700: Thumbnail requirements for the media repo 2020-07-28 2022-08-18 @turt2live
2695 MSC2695: Get event by ID over federation 2020-07-23 2022-05-05 @jryans
2673 MSC2673: Notification Levels 2020-07-07 2022-05-05 @timokoesters
2666 MSC2666: Get rooms in common with another user 2020-07-05 2023-02-28 @Half-Shot, @ShadowJonathan
2659 MSC2659: Application service ping endpoint 2020-06-29 2023-03-14 @tulir
2654 MSC2654: Unread counts 2020-06-24 2022-09-01 @babolivier
2644 MSC2644: `matrix.to` URI syntax v2 2020-06-19 2022-05-05 @jryans
2638 MSC2638: Ability for clients to request homeservers to resync device lists 2020-06-15 2022-05-05 @babolivier
2618 MSC2618: Helping others with mandatory implementation guides 2020-06-09 2022-05-05 @turt2live
2596 MSC2596: Proposal to always allow rescinding invites 2020-06-01 2022-05-05 @tulir
2545 MSC2545: Image Packs (Emoticons & Stickers) 2020-05-15 2023-01-03 @Sorunome
2530 MSC2530: Body field as media caption 2020-05-07 2022-10-19 @tulir
2529 MSC2529: Proposal to use existing events as captions for images 2020-05-07 2022-07-17 @benparsons
2513 MSC2513: Allow clients to specify content for membership events 2020-04-23 2022-05-05 @jevolk
2499 MSC2499: Fixes for Well-known URIs 2020-04-13 2022-05-05 @aaronraimist
2487 MSC2487: Filtering for Appservices 2020-04-03 2023-01-04 @Sorunome
2477 MSC2477: User-defined ephemeral events in rooms 2020-03-28 2022-06-03 @ananace
2474 MSC2474: Add key backup version to SSSS account data 2020-03-26 2022-05-05 @uhoreg
2461 MSC2461: Proposal for Authenticated Content Repository API 2020-03-15 2022-05-09 @SyrupThinker
2444 MSC2444: peeking over federation via /peek 2020-02-24 2022-05-05 @ara4n
2437 MSC2437: Store tagged events in Room Account Data 2020-02-18 2023-01-20 @giomfo
2427 MSC2427: Proposal for JSON-based message formatting 2020-01-24 2022-06-26 @tulir
2425 MSC2425: Remove Authentication on /submitToken Identity Service API 2020-01-24 2023-02-28 @anoadragon453
2416 MSC2416: Add m.login.jwt authentication type 2020-01-18 2022-05-24 @Sorunome
2413 MSC2413: Remove client_secret 2020-01-17 2022-05-05 @anoadragon453
2409 MSC2409: Proposal to send EDUs to appservices 2020-01-14 2022-09-01 @Sorunome
2398 MSC2398: proposal to allow mxc:// in the "a" tag within messages 2020-01-02 2022-05-05 @eras
2391 MSC2391: Federation point-queries. 2019-12-19 2022-05-05 @jevolk
2388 MSC2388: Toward the EDU-to-PDU transition: Read Receipts. 2019-12-18 2022-05-05 @jevolk
2385 MSC2385: Disable URL Previews, alternative method 2019-12-08 2022-05-05 @Sorunome @anoadragon453
2380 MSC2380: Matrix Media Information API 2019-12-05 2022-05-05 @turt2live
2379 MSC2379: Add /versions endpoint to Appservice API 2019-12-04 2022-05-05 @Half-Shot
2375 MSC2375: Appservice Invite States 2019-12-03 2022-05-05 @Sorunome
2354 MSC2354: Device to device streaming file transfers 2019-11-14 2022-08-17 @mvgorcum
2346 MSC2346: Bridge information state event 2019-11-05 2023-02-25 @Half-Shot
2326 MSC2326: Label based filtering 2019-10-22 2022-05-05 @ara4n
2316 MSC2316: Federation queries to aid with database recovery 2019-10-08 2022-05-05 @jevolk
2315 MSC2315: Allow users to select 'none' as an integration manager 2019-10-08 2022-11-03 @turt2live
2299 MSC2299: Proposal to add m.textfile msgtype 2019-09-21 2022-05-05 @Sorunome
2291 MSC2291: Configuration to Control Crawling 2019-09-14 2022-05-05 @uhoreg
2278 MSC2278: Deleting attachments for expired and redacted messages 2019-09-03 2022-05-05 @ara4n
2270 MSC2270: Proposal for Ignoring Invites 2019-08-31 2022-05-05 @ara4n
2228 MSC2228: Self destructing events 2019-08-11 2022-06-29 @ara4n
2214 MSC2214: Joining upgraded private rooms 2019-08-02 2022-05-05 @turt2live
2213 MSC2213: Rejoinability of private/invite-only rooms 2019-08-02 2022-05-05 @turt2live
2212 MSC2212: Third party user power levels 2019-08-01 2022-05-05 @turt2live
2211 MSC2211: Identity Servers Storing Threepid Hashes at Rest 2019-08-01 2022-05-05 @anoadragon453
2199 MSC2199: Canonical DMs 2019-07-30 2023-03-20 @turt2live
2192 MSC2192: Inline widgets 2019-07-28 2022-11-15 @turt2live
2191 MSC2191: Markup for mathematical messages 2019-07-26 2022-05-13 @uhoreg
2162 MSC2162: Signaling Errors at Bridges 2019-07-09 2022-06-17 @V02460
2127 MSC2127: Federation capabilities API 2019-06-12 2022-05-05 @turt2live
2108 MSC2108: Sync over Server Sent Events 2019-06-11 2022-08-16 @stalniy
2102 MSC2102: Enforce Canonical JSON on the wire for the S2S API 2019-06-08 2022-05-05 @leo-lb
2063 MSC2063: Add "server information" public API proposal 2019-05-31 2022-05-05 @grinapo
1998 MSC1998: Two-Factor Authentication Providers 2019-05-14 2022-10-03 @cyphar
1974 MSC1974: Crypto Puzzle Challenge 2019-04-24 2023-01-18 @Zolmeister
1973 MSC1973: Hash Key User ID 2019-04-24 2022-05-05 @Zolmeister
1959 MSC1959: Sticker picker API 2019-04-09 2022-05-05 @turt2live
1951 MSC1951: Custom sticker packs and emoji (mk II) 2019-04-04 2022-09-16 @turt2live
1929 MSC1929: Homeserver Admin Contact and Support page 2019-03-15 2023-03-02 @Half-Shot
1921 MSC1921: Support cancelling 3pid validation sessions 2019-03-08 2022-05-05 @turt2live
1920 MSC1920: Alternative texts for stickers 2019-03-08 2022-05-05 @babolivier
1902 MSC1902: Split the media repo into s2s and c2s parts 2019-02-24 2022-10-23 @turt2live
1862 MSC1862: Presence Capabilities 2019-02-07 2022-05-05 @Half-Shot
1840 MSC1840: Typed rooms 2019-02-03 2022-08-25 @jfrederickson
1797 MSC1797: Proposal for more granular profile error codes 2019-01-11 2022-05-05 @turt2live
1796 MSC1796: improved e2e notifications 2019-01-11 2023-03-19 @ara4n
1763 MSC1763: Proposal for specifying configurable message retention periods 2018-12-30 2022-11-21 @ara4n
1740 MSC1740: Using the Accept header to select an encoding 2018-12-02 2022-05-05 @Half-Shot
1716 MSC1716: Open on device API 2018-11-12 2022-05-05 @Half-Shot
1692 MSC1692: Terms of service at registration 2018-10-03 2022-05-05 @turt2live
1597 MSC1597: Better spec for matrix identifiers 2018-08-29 2022-10-12 @richvdh
3812 MSC1485: Hint buttons in messages 2018-08-04 2022-05-09 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
3808 Mechanism to communicate 3PID binding updates or deletions to homeservers 2018-06-20 2022-05-09 1 @babolivier
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
3805 Proposal for improving authorization for the matrix profile API 2018-06-13 2022-05-10 1 @turt2live
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 2022-05-09 1, 2 @richvdh, @krombel
3797 Refine and clarify how presence works 2017-12-26 2022-05-09 1 @ara4n
3796 Auth for content repo (and enforcing GDPR erasure) 2016-08-20 2022-05-25 1 @ara4n
3795 Extensible Profiles. (SPEC-93) 2015-01-19 2023-03-21 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 Docs Author Shepherd
3980 MSC3980: Dotted Field Consistency 2023-03-15 2023-03-18 @clokep
3967 MSC3967: Do not require UIA when first uploading cross signing keys 2023-02-15 2023-03-21 @hughns
3958 MSC3958: Suppress notifications from message edits 2023-01-24 2023-03-21 @clokep
3952 MSC3952: Intentional Mentions 2023-01-06 2023-03-21 @clokep
3882 MSC3882: Allow an existing session to sign in a new session 2022-09-05 2023-03-21 @hughns
3013 MSC3013: Encrypted Push 2021-02-17 2022-08-02 @Sorunome
2746 MSC2746: Improved VoIP Signalling 2020-08-21 2023-02-15 @dbkr
2463 MSC2463: Exclusion of MXIDs in push rules content matching 2020-03-18 2023-03-21 @pacien
2448 MSC2448: Using BlurHash as a Placeholder for Matrix Media 2020-02-27 2023-02-10 @anoadragon453
2249 MSC2249: Require users to have visibility on an event when submitting reports 2019-08-27 2023-03-12 @Half-Shot
2246 MSC2246: Asynchronous media uploads 2019-08-24 2022-07-08 @tulir

Final Comment Period

MSC Title Created at Updated at Docs Author Shepherd
3923 MSC3923: Bringing Matrix into the IETF process 2022-11-02 2023-03-21 @turt2live
2677 MSC2677: Annotations and reactions 2020-07-07 2023-03-21 @uhoreg @richvdh

Finished Final Comment Period

MSC Title Created at Updated at Docs Author Shepherd
2244 MSC2244: Mass redactions 2019-08-23 2022-07-18 @tulir
2175 MSC2175: Remove the `creator` field from `m.room.create` events 2019-07-14 2022-06-10 @richvdh

Spec PR Missing

MSC Title Created at Updated at Docs Author Shepherd
2176 MSC2176: Update the redaction rules 2019-07-14 2022-05-20 @richvdh
2174 MSC2174: Move the `redacts` key to a sane place 2019-07-14 2022-05-20 @richvdh
1961 MSC1961: Integration manager authentication APIs 2019-04-09 2021-04-06 @turt2live
1957 MSC1957: Integration manager discovery 2019-04-08 2021-04-06 @turt2live
1767 MSC1767: Extensible event types & fallback in Matrix (v2) 2019-01-01 2023-02-12 @ara4n @turt2live

Spec PR In Review

MSC Title Created at Updated at Docs Author Shepherd
3966 MSC3966: `event_property_contains` push rule condition 2023-02-09 2023-03-14 @clokep
3873 MSC3873: event_match dotted keys 2022-08-21 2023-03-14 @Johennes
3758 MSC3758: Add `event_property_is` push rule condition kind 2022-03-27 2023-03-14 @Fizzadar
2774 MSC2774: Expose the widget ID to the widget 2020-09-11 2021-04-06 @turt2live
2765 MSC2765: Widget avatars 2020-09-03 2021-04-06 @turt2live
1960 MSC1960: OpenID information exchange with widgets 2019-04-09 2021-08-23 @turt2live
3810 Widget API extension: Always-on-screen 2018-07-03 2022-05-09 1 @dbkr
3803 Matrix Widget API v2 2018-05-13 2023-03-16 1 @rxl881

Merged

MSC Title Created at Updated at Docs Author Shepherd
3943 MSC3943: Partial joins to nameless rooms should include heroes' memberships 2022-12-02 2023-02-07 @DMRobertson
3938 MSC3938: Remove keyId from `/keys` endpoints 2022-11-22 2023-01-06 @richvdh
3925 MSC3925: m.replace aggregation with full event 2022-11-03 2023-03-21 @benkuly
3905 MSC3905: Application services should only be interested in local users 2022-10-12 2022-11-08 @MadLittleMods
3904 MSC3904: Room version 10 as the default room version 2022-10-09 2023-01-08 @FSG-Cat
3856 MSC3856: Threads List API 2022-07-26 2022-09-27 @clokep
3844 MSC3844: Remove unused policy room sharing mechanism 2022-07-11 2022-08-03 @turt2live
3828 MSC3828: Content Repository CORP Headers 2022-06-01 2022-08-09 @robertlong
3827 MSC3827: Filtering of `/publicRooms` by room type 2022-05-27 2022-09-22 @SimonBrandner
3818 MSC3818: Copy room type on upgrade 2022-05-18 2022-08-03 @Mikaela
3816 MSC3816: Clarify Thread Participation 2022-05-17 2022-07-19 @clokep
3787 MSC3787: Allowing knocks to restricted rooms 2022-05-04 2023-01-05 @turt2live
3786 MSC3786: Add a default push rule to ignore `m.room.server_acl` events 2022-04-30 2022-08-03 @SimonBrandner
3783 MSC3783: Fixed base64 for SAS verification 2022-04-25 2023-02-10 @uhoreg
3773 MSC3773: Notifications for threads 2022-04-15 2022-09-28 @clokep
3771 MSC3771: Read receipts for threads 2022-04-15 2022-09-28 @clokep
3743 MSC3743: Standardized error response for unknown endpoints 2022-02-23 2022-11-22 @clokep
3715 MSC3715: Add a pagination direction parameter to `/relations` 2022-02-07 2022-09-27 @clokep
3706 MSC3706: Extensions to `/_matrix/federation/v2/send_join/{roomId}/{eventId}` for partial state 2022-02-03 2023-01-24 @richvdh
3700 MSC3700: Deprecate plaintext sender key 2022-02-03 2022-09-21 @erikjohnston
3676 MSC3676: Transitioning away from reply fallbacks 2022-01-26 2022-06-08 @ara4n
3667 MSC3667: Enforce integer power levels 2022-01-21 2022-06-08 @neilalexander
3666 MSC3666: Bundled aggregations for server side search 2022-01-21 2022-06-08 @clokep
3604 MSC3604: Room Version 10 2021-12-29 2022-09-27 @turt2live
3589 MSC3589: Room version 9 as the default room version 2021-12-23 2022-03-02 @turt2live
3582 MSC3582: Remove m.room.message.feedback 2021-12-21 2022-05-05 @uhoreg
3567 MSC3567: Allow requesting events from the start/end of the room history 2021-12-14 2022-04-05 @clokep
3550 MSC3550: Allow HTTP 403 as a response to profile lookups 2021-12-07 2022-01-03 @H-Shay
3442 MSC3442: move the `prev_content` key to `unsigned` 2021-10-14 2022-02-18 @richvdh
3440 MSC3440: Threading via `m.thread` relation 2021-10-13 2022-09-27 @gsouquet
3419 MSC3419: Allow guests to send more event types 2021-10-01 2022-01-05 @ara4n
3383 MSC3383: Include destination in X-Matrix Auth Header 2021-09-07 2022-05-30 @jcgruenhage
3375 MSC3375: Room version 9 2021-09-02 2022-03-02 @clokep
3316 MSC3316: Add timestamp massaging to the spec 2021-08-07 2022-07-18 @tulir
3289 MSC3289: Room version 8 2021-07-21 2022-03-01 @clokep
3288 MSC3288: Add room type to `/_matrix/identity/v2/store-invite` API 2021-07-20 2022-01-17 @BillCarsonFr
3283 MSC3283: Expose capabilities for profile actions 2021-07-13 2022-05-16 @JonasKress
3267 MSC3267: Reference relations 2021-07-05 2022-10-18 @bwindels
3231 MSC3231: Token authenticated registration 2021-06-04 2022-03-01 @govynnus
3173 MSC3173: Expose stripped state events to any potential joiner 2021-05-03 2022-01-05 @clokep
3122 MSC3122: Deprecate starting verifications without requesting first 2021-04-14 2021-05-20 @uhoreg
3083 MSC3083: Restricting room membership based on membership in other rooms 2021-03-31 2022-01-18 @clokep
3069 MSC3069: Allow guests to use /account/whoami 2021-03-19 2022-02-18 @turt2live
3030 MSC3030: Jump to date API endpoint 2021-02-25 2022-12-21 @MadLittleMods
2998 MSC2998: Room Version 7 2021-02-08 2021-04-30 @anoadragon453
2946 MSC2946: Spaces Summary 2021-01-07 2022-01-17 @clokep
2918 MSC2918: Refresh tokens 2020-12-18 2022-10-14 @sandhose
2874 MSC2874: Single SSSS 2020-11-23 2021-04-28 @uhoreg
2858 MSC2858: Multiple SSO Identity Providers 2020-11-09 2021-05-27 @t3chguy
2844 MSC2844: Global version number for the whole spec 2020-10-30 2022-02-22 @turt2live
2832 MSC2832: HS -> AS authorization header 2020-10-24 2022-08-04 @tulir
2801 MSC2801: Make it explicit that event bodies are untrusted data 2020-10-01 2022-05-19 @richvdh
2788 MSC2788: Room version 6 as the default room version 2020-09-23 2020-10-05 @turt2live
2778 MSC2778: Providing authentication method for appservice users 2020-09-16 2021-12-28 @Half-Shot
2758 MSC2758: Proposal for a common identifier grammar 2020-09-01 2021-12-29 @richvdh
2732 MSC2732: Olm fallback keys 2020-08-14 2022-01-05 @uhoreg
2713 MSC2713: Remove deprecated v1 Identity Service API 2020-07-30 2022-07-04 @turt2live
2689 MSC2689: Fix E2EE for guests 2020-07-15 2020-10-07 @awesome-michael
2676 MSC2676: Message editing 2020-07-07 2022-11-08 @uhoreg
2675 MSC2675: Serverside aggregations of message relationships 2020-07-07 2022-06-08 @uhoreg
2674 MSC2674: Event Relationships 2020-07-07 2023-02-23 @uhoreg
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 2020-07-30 @clokep
2582 MSC2582: Remove mimetype from EncryptedFile object 2020-05-26 2021-09-27 @Sorunome
2557 MSC2557: Proposal to clarify spoilers 2020-05-19 2021-04-06 @turt2live
2540 MSC2540: Stricter event validation: JSON compliance 2020-05-13 2022-03-01 @clokep
2526 MSC2526: Add ability to delete key backups 2020-05-05 2020-06-02 @uhoreg
2472 MSC2472: Symmetric SSSS 2020-03-24 2020-06-20 @uhoreg
2457 MSC2457: Invalidating devices during password modification 2020-03-12 2022-08-29 @clokep
2454 MSC2454: Support UI auth for SSO 2020-03-09 2020-05-11 @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 2022-03-01 @richvdh
2422 MSC2422: Allow color on font tag 2020-01-23 2021-04-06 @deepbluev7
2414 MSC2414: Make reason and score parameters optional for reporting content 2020-01-18 2022-03-01 @iinuwa
2403 MSC2403: Add "knock" feature 2020-01-09 2022-06-27 @Sorunome @anoadragon453
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
2366 MSC2366: Key verification flow additions: m.key.verification.ready and m.key.verification.done 2019-11-25 2022-03-01 @uhoreg
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
2320 MSC2320: Versions information for identity servers 2019-10-15 2021-05-04 @babolivier
2313 MSC2313: Moderation policies as rooms (ban lists) 2019-10-05 2020-11-14 @ara4n
2312 MSC2312: Matrix URI scheme proposal 2019-10-04 2022-03-01 @KitsuneRal
2290 MSC2290: Separate Endpoints for Threepid Binding 2019-09-12 2020-04-20 @anoadragon453
2285 MSC2285: Private read receipts 2019-09-06 2022-09-15 @SimonBrandner
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
2184 MSC2184: Allow the use of the HTML <details> tag 2019-07-16 2021-04-06 @ananace
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
2077 MSC2077: room v5 2019-06-04 2021-09-22 @richvdh
2076 MSC2076: Enforce key-validity periods when validating event signatures 2019-06-04 2021-09-22 @richvdh
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 2020-06-20 @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
1779 MSC1779: Proposal for Open Governance for Matrix.org (v2) 2019-01-07 2022-05-06 @ara4n
1772 MSC1772: Matrix spaces 2019-01-03 2022-03-01 @ara4n
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
1721 MSC1721: Rename m.login.cas to m.login.sso 2018-11-15 2021-09-22 @richvdh
1719 MSC1719: olm session unwedging 2018-11-14 2022-06-27 @uhoreg
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
1544 MSC1544: Key verification using QR codes 2018-08-20 2022-03-01 @uhoreg
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

MSC Title Created at Updated at Docs Author Shepherd
2190 MSC2190: Allow appservice bots to use /sync 2019-07-24 2022-11-03 @tulir

Abandoned

MSC Title Created at Updated at Docs Author Shepherd
3978 MSC3978: Deprecate room tagging 2023-03-15 2023-03-16 @uhoreg
3852 MSC3852: Expose user agent information on `Device` 2022-07-22 2023-01-11 @kerryarchibald
3790 MSC3790: Register Clients 2022-05-09 2022-05-11 @xarvic
3772 MSC3772: Push rule for mutually related events 2022-04-15 2022-10-07 @clokep
3302 MSC3302: Stories via To-Device-Messaging 2021-07-31 2021-11-22 @krillefear
3265 MSC3265: Login and SSSS with a Single Password 2021-07-02 2022-12-12 @cvwright
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
3073 MSC3073: Role based access control 2021-03-25 2021-08-27 @erkinalp
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
3006 MSC3006: Bot Interactions 2021-02-13 2021-11-23 @MTRNord
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
2880 MSC2880: extend event and state API to allow sending to all rooms 2020-11-27 2021-08-27 @ghost
2875 MSC2875: room descriptions 2020-11-23 2021-08-27 @ghost
2834 MSC2834: Media IDs as hashes 2020-10-26 2021-08-27 @ghost
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
2000 MSC2000: Server-side password policies 2019-05-15 2023-02-27 @babolivier
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
3910 MSC3910: Content tokens for media 2022-10-14 2022-11-04 @richvdh
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
3760 MSC3760: State sub-keys 2022-03-31 2022-04-13 @andybalaam
3613 MSC3613: Combinatorial join rules 2021-12-31 2022-05-04 @turt2live
3585 MSC3585: Allow the base event to be omitted from `/federation/v1/event_auth` response 2021-12-22 2022-01-06 @richvdh
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
3429 MSC3429: Individual room preview API 2021-10-05 2022-07-19 @turt2live
3306 MSC3306: Counting unread messages 2021-08-02 2021-08-03 @KitsuneRal
3286 MSC3286: Media spoilers 2021-07-18 2022-02-14 @robintown
3282 MSC3282: Expose enable_set_displayname in capabilities response 2021-07-13 2021-07-19 @JonasKress
3279 MSC3279: Expose enable_set_displayname in capabilities response 2021-07-13 2021-07-13 @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
2153 MSC2153: Add a default push rule to ignore m.reaction events 2019-07-04 2022-07-31 @jryans
1958 MSC1958: Widget architecture changes 2019-04-09 2020-11-23 @turt2live
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
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
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