1   Proposals for Spec Changes to Matrix

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.

2   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.

3   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 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 Resonsance 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 transfering 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.

4   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-doc 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-doc 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 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, 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 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. On its conclusion, the disposition of the FCP will be carried out. If sufficient reasoning against the disposition is raised, the FCP can be cancelled and the MSC will continue to evolve accordingly.
  • 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 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-doc issue and 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       |  |  |                       |
|                      |  |  |                       |
+----------+-----------+  |  |                       |
           |              |  |                       |
           +-----------------+                       |
                          |                          |
                          +                          +

5   Lifetime States

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

Name GitHub Label Description
Proposal Drafting and Feedback N/A 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 proposal-in-review 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 Commment 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
Closed proposal-closed A proposal which has been reviewed and deemed unsuitable for acceptance
Obsolete obsolete A proposal which has been made obsolete by another proposal or decision elsewhere.

6   Proposal Tracking

This is a living document generated from the list of proposals on the issue and pull request trackers of the matrix-doc 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-doc 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-doc/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.

7   Tables of Tracked Proposals

7.1   <work-in-progress>

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC455 Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) 2014-09-15 2019-01-04 455-1 @KitsuneRal None  
MSC586 Federation API for canonicalising MXIDs 2014-10-27 2019-01-04 586-1 @ara4n None  
MSC489 Extensible Profiles. (SPEC-93) 2015-01-19 2019-07-30 489-1 @erikjohnston None  
MSC1148 Support for websockets 2015-11-16 2019-01-04 1148-1, 1148-2 @richvdh, @krombel None  
MSC1238 Voice messages 2016-04-13 2019-04-03 1238-1 @aviraldg None PR#310
MSC1198 Threading API 2016-05-23 2019-01-04 1198-1 @Half-Shot None  
MSC1207 Publishing Room Lists for 3rd party networks 2016-10-21 2019-01-04 1207-1 @erikjohnston None  
MSC1237 Improving m.location with GeoJSON and accuracy 2017-05-19 2019-01-04 1237-1 @Half-Shot None PR#919
MSC1218 Bridging group membership with 3rd party group sources 2017-11-15 2019-01-04 1218-1 @lukebarnard1 None  
MSC1221 Improving Presence 2017-12-26 2019-06-25 1221-1 @ara4n None  
MSC1100 Refine and clarify how presence works 2017-12-26 2019-01-04 1100-1 @ara4n None  
MSC1222 Pushing updates about Groups (Communities) to clients 2018-01-02 2019-01-04 1222-1 @ara4n None  
MSC1206 Proposal for improved bot support 2018-03-14 2019-03-21 1206-1 @turt2live None  
MSC1228 Removing MXIDs from events 2018-04-19 2019-09-01 1228-1 @richvdh None  
MSC1280 Mechanisms for communicating erasure requests to bots and federated homeservers 2018-06-05 2019-01-04 1280-1 @richvdh None  
MSC1322 Mechanism to communicate 3PID binding updates or deletions to homeservers 2018-06-20 2019-01-04 1322-1 @babolivier None  
MSC1410 Proposal for Rich Bridging 2018-07-12 2019-01-04 1410-1 @Half-Shot None  
MSC1453 Antivirus support 2018-07-26 2019-01-09   @ara4n None  
MSC1485 MSC1485: Hint buttons in messages 2018-08-04 2019-03-19 1485-1 @tulir None  
MSC1488 MSC Suggested Mentions 2018-08-06 2019-01-04 1488-1 @Half-Shot None  
MSC1544 [WIP] MSC1543: Key verification using QR codes 2018-08-20 2019-09-19   @uhoreg None  
MSC1543 Key verification using QR codes 2018-08-20 2019-04-01 1543-1 @uhoreg None PR#1544
MSC1608 Better spec for room aliases 2018-08-29 2019-06-03 1608-1 @richvdh None  
MSC1607 MSC1608: Proposal for room alias grammar 2018-08-29 2019-06-03   @richvdh None  
MSC1646 MSC: Better specify how to validate events 2018-08-31 2019-07-15   @richvdh None  
MSC1762 [WIP] MSC1762: Support user-owned identifiers as new 3PID type 2018-12-28 2019-02-27   @friedger None  
MSC1772 WIPish: MSC1772: Groups as rooms (v2) 2019-01-03 2019-09-08   @ara4n None  
MSC1769 WIPish: MSC1769: Extensible profiles as rooms 2019-01-03 2019-02-13   @ara4n None  
MSC1768 [WIP] MSC1768: Proposal to authenticate with public keys 2019-01-03 2019-02-13   @friedger None  
MSC1777 [WIPish] MSC1777: peeking over federation 2019-01-06 2019-07-29   @ara4n None  
MSC1776 [WIPish] MSC1776: Implementing peeking via /sync 2019-01-06 2019-02-13   @ara4n None  
MSC1781 [WIP] MSC1781: Proposal for associations for DIDs and DID names 2019-01-07 2019-02-13   @friedger None  
MSC1780 [WIP] MSC1780: Add DIDs and DID names as admin accounts to HS 2019-01-07 2019-02-13   @friedger None  
MSC1888 [WIP] MSC1888: Proposal to send EDUs to appservices 2019-02-15 2019-03-22   @Half-Shot None  
MSC1956 MSC1956: [WIP] Integrations API (base) 2019-04-08 2019-07-28   @turt2live None  
MSC2240 [WIP] MSC2240: Room version 6 2019-08-22 2019-08-27   @turt2live None  
MSC2246 MSC2246: Asynchronous media uploads 2019-08-24 2019-08-29   @tulir None  
MSC2249 [WIP] MSC2249: Require users to have visibility on an event when submitting reports 2019-08-27 2019-09-02   @Half-Shot None  
MSC2271 [WIP] MSC2271 TOTP 2FA login 2019-08-31 2019-08-31   @ara4n None  

7.2   proposal-in-review

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC1270 Proposal Add /_matrix/media/v1/resolve_url to Client-Server API: download and preview urls in the clients despite CORS 2018-05-31 2019-01-04 1270-1 @oivoodoo None  
MSC701 Auth for content repo (and enforcing GDPR erasure) 2018-06-04 2019-01-04 701-1 @ara4n None  
MSC1301 Proposal for improving authorization for the matrix profile API 2018-06-13 2019-01-04 1301-1 @turt2live None  
MSC1309 Proposal for an application service management API 2018-06-14 2019-04-12 1309-1 @turt2live None  
MSC1306 Proposal to filter out traffic to Appservices based on filters 2018-06-14 2019-01-04 1306-1 @Half-Shot None  
MSC1310 Proposal for a media information API 2018-06-17 2019-01-04 1310-1 @turt2live None  
MSC1316 Proposal to have the appservice registration type be optional 2018-06-18 2019-01-04 1316-1 @turt2live None  
MSC1330 Proposal to improve /createRoom 2018-06-22 2019-01-04 1330-1 @turt2live None  
MSC1337 Proposal to improve /members and /joined_rooms 2018-06-23 2019-03-28 1337-1 @turt2live None  
MSC1489 Suggested Mentions Proposal 2018-08-06 2018-12-17   @Half-Shot None  
MSC1692 MSC1692: Terms of service API 2018-10-03 2019-07-16   @turt2live None  
MSC1703 MSC1703: encrypting recovery keys for online megolm backups 2018-10-23 2019-04-30   @dbkr None  
MSC1716 MSC1716: Open on device API 2018-11-12 2019-02-13   @Half-Shot None  
MSC1722 MSC1722: Support for displaying math(s) in messages 2018-11-15 2019-07-12   @uhoreg None  
MSC1740 MSC1740: Using the Accept header to select an encoding 2018-12-02 2019-07-30   @Half-Shot None  
MSC1767 MSC1767: Extensible event types & fallback in Matrix (v2) 2019-01-01 2019-02-27   @ara4n None  
MSC1797 MSC1797: Proposal for more granular profile error codes 2019-01-11 2019-02-13   @turt2live None  
MSC1796 MSC1796: improved e2e notifications 2019-01-11 2019-02-13   @ara4n None  
MSC1840 MSC1840: Typed rooms 2019-02-03 2019-02-19   @jfrederickson None  
MSC1849 MSC1849: Proposal for m.relates_to aggregations 2019-02-04 2019-09-10   @ara4n None  
MSC1902 MSC1902: Split the media repo into s2s and c2s parts 2019-02-24 2019-03-20   @turt2live None  
MSC1921 MSC1921: Support cancelling 3pid validation sessions 2019-03-08 2019-09-18   @turt2live None  
MSC1920 MSC1920: Alternative texts for stickers 2019-03-08 2019-03-10   @babolivier None  
MSC1929 MSC1929: Homeserver Admin Contact and Support page 2019-03-15 2019-09-09   @Half-Shot None  
MSC1951 MSC1951: Custom sticker packs and emoji (mk II) 2019-04-04 2019-09-12   @turt2live None  
MSC1960 MSC1960: OpenID information exchange with widgets 2019-04-09 2019-08-12   @turt2live None  
MSC1959 MSC1959: Sticker picker API 2019-04-09 2019-06-20   @turt2live None  
MSC1958 MSC1958: Widget architecture changes 2019-04-09 2019-06-20   @turt2live None  
MSC1974 MSC1974: Crypto Puzzle Challenge 2019-04-24 2019-05-22   @Zolmeister None  
MSC1973 MSC1973: Hash Key User ID 2019-04-24 2019-04-24   @Zolmeister None  
MSC1998 MSC1998: Two-Factor Authentication Providers 2019-05-14 2019-06-12   @cyphar None  
MSC2000 MSC2000: Server-side password policies 2019-05-15 2019-05-31   @babolivier None  
MSC2033 MSC2033: Adding a device_id to /account/whoami 2019-05-27 2019-05-28   @turt2live None  
MSC2063 MSC2063: Add "server information" public API proposal 2019-05-31 2019-07-24   @grinapo None  
MSC2102 MSC2102: Enforce Canonical JSON on the wire for the S2S API 2019-06-08 2019-06-13   @leo-lb None  
MSC2108 MSC2108: Sync over Server Sent Events 2019-06-11 2019-06-26   @stalniy None  
MSC2127 MSC2127: Federation capabilities API 2019-06-12 2019-06-18   @turt2live None  
MSC2162 MSC2162: Signaling Errors at Bridges 2019-07-09 2019-08-09   @V02460 None  
MSC2191 MSC2191: Proposal for using LaTeX for maths display 2019-07-26 2019-08-03   @uhoreg None  
MSC2192 MSC2192: Inline widgets (including polls and buttons) 2019-07-28 2019-08-21   @turt2live None  
MSC2211 MSC2211: Identity Servers Storing Threepid Hashes at Rest 2019-08-01 2019-08-02   @anoadragon453 None  
MSC2209 MSC2209: Alter auth rules to check notifications in m.room.power_levels 2019-08-01 2019-08-03   @lucavb None  
MSC2214 MSC2214: Joining upgraded private rooms 2019-08-02 2019-08-06   @turt2live None  
MSC2261 MSC2261: Allow m.room.aliases events to be redacted by room admins 2019-08-29 2019-08-29   @richvdh None  
MSC2260 MSC2260: Update the auth rules for m.room.aliases events 2019-08-29 2019-09-12   @richvdh None  
MSC2284 MSC2284: Making the identity server optional during discovery 2019-09-06 2019-09-06   @turt2live None  
MSC2291 MSC2291: Configuration to Control Crawling 2019-09-14 2019-09-16   @uhoreg None  

7.3   proposed-final-comment-period

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC1219 Proposal for storing megolm keys serverside 2017-11-23 2019-09-19 1219-1 @ara4n, @uhoreg None  
MSC1756 MSC1756: cross-signing devices using a master identity key 2018-12-14 2019-09-13   @uhoreg None  
MSC1763 MSC1763: Proposal for specifying configurable message retention periods 2018-12-30 2019-09-11   @ara4n None  
MSC1862 MSC1862: Presence Capabilities 2019-02-07 2019-08-28   @Half-Shot None  
MSC1946 MSC1946: Secure Secret Storage and Sharing 2019-03-28 2019-09-19   @uhoreg None  
MSC1983 MSC1983: Supporting a reason for leaving rooms 2019-04-30 2019-09-19   @turt2live None  
MSC2153 MSC2153: Add a default push rule to ignore m.reaction events 2019-07-04 2019-09-05   @jryans None  
MSC2176 MSC2176: Update the redaction rules 2019-07-14 2019-09-19   @richvdh None  
MSC2184 MSC2184: Allow the use of the HTML <details> tag 2019-07-16 2019-08-28   @ananace None  
MSC2190 MSC2190: Allow appservice bots to use /sync 2019-07-24 2019-08-28   @tulir None  
MSC2199 MSC2199: Canonical DMs 2019-07-30 2019-09-13   @turt2live None  
MSC2212 MSC2212: Third party user power levels 2019-08-01 2019-09-12   @turt2live None  
MSC2213 MSC2213: Rejoinability of private/invite-only rooms 2019-08-02 2019-09-11   @turt2live None  
MSC2228 MSC2228: Self destructing events 2019-08-11 2019-09-05   @ara4n None  
MSC2241 MSC2241: key verification in DMs 2019-08-22 2019-09-16   @uhoreg None  
MSC2244 MSC2244: Mass redactions 2019-08-23 2019-08-31   @tulir None  
MSC2265 MSC2265: Proposal for mandating lowercasing when processing e-mail address localparts 2019-08-30 2019-09-19   @babolivier None  
MSC2270 MSC2270: Proposal for Ignoring Invites 2019-08-31 2019-09-12   @ara4n None  
MSC2278 MSC2278: Deleting attachments for expired and redacted messages 2019-09-03 2019-09-11   @ara4n None  
MSC2285 MSC2285: Hidden read receipts 2019-09-06 2019-09-11   @turt2live None  
MSC2290 MSC2290: Separate Endpoints for Threepid Binding 2019-09-12 2019-09-19   @anoadragon453 None  

7.5   finished-final-comment-period

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC1229 Mitigating abuse of the event depth parameter over federation 2018-04-30 2019-01-07 1229-1 @ara4n None  
MSC1597 Better spec for matrix identifiers 2018-08-29 2019-01-04 1597-1 @richvdh None  
MSC1802 MSC1802: Remove the '200' value from some federation responses 2019-01-14 2019-09-10   @babolivier None  
MSC2175 MSC2175: Remove the creator field from m.room.create events 2019-07-14 2019-08-26   @richvdh None  
MSC2174 MSC2174: Move the redacts key to a sane place 2019-07-14 2019-08-26   @richvdh None  

7.6   spec-pr-missing

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC971 Add groups stuff to spec 2017-08-10 2019-05-24 971-1, 971-2, 971-3 @erikjohnston None  
MSC1214 Related Groups (i.e. flair) 2017-10-03 2019-05-24 1214-1 @lukebarnard1 None  
MSC1236 Matrix Widget API v2 2018-05-13 2019-06-20 1236-1 @rxl881 None  
MSC1354 Widget API extension: Always-on-screen 2018-07-03 2019-06-20 1354-1 @dbkr None  
MSC1466 MSC Soft Logout 2018-08-01 2019-07-12 1466-1 @erikjohnston None  
MSC1957 MSC1957: Integration manager discovery 2019-04-08 2019-08-30   @turt2live None  
MSC1961 MSC1961: Integration manager authentication APIs 2019-04-09 2019-08-30   @turt2live None  
MSC2010 MSC2010: Add client-side spoilers 2019-05-22 2019-08-29   @Sorunome None  
MSC2197 MSC2197: Search Filtering in Federation /publicRooms 2019-07-29 2019-08-30   @reivilibre None  
MSC2263 MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets 2019-08-29 2019-09-05   @turt2live None  

7.8   merged

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC433 Support for discovering API endpoints via .well-known URIs (SPEC-121) 2015-03-08 2018-08-29 433-1, 433-2 @maxidor, others @uhoreg  
MSC1197 Ignoring Users 2016-05-03 2018-05-18 1197-1 @erikjohnston None PR#1142
MSC1199 Notifications API 2016-05-23 2018-06-25 1199-1 @dbkr None  
MSC1200 Configuration of E2E encryption in a room 2016-06-16 2018-08-24 1200-1 @richvdh None PR#1284
MSC1201 Device Management API 2016-07-14 2018-08-15 1201-1 @richvdh None  
MSC1203 3rd Party Entity lookup API 2016-07-21 2018-08-14 1203-1 @leonerd None PR#1353
MSC1204 Access Token Semantics (refresh and macaroons) - aka Auth Sept 2016 Edition 2016-09-29 2018-06-25 1204-1 @richvdh None  
MSC1205 Proposal for multi-device deletion API 2016-10-12 2018-06-25 1205-1 @richvdh None PR#1239
MSC1208 Encrypted attachment format 2016-10-26 2018-08-31 1208-1 @NegativeMjark None PR#1420
MSC739 Reporting inappropriate content in Matrix 2016-11-21 2018-07-03 739-1 @ara4n None  
MSC1211 Megolm session export format 2017-01-03 2018-11-08 1211-1 @richvdh None  
MSC1212 Device List Update Stream 2017-01-18 2018-09-18 1212-1 @richvdh None PR#1648, PR#1284
MSC829 Need to spec msisdn login API 2017-03-08 2018-08-17 829-1 @dbkr None PR#1390
MSC855 spec m.login.msisdn UI auth type 2017-03-24 2018-08-14 855-1 @dbkr None  
MSC910 Add new Read Marker API to docs 2017-05-08 2018-09-17 910-1 @lukebarnard1 None  
MSC953 Add /user_directory/search API 2017-05-31 2018-07-26 953-1 @erikjohnston None  
MSC1067 Spec @mentions 2017-07-14 2018-08-30 1067-1 @lukebarnard1 None  
MSC1033 Doc @room notifications 2017-10-23 2018-08-30 1033-1 @dbkr None  
MSC1227 Proposal for lazy-loading room members to improve initial sync speed and client RAM usage 2018-03-05 2019-06-11 1227-1 @ara4n None  
MSC1183 Document key-share requests 2018-04-30 2018-08-30 1183-1 @richvdh None  
MSC1230 Temporary mitigation for depth parameter abuse 2018-05-01 2018-08-30 1230-1 @ara4n None  
MSC1232 Media limits API 2018-05-04 2018-07-06 1232-1 @Half-Shot None PR#1189
MSC1233 A proposal for organising spec proposals 2018-05-10 2018-06-25 1233-1 @ara4n None PR#1240
MSC1234 Rich Replies format 2018-05-12 2018-09-17 1234-1 @t3chguy None  
MSC1267 MSC 1267: Interactive key verification using short authentication strings 2018-05-28 2019-06-07 1267-1 @uhoreg None  
MSC688 Room Summaries (was: Calculate room names server-side) 2018-06-10 2019-06-11 688-1 @ara4n None  
MSC1304 Proposal to simplify the auth rules of m.room.power_level events. 2018-06-13 2018-09-04 1304-1 @richvdh, @ara4n None  
MSC1323 AS traffic rate-limiting 2018-06-20 2018-08-28 1323-1 @anoadragon453 None  
MSC1339 Proposal to add a GET method to read account data 2018-06-24 2019-02-11   @ananace None  
MSC1383 Proposal for ACLing servers from rooms 2018-07-05 2018-08-30 1383-1 @richvdh, @ara4n None  
MSC1426 Proposal for clarifying and improving review process for MSCs 2018-07-17 2018-12-17 1426-1 @ara4n None  
MSC1425 Room Versioning 2018-07-17 2019-01-17 1425-1 @richvdh None  
MSC1442 State Resolution: Reloaded 2018-07-20 2018-09-04 1442-1 @erikjohnston None  
MSC1452 Homeserver Warning Messages 2018-07-25 2019-05-28 1452-1 @dbkr None  
MSC1497 MSC1497: Advertising support of experimental features in the CS API 2018-08-08 2019-01-24 1497-1 @ara4n None  
MSC1501 Room version upgrades 2018-08-10 2019-01-24 1501-1 @richvdh None  
MSC1504 Homeserver resource limiting error codes 2018-08-13 2019-02-11 1504-1 @neilisfragile None  
MSC1659 MSC 1659 Proposal: Change Event IDs to Hashes 2018-09-05 2019-02-01   @erikjohnston None  
MSC1693 MSC1693: Specify how to handle rejected events in new state res 2018-10-08 2019-01-24   @erikjohnston None  
MSC1704 MSC1704: Adding ?via= to matrix.to permalinks to help with routing 2018-10-26 2019-04-08   @turt2live None  
MSC1708 MSC1708: .well-known support for server name resolution 2018-11-05 2019-03-07   @richvdh None  
MSC1711 MSC1711: X.509 certificate verification for federation connections 2018-11-07 2019-05-24   @richvdh None  
MSC1717 MSC1717: common definitions for key verification methods 2018-11-13 2019-06-07   @uhoreg None  
MSC1719 MSC1719: olm session unwedging 2018-11-14 2019-06-04   @uhoreg None  
MSC1721 MSC1721: Rename m.login.cas to m.login.sso 2018-11-15 2019-01-17   @richvdh None  
MSC1730 MSC1730: Mechanism for redirecting to an alternative server during login 2018-11-23 2019-01-30   @richvdh None  
MSC1753 MSC1753: client-server capabilities API 2018-12-12 2019-01-31   @richvdh None  
MSC1759 Room v2 proposal 2018-12-17 2019-01-24   @erikjohnston None  
MSC1779 MSC1779: Proposal for Open Governance for Matrix.org (v2) 2019-01-07 2019-06-07   @ara4n None  
MSC1794 MSC 1794 - Federation v2 Invite API 2019-01-10 2019-01-29   @erikjohnston None  
MSC1804 MSC1804: Advertising capable room versions to clients 2019-01-17 2019-01-31   @turt2live None  
MSC1813 MSC 1813 - Federation Make Membership Room Version 2019-01-22 2019-01-29   @erikjohnston None  
MSC1819 MSC:1819 Remove Presence Lists 2019-01-28 2019-04-05   @neilisfragile None  
MSC1831 MSC1831: Change the order of .well-known and SRV discovery techniques 2019-01-31 2019-02-01   @turt2live None  
MSC1866 Add proposal for invite error code for unsupported room version 2019-02-08 2019-02-25   @erikjohnston None  
MSC1884 MSC1884: Proposal to replace slashes in event IDs 2019-02-13 2019-05-28   @richvdh None  
MSC1915 MSC 1915 - Add a 3PID unbind API 2019-03-06 2019-06-07   @erikjohnston None  
MSC1930 MSC1930: Add a push rule for m.room.tombstone events 2019-03-15 2019-08-08   @turt2live None  
MSC1954 MSC1954: Proposal to remove prev_content from the essential keys list 2019-04-05 2019-05-25   @neilisfragile None  
MSC2002 MSC2002: Proposal for adopting MSC1884 as v4 rooms 2019-05-17 2019-05-28   @ara4n None  
MSC2077 MSC2077: room v5 2019-06-04 2019-06-11   @richvdh None  
MSC2076 MSC2076: Enforce key-validity periods when validating event signatures 2019-06-04 2019-06-11   @richvdh None  
MSC2078 MSC2078: Sending Third-Party Request Tokens via the Homeserver 2019-06-05 2019-09-17   @anoadragon453 None  
MSC2134 MSC2134: Identity Hash Lookups 2019-06-15 2019-09-16   @anoadragon453 None  
MSC2140 MSC2140: Terms of Service for ISes and IMs 2019-06-20 2019-09-19   @dbkr None  
MSC2181 MSC2181: Add an Error Code for Signaling a Deactivated User 2019-07-16 2019-08-26   @anoadragon453 None PR#2234
MSC2230 MSC2230: Store Identity Server in Account Data 2019-08-13 2019-09-07   @dbkr None  
MSC2264 MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support 2019-08-29 2019-09-04   @turt2live None  

7.9   proposal-postponed

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC1699 Future Proposal for Cryptographic Challenge Login Flow and E2E Key Backup Recovery 2018-10-18 2019-01-29 1699-1 @ara4n None  

7.10   abandoned

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC531 Homeservers as OAuth authorization endpoints (resource owners) (SPEC-206) 2015-07-25 2019-02-17 531-1 @Kegsay None  
MSC1202 Profile Personae 2016-07-15 2019-01-04 1202-1 @erikjohnston None  
MSC1209 Server Side Profile API 2016-11-01 2019-01-04 1209-1 @erikjohnston None  
MSC1213 Set defaults for m.federate 2017-04-10 2019-01-04 1213-1 @psaavedra None  
MSC1217 Visibility of groups to group members and their non-members 2017-10-30 2019-01-04 1217-1 @lampholder None  
MSC1681 MSC1680: cross-signing 2018-09-20 2019-01-18   @uhoreg None  
MSC1680 MSC1680: cross-signing of devices to simplify key verification 2018-09-20 2019-01-18 1680-1 @uhoreg None  
MSC1700 MSC1700: Improving .well-known discovery 2018-10-19 2018-12-27   @turt2live None  
MSC1714 MSC1714: using the TLS private key to sign federation-signing keys 2018-11-09 2019-01-07   @richvdh None  
MSC1935 MSC1935: Key validity enforcement 2019-03-20 2019-08-21   @turt2live None  
MSC2233 MSC2233: Unauthenticated Capabilities API 2019-08-15 2019-08-19   @anoadragon453 None  

7.11   obsolete

MSC Proposal Title Creation Date Update Date Documentation Author Shepherd PRs
MSC1196 Matrix Escape Hatch (Versioned Rooms) 2015-10-22 2018-07-17 1196-1 @leonerd None  
MSC441 Support for Reactions / Aggregations 2016-12-25 2019-06-22 441-1 @pik @ara4n  
MSC1215 Groups as Rooms 2017-10-17 2019-01-03 1215-1 @ara4n None  
MSC1223 Replies event format 2018-02-01 2018-05-15 1223-1 @t3chguy None  
MSC1224 Replies - next steps 2018-02-03 2018-05-15 1224-1 @t3chguy None  
MSC1235 Proposal for Calendar Events 2018-02-06 2019-01-04 1235-1 @Half-Shot None  
MSC1225 Extensible event types & fallback in Matrix 2018-02-18 2019-01-03 1225-1 @ara4n None  
MSC1226 State Reset mitigation proposal 2018-02-20 2018-07-17 1226-1 @richvdh None  
MSC1231 Handling Consent for Privacy Policy 2018-05-02 2018-11-05 1231-1 @neilisfragile None  
MSC1194 A way for HSes to remove bindings from ISes (aka unbind) 2018-05-09 2019-03-18 1194-1 @dbkr None  
MSC1220 Rich quoting proposal 2018-05-10 2018-05-15 1220-1 @t3chguy None  
MSC1256 Custom emoji and sticker packs in matrix 2018-05-23 2019-07-30 1256-1 @turt2live None  
MSC1308 Proposal for speeding up review of simple spec changes 2018-06-14 2018-10-11   @ara4n None  
MSC1324 Custom protocol definitions for application services 2018-06-20 2018-08-30 1324-1 @anoadragon453 None  
MSC1318 Proposal for Open Governance of Matrix.org 2018-06-20 2019-01-07 1318-1 @ara4n None  
MSC1421 Make a Discourse forum the canonical location for spec discussions 2018-07-16 2018-08-05 1421-1 @non-Jedi None  
MSC1687 MSC1687: Encrypting recovery keys for online megolm backups 2018-09-26 2018-12-27 1687-1 @ara4n None  
MSC1695 MSC1695 Message Edits 2018-10-12 2019-07-23   @Half-Shot None  
MSC1731 MSC1731: Mechanism for redirecting to an alternative server during SSO login 2018-11-24 2018-12-17   @richvdh None  
MSC1943 MSC1943: Set default room as v3 2019-03-27 2019-05-20   @neilisfragile None  
MSC2229 MSC2229: Allowing 3PID Owners to Rebind 2019-08-12 2019-09-18   @anoadragon453 None