Table of Contents
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:
- If the feature would benefit the whole Matrix ecosystem and is aligned with the guiding principles above, then it should be supported by the spec.
- If the spec already makes the feature possible without changing any of the implementations and spec, then it may not need to be added to the spec.
- However, if the best user experience for a feature does require custom implementation behaviour then the behaviour should be defined in the spec such that all implementations may implement it.
- However, the spec must never add dependencies on unspecified/nonstandardised 3rd party behaviour.
As a worked example:
- Video conferencing is clearly a feature which would benefit the whole ecosystem, and so the spec should find a way to make it happen.
- Video conferencing can be achieved by widgets without requiring any compulsory changes to clients nor servers to work, and so could be omitted from the spec.
- A better experience could be achieved by embedding Jitsi natively into clients rather than using a widget...
- ...except that would add a dependency on unspecified/nonstandardised 3rd party behaviour, so must not be added to the spec.
Therefore, our two options in the specific case of video conferencing are either to spec SFU conferencing semantics for WebRTC (or refer to an existing spec for doing so), or to keep it as a widget-based approach (optionally with widget extensions specific for more deeply integrating video conferencing use cases).
As an alternative example: it's very unlikely that "how to visualise Magnetic Resonance Imaging data over Matrix" would ever be added to the Matrix spec (other than perhaps a custom event type in a wider standardised Matrix event registry) given that the spec's existing primitives of file transfer and extensible events (MSC1767) give excellent tools for transferring and visualising arbitrary rich data.
Supporting public search engines are likely to not require custom spec features (other than possibly better bulk access APIs), given they can be implemented as clients using the existing CS API. An exception could be API features required by decentralised search infrastructure (avoiding centralisation of power by a centralised search engine).
Features such as reactions, threaded messages, editable messages, spam/abuse/content filtering (and reputation systems), are all features which would clearly benefit the whole Matrix ecosystem, and cannot be implemented in an interoperable way using the current spec; so they necessitate a spec change.
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 #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. 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 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 |
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 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.
7 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.
7.1 Early release of an MSC/idea
To help facilitate early releases of software dependent on a spec release, implementations are required to use the following process to ensure that the official Matrix namespace is not cluttered with development or testing data.
Note
Unreleased implementations (including proofs-of-concept demonstrating that a particular MSC works) do not have to follow this process.
- Have an idea for a feature.
- Implement the feature using unstable endpoints, vendor prefixes, and unstable
feature flags as appropriate.
- 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.
- In parallel, or ahead of implementation, open an MSC and solicit review per above.
- Before FCP can be called, the Spec Core Team will require evidence of the MSC working as proposed. A typical example of this is an implementation of the MSC, though the implementation does not need to be shipped anywhere and can therefore avoid the forwards/backwards compatibility concerns mentioned here.
- The FCP process is completed, and assuming nothing is flagged the MSC lands.
- A spec PR is written to incorporate the changes into Matrix.
- A spec release happens.
- Implementations switch to using stable prefixes (e.g.: /r0) if the server supports the specification version released. If the server doesn't advertise the specification version, but does have the feature flag, unstable prefixes should still be used.
- 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.
Note
MSCs MUST still describe what the stable endpoints/feature looks like with a note towards the bottom for what the unstable feature flag/prefixes are. For example, an MSC would propose /_matrix/client/r0/new/endpoint, not /_matrix/client/unstable/ com.example/new/endpoint.
In summary:
- Implementations MUST NOT use stable endpoints before the MSC is in the spec. This includes NOT using stable endpoints in the period between completion of FCP and release of the spec. passed.
- 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.
8 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 necessarily represent a chronological order.
- The GitHub PR title will act as the MSC's title.
- Please link to the spec PR (if any) by adding a "PRs: #1234" line in the issue description.
- The creation date is taken from the GitHub PR, but can be overridden by adding a "Date: yyyy-mm-dd" line in the PR description.
- Updated Date is taken from GitHub.
- Author is the creator of the MSC PR, but can be overridden by adding an "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.
9 Tables of Tracked Proposals
9.1 <work-in-progress>
MSC | Proposal Title | Creation Date | Update Date | Documentation | Author | Shepherd | PRs |
---|---|---|---|---|---|---|---|
MSC586 | Federation API for canonicalising MXIDs | 2014-10-27 | 2020-04-21 | 586-1 | @ara4n | None | |
MSC489 | Extensible Profiles. (SPEC-93) | 2015-01-19 | 2020-05-12 | 489-1 | @erikjohnston | None | |
MSC1148 | Support for websockets | 2015-11-16 | 2020-04-21 | 1148-1, 1148-2 | @krombel, @richvdh | None | |
MSC1198 | Threading API | 2016-05-23 | 2020-10-30 | 1198-1 | @Half-Shot | None | |
MSC1218 | Bridging group membership with 3rd party group sources | 2017-11-15 | 2020-04-21 | 1218-1 | @lukebarnard1 | None | |
MSC1100 | Refine and clarify how presence works | 2017-12-26 | 2020-04-21 | 1100-1 | @ara4n | None | |
MSC1222 | Pushing updates about Groups (Communities) to clients | 2018-01-02 | 2020-04-21 | 1222-1 | @ara4n | None | |
MSC1206 | Proposal for improved bot support | 2018-03-14 | 2020-07-23 | 1206-1 | @turt2live | None | |
MSC1228 | [WIP] MSC1228: Removing MXIDs from events | 2018-05-10 | 2020-09-03 | @benparsons | None | ||
MSC1280 | Mechanisms for communicating erasure requests to bots and federated homeservers | 2018-06-05 | 2020-04-21 | 1280-1 | @richvdh | None | |
MSC1322 | Mechanism to communicate 3PID binding updates or deletions to homeservers | 2018-06-20 | 2020-04-21 | 1322-1 | @babolivier | None | |
MSC1453 | Antivirus support | 2018-07-26 | 2020-04-21 | @ara4n | None | ||
MSC1485 | MSC1485: Hint buttons in messages | 2018-08-04 | 2020-07-15 | 1485-1 | @tulir | None | |
MSC1608 | Better spec for room aliases | 2018-08-29 | 2020-04-21 | 1608-1 | @richvdh | None | |
MSC1762 | [WIP] MSC1762: Support user-owned identifiers as new 3PID type | 2018-12-28 | 2020-04-20 | @friedger | None | ||
MSC1772 | WIP: MSC1772: Matrix spaces | 2019-01-03 | 2021-01-15 | @ara4n | None | ||
MSC1769 | WIPish: MSC1769: Extensible profiles as rooms | 2019-01-03 | 2020-06-13 | @ara4n | None | ||
MSC1768 | [WIP] MSC1768: Proposal to authenticate with public keys | 2019-01-03 | 2020-04-20 | @friedger | None | ||
MSC1781 | [WIP] MSC1781: Proposal for associations for DIDs and DID names | 2019-01-07 | 2020-04-20 | @friedger | None | ||
MSC1780 | [WIP] MSC1780: Add DIDs and DID names as admin accounts to HS | 2019-01-07 | 2020-04-20 | @friedger | None | ||
MSC1956 | [WIP] MSC1956: Integrations API (base) | 2019-04-08 | 2020-12-17 | @turt2live | None | ||
MSC2153 | MSC2153: Add a default push rule to ignore m.reaction events | 2019-07-04 | 2020-09-23 | @jryans | None | ||
MSC2249 | [WIP] MSC2249: Require users to have visibility on an event when submitting reports | 2019-08-27 | 2020-04-20 | @Half-Shot | None | ||
MSC2271 | [WIP] MSC2271 TOTP 2FA login | 2019-08-31 | 2020-04-20 | @ara4n | None | ||
MSC2285 | [WIP] MSC2285: Hidden read receipts | 2019-09-06 | 2020-07-03 | @turt2live | None | ||
MSC2301 | [WIP] MSC2301: server info endpoint | 2019-09-23 | 2020-09-30 | @ara4n | None | ||
MSC2300 | [WIP] MSC2300: /ping endpoint | 2019-09-23 | 2020-04-20 | @ara4n | None | ||
MSC2306 | [WIP] MSC2306: Removing MSISDN password resets | 2019-09-24 | 2020-04-20 | @turt2live | None | ||
MSC2356 | [WIP] MSC2356: Bulk /joined_members endpoint | 2019-11-15 | 2020-04-20 | @Half-Shot | None | ||
MSC2359 | [WIP] MSC2359: E2EE VoIP Conferencing | 2019-11-17 | 2020-12-15 | @ara4n | None | ||
MSC2370 | [WIP] MSC2370: Resolve URL API | 2019-11-29 | 2020-12-29 | @uhoreg | None | ||
MSC2390 | MSC2390: On the EDU-to-PDU transition. | 2019-12-18 | 2020-05-18 | @jevolk | None | ||
MSC2389 | MSC2389: Toward the EDU-to-PDU transition: Typing. | 2019-12-18 | 2020-05-18 | @jevolk | None | ||
MSC2438 | [WIP] MSC2438: Local and Federated User Erasure Requests | 2020-02-19 | 2020-04-20 | @anoadragon453 | None | ||
MSC2474 | MSC2474: Add key backup version to SSSS account data | 2020-03-26 | 2020-05-13 | @uhoreg | None | ||
MSC2545 | MSC2545: Emoticons | 2020-05-15 | 2020-11-25 | @Sorunome | None | ||
MSC2697 | [WIP] MSC2697: Device dehydration | 2020-07-24 | 2020-12-28 | @uhoreg | None | ||
MSC2706 | [WIP] MSC2706: IPFS as a media repository for Matrix | 2020-07-28 | 2021-01-11 | @turt2live | None | ||
MSC2745 | [WIP] MSC2745 : Add hCaptcha as captcha provider | 2020-08-20 | 2020-11-10 | @Toby4213 | None | ||
MSC2753 | MSC2753: Peeking via sync (take 2) | 2020-08-29 | 2020-11-26 | @ara4n | None | ||
MSC2783 | [WIP] MSC2783: Homeserver Migration Data Format | 2020-09-19 | 2020-09-23 | @ShadowJonathan | None | ||
MSC2787 | MSC2787: Portable Identities | 2020-09-23 | 2021-01-12 | @neilalexander | None | ||
MSC2802 | [WIP] MSC2802: Flip The Table for Full Room Abstraction | 2020-10-05 | 2020-11-10 | @ShadowJonathan | None | ||
MSC2812 | [WIP] MSC2812: Role-based power/permissions | 2020-10-08 | 2021-01-07 | @turt2live | None | ||
MSC2821 | MSC2821: Testing Pushers | 2020-10-15 | 2020-11-19 | @clokep | None | ||
MSC2883 | MSC2883: [WIP] Matrix-flavoured MLS | 2020-11-27 | 2020-12-31 | @uhoreg | None | ||
MSC2882 | MSC2882: [WIP] Tempered Transitive Trust | 2020-11-27 | 2021-01-08 | @uhoreg | None | ||
MSC2918 | [WIP] MSC2918: Refresh tokens | 2020-12-18 | 2021-01-14 | @sandhose | None | ||
MSC2923 | MSC2923: Connect Matrix room to another Matrix room | 2020-12-22 | 2021-01-18 | @MadLittleMods | None | ||
MSC2957 | [WIP] MSC2957: Cryptographically Concealed Credentials | 2021-01-11 | 2021-01-16 | @uhoreg | None | ||
MSC2967 | [WIP] MSC2967: API scope restriction | 2021-01-14 | 2021-01-15 | @sandhose | None | ||
MSC2966 | [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix | 2021-01-14 | 2021-01-14 | @sandhose | None | ||
MSC2965 | [WIP] MSC2965: OIDC Provider discovery | 2021-01-14 | 2021-01-14 | @sandhose | None | ||
MSC2964 | [WIP] MSC2964: Matrix profile for OAuth 2.0 | 2021-01-14 | 2021-01-16 | @sandhose | None |
9.2 proposal-in-review
MSC | Proposal Title | Creation Date | Update Date | Documentation | Author | Shepherd | PRs |
---|---|---|---|---|---|---|---|
MSC701 | Auth for content repo (and enforcing GDPR erasure) | 2018-06-04 | 2020-04-21 | 701-1 | @ara4n | None | |
MSC1301 | Proposal for improving authorization for the matrix profile API | 2018-06-13 | 2020-04-21 | 1301-1 | @turt2live | None | |
MSC1309 | Proposal for an application service management API | 2018-06-14 | 2020-04-21 | 1309-1 | @turt2live | None | |
MSC1306 | Proposal to filter out traffic to Appservices based on filters | 2018-06-14 | 2020-04-21 | 1306-1 | @Half-Shot | None | |
MSC1316 | Proposal to have the appservice registration type be optional | 2018-06-18 | 2020-04-21 | 1316-1 | @turt2live | None | |
MSC1330 | Proposal to improve /createRoom | 2018-06-22 | 2020-04-21 | 1330-1 | @turt2live | None | |
MSC1597 | Better spec for matrix identifiers | 2018-08-29 | 2021-01-20 | @richvdh | None | ||
MSC1692 | MSC1692: Terms of service API | 2018-10-03 | 2020-04-20 | @turt2live | None | ||
MSC1703 | MSC1703: encrypting recovery keys for online megolm backups | 2018-10-23 | 2020-06-15 | @dbkr | None | ||
MSC1716 | MSC1716: Open on device API | 2018-11-12 | 2020-04-20 | @Half-Shot | None | ||
MSC1740 | MSC1740: Using the Accept header to select an encoding | 2018-12-02 | 2020-04-20 | @Half-Shot | None | ||
MSC1767 | MSC1767: Extensible event types & fallback in Matrix (v2) | 2019-01-01 | 2020-12-01 | @ara4n | None | ||
MSC1797 | MSC1797: Proposal for more granular profile error codes | 2019-01-11 | 2020-04-20 | @turt2live | None | ||
MSC1796 | MSC1796: improved e2e notifications | 2019-01-11 | 2020-04-20 | @ara4n | None | ||
MSC1840 | MSC1840: Typed rooms | 2019-02-03 | 2021-01-03 | @jfrederickson | None | ||
MSC1862 | MSC1862: Presence Capabilities | 2019-02-07 | 2021-01-19 | @Half-Shot | None | ||
MSC1902 | MSC1902: Split the media repo into s2s and c2s parts | 2019-02-24 | 2021-01-19 | @turt2live | None | ||
MSC1921 | MSC1921: Support cancelling 3pid validation sessions | 2019-03-08 | 2020-04-20 | @turt2live | None | ||
MSC1920 | MSC1920: Alternative texts for stickers | 2019-03-08 | 2021-01-06 | @babolivier | None | ||
MSC1929 | MSC1929: Homeserver Admin Contact and Support page | 2019-03-15 | 2020-04-20 | @Half-Shot | None | ||
MSC1951 | MSC1951: Custom sticker packs and emoji (mk II) | 2019-04-04 | 2020-12-20 | @turt2live | None | ||
MSC1959 | MSC1959: Sticker picker API | 2019-04-09 | 2020-04-20 | @turt2live | None | ||
MSC1974 | MSC1974: Crypto Puzzle Challenge | 2019-04-24 | 2020-04-20 | @Zolmeister | None | ||
MSC1973 | MSC1973: Hash Key User ID | 2019-04-24 | 2020-04-20 | @Zolmeister | None | ||
MSC1998 | MSC1998: Two-Factor Authentication Providers | 2019-05-14 | 2020-07-10 | @cyphar | None | ||
MSC2000 | MSC2000: Server-side password policies | 2019-05-15 | 2020-05-19 | @babolivier | None | ||
MSC2063 | MSC2063: Add "server information" public API proposal | 2019-05-31 | 2020-04-20 | @grinapo | None | ||
MSC2102 | MSC2102: Enforce Canonical JSON on the wire for the S2S API | 2019-06-08 | 2020-04-20 | @leo-lb | None | ||
MSC2108 | MSC2108: Sync over Server Sent Events | 2019-06-11 | 2020-04-20 | @stalniy | None | ||
MSC2127 | MSC2127: Federation capabilities API | 2019-06-12 | 2020-04-20 | @turt2live | None | ||
MSC2162 | MSC2162: Signaling Errors at Bridges | 2019-07-09 | 2020-04-20 | @V02460 | None | ||
MSC2191 | MSC2191: Markup for mathematical messages | 2019-07-26 | 2020-12-26 | @uhoreg | None | ||
MSC2192 | MSC2192: Inline widgets (including polls and buttons) | 2019-07-28 | 2020-11-23 | @turt2live | None | ||
MSC2199 | MSC2199: Canonical DMs | 2019-07-30 | 2020-10-08 | @turt2live | None | ||
MSC2212 | MSC2212: Third party user power levels | 2019-08-01 | 2020-10-02 | @turt2live | None | ||
MSC2211 | MSC2211: Identity Servers Storing Threepid Hashes at Rest | 2019-08-01 | 2020-04-20 | @anoadragon453 | None | ||
MSC2214 | MSC2214: Joining upgraded private rooms | 2019-08-02 | 2020-04-20 | @turt2live | None | ||
MSC2213 | MSC2213: Rejoinability of private/invite-only rooms | 2019-08-02 | 2020-10-02 | @turt2live | None | ||
MSC2246 | MSC2246: Asynchronous media uploads | 2019-08-24 | 2020-08-01 | @tulir | None | ||
MSC2270 | MSC2270: Proposal for Ignoring Invites | 2019-08-31 | 2020-10-02 | @ara4n | None | ||
MSC2278 | MSC2278: Deleting attachments for expired and redacted messages | 2019-09-03 | 2021-01-19 | @ara4n | None | ||
MSC2291 | MSC2291: Configuration to Control Crawling | 2019-09-14 | 2020-04-20 | @uhoreg | None | ||
MSC2299 | MSC2299: Proposal to add m.textfile msgtype | 2019-09-21 | 2020-04-20 | @Sorunome | None | ||
MSC2314 | MSC2314: A Method to Backfill Room State | 2019-10-07 | 2020-05-06 | @hawkowl | None | ||
MSC2316 | MSC2316: Federation queries to aid with database recovery | 2019-10-08 | 2020-10-03 | @jevolk | None | ||
MSC2315 | MSC2315: Allow users to select 'none' as an integration manager | 2019-10-08 | 2020-04-20 | @turt2live | None | ||
MSC2346 | MSC2346: Bridge information state event | 2019-11-05 | 2020-07-03 | @Half-Shot | None | ||
MSC2354 | MSC2354: Device to device streaming file transfers | 2019-11-14 | 2020-04-20 | @mvgorcum | None | ||
MSC2375 | MSC2375: Appservice Invite States | 2019-12-03 | 2020-07-10 | @Sorunome | None | ||
MSC2379 | MSC2379: Add /versions endpoint to Appservice API | 2019-12-04 | 2020-04-20 | @Half-Shot | None | ||
MSC2380 | MSC2380: Matrix Media Information API | 2019-12-05 | 2020-04-20 | @turt2live | None | ||
MSC2385 | MSC2385: Disable URL Previews, alternative method | 2019-12-08 | 2020-04-20 | @Sorunome | None | ||
MSC2388 | MSC2388: Toward the EDU-to-PDU transition: Read Receipts. | 2019-12-18 | 2020-05-15 | @jevolk | None | ||
MSC2391 | MSC2391: Federation point-queries. | 2019-12-19 | 2020-04-20 | @jevolk | None | ||
MSC2398 | MSC2398: proposal to allow mxc:// in the "a" tag within messages | 2020-01-02 | 2020-04-20 | @eras | None | ||
MSC2403 | MSC2403: Add "knock" feature | 2020-01-09 | 2020-11-27 | @Sorunome | None | ||
MSC2409 | MSC2409: Proposal to send EDUs to appservices | 2020-01-14 | 2020-11-10 | @Sorunome | None | ||
MSC2413 | MSC2413: Remove client_secret | 2020-01-17 | 2020-04-20 | @anoadragon453 | None | ||
MSC2416 | MSC2416: Enhance m.login.token authentication type | 2020-01-18 | 2020-09-01 | @Sorunome | None | ||
MSC2427 | MSC2427: Proposal for JSON-based message formatting | 2020-01-24 | 2021-01-02 | @tulir | None | ||
MSC2425 | MSC2425: Remove Authentication on /submitToken Identity Service API | 2020-01-24 | 2020-08-26 | @anoadragon453 | None | ||
MSC2437 | MSC2437: Store tagged events in Room Account Data | 2020-02-18 | 2020-04-20 | @giomfo | None | ||
MSC2444 | MSC2444: peeking over federation via /peek | 2020-02-24 | 2021-01-21 | @ara4n | None | ||
MSC2448 | MSC2448: Using Blurhash in Media Events | 2020-02-27 | 2020-12-07 | @anoadragon453 | None | ||
MSC2461 | MSC2461: Proposal for Authenticated Content Repository API | 2020-03-15 | 2020-04-20 | @SyrupThinker | None | ||
MSC2463 | MSC2463: Exclusion of MXIDs in push rules content matching | 2020-03-18 | 2020-11-10 | @pacien | None | ||
MSC2477 | MSC2477: User-defined ephemeral events in rooms | 2020-03-28 | 2020-09-09 | @ananace | None | ||
MSC2487 | MSC2487: Filtering for Appservices | 2020-04-03 | 2020-11-10 | @Sorunome | None | ||
MSC2499 | MSC2499: Fixes for Client Well-known URI | 2020-04-13 | 2020-11-10 | @aaronraimist | None | ||
MSC2513 | MSC2513: Allow clients to specify content for membership events | 2020-04-23 | 2020-11-17 | @jevolk | None | ||
MSC2516 | MSC2516: Add a new message type for voice messages | 2020-04-27 | 2020-12-15 | @ludwigbald | None | ||
MSC2530 | MSC2530: Body field as media caption | 2020-05-07 | 2020-11-10 | @tulir | None | ||
MSC2529 | MSC2529: Proposal to use existing events as captions for images | 2020-05-07 | 2020-12-16 | @benparsons | None | ||
MSC2557 | MSC2557: Proposal to clarify spoilers | 2020-05-19 | 2020-05-20 | @turt2live | None | ||
MSC2582 | MSC2582: Remove mimetype from EncryptedFile object | 2020-05-26 | 2020-11-10 | @Sorunome | None | ||
MSC2589 | MSC2589: Improve replies | 2020-05-29 | 2020-06-15 | @turt2live | None | ||
MSC2596 | MSC2596: Proposal to always allow rescinding invites | 2020-06-01 | 2020-07-01 | @tulir | None | ||
MSC2618 | MSC2618: Helping others with mandatory implementation guides | 2020-06-09 | 2020-06-15 | @turt2live | None | ||
MSC2638 | MSC2638: Ability for clients to request homeservers to resync device lists | 2020-06-15 | 2020-07-29 | @babolivier | None | ||
MSC2644 | MSC2644: matrix.to URI syntax v2 | 2020-06-19 | 2020-07-24 | @jryans | None | ||
MSC2654 | MSC2654: Unread counts | 2020-06-24 | 2020-12-02 | @babolivier | None | ||
MSC2659 | MSC2659: Application service ping endpoint | 2020-06-29 | 2020-07-01 | @tulir | None | ||
MSC2666 | MSC2666: Get rooms in common with another user | 2020-07-05 | 2020-11-10 | @Half-Shot | None | ||
MSC2677 | MSC2677: Annotations and reactions | 2020-07-07 | 2021-01-18 | @uhoreg | None | ||
MSC2676 | MSC2676: Message editing | 2020-07-07 | 2021-01-21 | @uhoreg | None | ||
MSC2675 | MSC2675: Serverside aggregations of message relationships | 2020-07-07 | 2020-12-31 | @uhoreg | None | ||
MSC2674 | MSC2674: Event Relationships | 2020-07-07 | 2020-12-13 | @uhoreg | None | ||
MSC2673 | MSC2673: Notification Levels | 2020-07-07 | 2020-12-02 | @timokoesters | None | ||
MSC2695 | MSC2695: Get event by ID over federation | 2020-07-23 | 2020-11-03 | @jryans | None | ||
MSC2705 | MSC2705: Animated thumbnails for media (and thumbnail content-type requirements) | 2020-07-28 | 2020-08-10 | @turt2live | None | ||
MSC2704 | MSC2704: Explicitly allow alternative origins in MXC URIs and specify deduplication requirements on uploads | 2020-07-28 | 2020-07-28 | @turt2live | None | ||
MSC2703 | MSC2703: Media ID grammar | 2020-07-28 | 2020-07-29 | @turt2live | None | ||
MSC2702 | MSC2702: Specifying semantics for Content-Disposition on media | 2020-07-28 | 2020-08-18 | @turt2live | None | ||
MSC2701 | MSC2701: Clarifying Content-Type usage in the media repo | 2020-07-28 | 2020-07-28 | @turt2live | None | ||
MSC2700 | MSC2700: Thumbnail requirements for the media repo | 2020-07-28 | 2020-08-11 | @turt2live | None | ||
MSC2716 | MSC2716: Incrementally importing history into existing rooms | 2020-08-04 | 2021-01-19 | @ara4n | None | ||
MSC2730 | MSC2730: Verifiable forwarded events | 2020-08-12 | 2021-01-07 | @tulir | None | ||
MSC2723 | MSC2723: Forwarded message metadata | 2020-08-12 | 2020-08-12 | @hummlbach | None | ||
MSC2747 | MSC2747: VoIP call transfers | 2020-08-21 | 2021-01-19 | @dbkr | None | ||
MSC2746 | MSC2746: Improved VoIP Signalling | 2020-08-21 | 2021-01-20 | @dbkr | None | ||
MSC2749 | MSC2749: Per-user E2EE on/off setting | 2020-08-25 | 2020-11-10 | @KB1RD | None | ||
MSC2755 | MSC2755: Lazy load rooms | 2020-08-31 | 2020-09-01 | @deepbluev7 | None | ||
MSC2757 | MSC2757: Sign Events | 2020-09-01 | 2020-11-13 | @Sorunome | None | ||
MSC2762 | MSC2762: Allowing widgets to send/receive events | 2020-09-02 | 2020-11-23 | @turt2live | None | ||
MSC2771 | MSC2771: Bookmarks | 2020-09-10 | 2020-11-08 | @MTRNord | None | ||
MSC2772 | MSC2772: Notifications for Jitsi Calls | 2020-09-11 | 2020-11-02 | @dbkr | None | ||
MSC2775 | MSC2775: Lazy loading over federation | 2020-09-14 | 2020-11-09 | @ara4n | None | ||
MSC2778 | MSC2778: Providing authentication method for appservice users | 2020-09-16 | 2020-11-30 | @Half-Shot | None | ||
MSC2781 | MSC2781: Deprecate the (reply) fallbacks in the Matrix specification | 2020-09-18 | 2020-10-10 | @deepbluev7 | None | ||
MSC2782 | MSC2782: Pushers with the full event content | 2020-09-19 | 2020-09-19 | @Sorunome | None | ||
MSC2785 | MSC2785: Event notification attributes and actions | 2020-09-20 | 2020-10-09 | @richvdh | None | ||
MSC2801 | MSC2801: Make it explicit that event bodies are untrusted data | 2020-10-01 | 2020-11-27 | @richvdh | None | ||
MSC2810 | MSC2810: Consistent globs specification | 2020-10-08 | 2020-10-08 | @turt2live | None | ||
MSC2813 | MSC2813: Widget API error handling and validation | 2020-10-09 | 2020-11-23 | @turt2live | None | ||
MSC2815 | MSC2815: Proposal to allow room moderators to view redacted event content | 2020-10-10 | 2020-12-16 | @tulir | None | ||
MSC2828 | MSC2828: Proposal to restrict allowed user IDs over federation | 2020-10-20 | 2020-10-20 | @tulir | None | ||
MSC2832 | MSC2832: HS -> AS authorization header | 2020-10-24 | 2020-12-17 | @tulir | None | ||
MSC2834 | MSC2834: Media IDs as hashes | 2020-10-26 | 2020-10-31 | @ghost | None | ||
MSC2836 | MSC2836: Threading | 2020-10-28 | 2020-12-01 | @Kegsay | None | ||
MSC2835 | MSC2835: Add UIA to the /login endpoint | 2020-10-28 | 2020-10-30 | @Sorunome | None | ||
MSC2839 | MSC2839: Dynamic User-Interactive Authentication | 2020-10-29 | 2020-10-30 | @Sorunome | None | ||
MSC2846 | MSC2846: Decentralizing media through CIDs | 2020-11-02 | 2020-12-02 | @jcgruenhage | None | ||
MSC2845 | MSC2845: Phone number lookups using third party API | 2020-11-02 | 2020-11-04 | @dbkr | None | ||
MSC2848 | MSC2848: Globally unique event IDs | 2020-11-04 | 2020-11-22 | @turt2live | None | ||
MSC2855 | MSC2855: Server-Initiated Client Clear-Cache & Reload | 2020-11-08 | 2020-12-22 | @jevolk | None | ||
MSC2858 | MSC2858: Multiple SSO Identity Providers | 2020-11-09 | 2021-01-20 | @t3chguy | None | ||
MSC2867 | MSC2867: Marking rooms as unread | 2020-11-17 | 2021-01-02 | @Bubu | None | ||
MSC2871 | MSC2871: Give widgets an indication of which capabilities they were approved for | 2020-11-20 | 2020-11-23 | @turt2live | None | ||
MSC2870 | MSC2870: Protect server ACLs from redaction | 2020-11-20 | 2020-11-23 | @turt2live | None | ||
MSC2875 | MSC2875: room descriptions | 2020-11-23 | 2020-11-24 | @ghost | None | ||
MSC2874 | MSC2874: Single SSSS | 2020-11-23 | 2021-01-19 | @uhoreg | None | ||
MSC2873 | MSC2873: Identifying clients and user settings in widgets | 2020-11-23 | 2020-11-23 | @turt2live | None | ||
MSC2872 | MSC2872: Move the widget title to the top level of the definition | 2020-11-23 | 2020-11-23 | @turt2live | None | ||
MSC2876 | MSC2876: Allowing widgets to read events in a room | 2020-11-24 | 2020-11-24 | @turt2live | None | ||
MSC2881 | MSC2881: Message Attachments | 2020-11-27 | 2020-12-17 | @MurzNN | None | ||
MSC2880 | MSC2880: extend event and state API to allow sending to all rooms | 2020-11-27 | 2020-11-27 | @ghost | None | ||
MSC2895 | MSC2895: Proposal to improve /members and /joined_rooms | 2020-12-07 | 2020-12-28 | @turt2live | None | ||
MSC2931 | MSC2931: Allow widgets to navigate with matrix.to URIs | 2020-12-29 | 2021-01-19 | @turt2live | None | ||
MSC2929 | MSC2929: Interaction events | 2020-12-29 | 2021-01-03 | @erkinalp | None | ||
MSC2938 | MSC2938: Report content to moderators | 2021-01-05 | 2021-01-19 | @Yoric | None | ||
MSC2949 | MSC2949: Proposal to clarify "Requires auth" and "Rate-limited" in the spec | 2021-01-07 | 2021-01-08 | @tulir | None | ||
MSC2946 | MSC2946: Spaces Summary | 2021-01-07 | 2021-01-19 | @Kegsay | None | ||
MSC2943 | MSC2943: Return an event ID for membership endpoints | 2021-01-07 | 2021-01-07 | @turt2live | None | ||
MSC2961 | MSC2961: External Signatures | 2021-01-13 | 2021-01-14 | @Sorunome | None | ||
MSC2962 | MSC2962: Group Access Control via Spaces in Matrix | 2021-01-14 | 2021-01-15 | @ara4n | None | ||
MSC2970 | MSC2970: Remove pusher path requirement | 2021-01-17 | 2021-01-18 | @Sorunome | None | ||
MSC2974 | MSC2974: Widgets: Capabilities re-exchange | 2021-01-19 | 2021-01-19 | @turt2live | None |
9.3 proposed-final-comment-period
MSC | Proposal Title | Creation Date | Update Date | Documentation | Author | Shepherd | PRs |
---|---|---|---|---|---|---|---|
MSC1763 | MSC1763: Proposal for specifying configurable message retention periods | 2018-12-30 | 2021-01-12 | @ara4n | None | ||
MSC2184 | MSC2184: Allow the use of the HTML <details> tag | 2019-07-16 | 2020-12-27 | @ananace | None | ||
MSC2190 | MSC2190: Allow appservice bots to use /sync | 2019-07-24 | 2020-07-25 | @tulir | None | ||
MSC2228 | MSC2228: Self destructing events | 2019-08-11 | 2020-11-26 | @ara4n | None | ||
MSC2241 | MSC2241: Key verification in DMs | 2019-08-22 | 2020-12-14 | @uhoreg | None | ||
MSC2312 | MSC2312: Matrix URI scheme proposal | 2019-10-04 | 2021-01-21 | @KitsuneRal | None | ||
MSC2320 | MSC2320: Versions information for identity servers | 2019-10-15 | 2020-04-27 | @babolivier | None | ||
MSC2326 | MSC2326: Label based filtering | 2019-10-22 | 2020-09-27 | @ara4n | None | ||
MSC2366 | MSC2366: Key verification flow additions: m.key.verification.ready and m.key.verification.done | 2019-11-25 | 2021-01-19 | @uhoreg | None | ||
MSC2475 | MSC2475: API versioning | 2020-03-27 | 2020-10-13 | @turt2live | None | ||
MSC2713 | MSC2713: Remove deprecated v1 Identity Service API | 2020-07-30 | 2020-09-09 | @turt2live | None | ||
MSC2732 | MSC2732: Olm fallback keys | 2020-08-14 | 2020-11-10 | @uhoreg | None | ||
MSC2790 | MSC2790: Modal widgets (acquiring user input from a widget) | 2020-09-24 | 2020-12-08 | @turt2live | None |
9.4 final-comment-period
No proposals.
9.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 | 2020-04-21 | 1229-1 | @ara4n | None | |
MSC1544 | MSC1544: Key verification using QR codes | 2018-08-20 | 2020-11-25 | @uhoreg | None | ||
MSC1983 | MSC1983: Supporting a reason for leaving rooms | 2019-04-30 | 2020-04-20 | @turt2live | None | ||
MSC2033 | MSC2033: Adding a device_id to /account/whoami | 2019-05-27 | 2020-08-23 | @turt2live | None | ||
MSC2175 | MSC2175: Remove the creator field from m.room.create events | 2019-07-14 | 2021-01-16 | @richvdh | None | ||
MSC2174 | MSC2174: Move the redacts key to a sane place | 2019-07-14 | 2020-05-13 | @richvdh | None | ||
MSC2244 | MSC2244: Mass redactions | 2019-08-23 | 2020-12-10 | @tulir | None | ||
MSC2265 | MSC2265: Proposal for mandating case folding when processing e-mail address localparts | 2019-08-30 | 2020-06-07 | @babolivier | None | ||
MSC2284 | MSC2284: Making the identity server optional during discovery | 2019-09-06 | 2020-04-20 | @turt2live | None | ||
MSC2630 | MSC2630: checking public keys in SAS verification | 2020-06-11 | 2020-07-23 | @uhoreg | None |
9.6 spec-pr-missing
MSC | Proposal Title | Creation Date | Update Date | Documentation | Author | Shepherd | PRs |
---|---|---|---|---|---|---|---|
MSC971 | Add groups stuff to spec | 2017-08-10 | 2020-10-27 | 971-1, 971-2, 971-3 | @erikjohnston | None | |
MSC1214 | Related Groups (i.e. flair) | 2017-10-03 | 2020-04-21 | 1214-1 | @lukebarnard1 | None | |
MSC1957 | MSC1957: Integration manager discovery | 2019-04-08 | 2020-04-20 | @turt2live | None | ||
MSC1961 | MSC1961: Integration manager authentication APIs | 2019-04-09 | 2020-04-20 | @turt2live | None | ||
MSC2176 | MSC2176: Update the redaction rules | 2019-07-14 | 2020-12-28 | @richvdh | None | ||
MSC2758 | MSC2758: Proposal for a common identifier grammar | 2020-09-01 | 2020-10-25 | @richvdh | None | ||
MSC2844 | MSC2844: Global version number for the whole spec | 2020-10-30 | 2021-01-18 | @turt2live | None |
9.7 spec-pr-in-review
MSC | Proposal Title | Creation Date | Update Date | Documentation | Author | Shepherd | PRs |
---|---|---|---|---|---|---|---|
MSC1236 | Matrix Widget API v2 | 2018-05-13 | 2021-01-04 | 1236-1 | @rxl881 | None | |
MSC1354 | Widget API extension: Always-on-screen | 2018-07-03 | 2020-11-23 | 1354-1 | @dbkr | None | |
MSC1960 | MSC1960: OpenID information exchange with widgets | 2019-04-09 | 2020-11-23 | @turt2live | None | ||
MSC2010 | MSC2010: Add client-side spoilers | 2019-05-22 | 2020-05-15 | @Sorunome | None | ||
MSC2422 | MSC2422: Allow color on font tag | 2020-01-23 | 2020-05-15 | @deepbluev7 | None | ||
MSC2765 | MSC2765: Widget avatars | 2020-09-03 | 2020-11-23 | @turt2live | None | ||
MSC2774 | MSC2774: Expose the widget ID to the widget | 2020-09-11 | 2020-11-23 | @turt2live | None |
9.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 | 2020-04-21 | 433-1, 433-2 | others, @maxidor | @uhoreg | |
MSC1197 | Ignoring Users | 2016-05-03 | 2020-04-21 | 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 | 2020-04-21 | 1200-1 | @richvdh | None | PR#1284 |
MSC1201 | Device Management API | 2016-07-14 | 2020-04-21 | 1201-1 | @richvdh | None | |
MSC1203 | 3rd Party Entity lookup API | 2016-07-21 | 2020-04-21 | 1203-1 | @leonerd | None | PR#1353 |
MSC1204 | Access Token Semantics (refresh and macaroons) - aka Auth Sept 2016 Edition | 2016-09-29 | 2020-04-21 | 1204-1 | @richvdh | None | |
MSC1205 | Proposal for multi-device deletion API | 2016-10-12 | 2020-04-21 | 1205-1 | @richvdh | None | PR#1239 |
MSC1207 | Publishing Room Lists for 3rd party networks | 2016-10-21 | 2020-04-21 | 1207-1 | @erikjohnston | None | |
MSC1208 | Encrypted attachment format | 2016-10-26 | 2020-04-21 | 1208-1 | @NegativeMjark | None | PR#1420 |
MSC739 | Reporting inappropriate content in Matrix | 2016-11-21 | 2020-04-21 | 739-1 | @ara4n | None | |
MSC1211 | Megolm session export format | 2017-01-03 | 2020-04-21 | 1211-1 | @richvdh | None | |
MSC1212 | Device List Update Stream | 2017-01-18 | 2020-04-21 | 1212-1 | @richvdh | None | PR#1648, PR#1284 |
MSC829 | Need to spec msisdn login API | 2017-03-08 | 2020-04-21 | 829-1 | @dbkr | None | PR#1390 |
MSC855 | spec m.login.msisdn UI auth type | 2017-03-24 | 2020-04-21 | 855-1 | @dbkr | None | |
MSC910 | Add new Read Marker API to docs | 2017-05-08 | 2020-04-21 | 910-1 | @lukebarnard1 | None | |
MSC953 | Add /user_directory/search API | 2017-05-31 | 2020-04-21 | 953-1 | @erikjohnston | None | |
MSC1067 | Spec @mentions | 2017-07-14 | 2020-04-21 | 1067-1 | @lukebarnard1 | None | |
MSC1033 | Doc @room notifications | 2017-10-23 | 2020-04-21 | 1033-1 | @dbkr | None | |
MSC1219 | Proposal for storing megolm keys serverside | 2017-11-23 | 2020-06-02 | 1219-1 | @ara4n, @uhoreg | None | |
MSC1227 | Proposal for lazy-loading room members to improve initial sync speed and client RAM usage | 2018-03-05 | 2020-04-21 | 1227-1 | @ara4n | None | |
MSC1183 | Document key-share requests | 2018-04-30 | 2020-04-21 | 1183-1 | @richvdh | None | |
MSC1230 | Temporary mitigation for depth parameter abuse | 2018-05-01 | 2020-04-21 | 1230-1 | @ara4n | None | |
MSC1232 | Media limits API | 2018-05-04 | 2020-04-21 | 1232-1 | @Half-Shot | None | PR#1189 |
MSC1233 | A proposal for organising spec proposals | 2018-05-10 | 2020-04-21 | 1233-1 | @ara4n | None | PR#1240 |
MSC1234 | Rich Replies format | 2018-05-12 | 2020-04-21 | 1234-1 | @t3chguy | None | |
MSC1267 | MSC 1267: Interactive key verification using short authentication strings | 2018-05-28 | 2020-04-21 | 1267-1 | @uhoreg | None | |
MSC688 | Room Summaries (was: Calculate room names server-side) | 2018-06-10 | 2020-04-21 | 688-1 | @ara4n | None | |
MSC1304 | Proposal to simplify the auth rules of m.room.power_level events. | 2018-06-13 | 2020-04-21 | 1304-1 | @ara4n, @richvdh | 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 | 2020-04-21 | @ananace | None | ||
MSC1383 | Proposal for ACLing servers from rooms | 2018-07-05 | 2020-04-21 | 1383-1 | @ara4n, @richvdh | None | |
MSC1426 | Proposal for clarifying and improving review process for MSCs | 2018-07-17 | 2020-04-21 | 1426-1 | @ara4n | None | |
MSC1425 | Room Versioning | 2018-07-17 | 2020-04-21 | 1425-1 | @richvdh | None | |
MSC1442 | State Resolution: Reloaded | 2018-07-20 | 2020-04-21 | 1442-1 | @erikjohnston | None | |
MSC1452 | Homeserver Warning Messages | 2018-07-25 | 2020-04-21 | 1452-1 | @dbkr | None | |
MSC1466 | MSC1466: Soft Logout | 2018-08-01 | 2020-05-26 | 1466-1 | @erikjohnston | None | |
MSC1497 | MSC1497: Advertising support of experimental features in the CS API | 2018-08-08 | 2020-04-21 | 1497-1 | @ara4n | None | |
MSC1501 | Room version upgrades | 2018-08-10 | 2020-04-21 | 1501-1 | @richvdh | None | |
MSC1504 | Homeserver resource limiting error codes | 2018-08-13 | 2020-04-21 | 1504-1 | @neilisfragile | None | |
MSC1659 | MSC 1659 Proposal: Change Event IDs to Hashes | 2018-09-05 | 2020-04-21 | @erikjohnston | None | ||
MSC1693 | MSC1693: Specify how to handle rejected events in new state res | 2018-10-08 | 2020-04-20 | @erikjohnston | None | ||
MSC1704 | MSC1704: Adding ?via= to matrix.to permalinks to help with routing | 2018-10-26 | 2020-04-20 | @turt2live | None | ||
MSC1708 | MSC1708: .well-known support for server name resolution | 2018-11-05 | 2020-04-20 | @richvdh | None | ||
MSC1711 | MSC1711: X.509 certificate verification for federation connections | 2018-11-07 | 2020-04-20 | @richvdh | None | ||
MSC1717 | MSC1717: common definitions for key verification methods | 2018-11-13 | 2020-04-20 | @uhoreg | None | ||
MSC1719 | MSC1719: olm session unwedging | 2018-11-14 | 2020-04-20 | @uhoreg | None | ||
MSC1721 | MSC1721: Rename m.login.cas to m.login.sso | 2018-11-15 | 2020-04-20 | @richvdh | None | ||
MSC1730 | MSC1730: Mechanism for redirecting to an alternative server during login | 2018-11-23 | 2020-04-20 | @richvdh | None | ||
MSC1753 | MSC1753: client-server capabilities API | 2018-12-12 | 2020-04-20 | @richvdh | None | ||
MSC1756 | MSC1756: cross-signing devices using a master identity key | 2018-12-14 | 2020-12-15 | @uhoreg | None | ||
MSC1759 | Room v2 proposal | 2018-12-17 | 2020-04-20 | @erikjohnston | None | ||
MSC1779 | MSC1779: Proposal for Open Governance for Matrix.org (v2) | 2019-01-07 | 2020-04-20 | @ara4n | None | ||
MSC1794 | MSC 1794 - Federation v2 Invite API | 2019-01-10 | 2020-04-20 | @erikjohnston | None | ||
MSC1802 | MSC1802: Remove the '200' value from some federation responses | 2019-01-14 | 2020-05-19 | @babolivier | None | ||
MSC1804 | MSC1804: Advertising capable room versions to clients | 2019-01-17 | 2020-04-20 | @turt2live | None | ||
MSC1813 | MSC 1813 - Federation Make Membership Room Version | 2019-01-22 | 2020-04-20 | @erikjohnston | None | ||
MSC1819 | MSC:1819 Remove Presence Lists | 2019-01-28 | 2020-04-20 | @neilisfragile | None | ||
MSC1831 | MSC1831: Change the order of .well-known and SRV discovery techniques | 2019-01-31 | 2020-04-20 | @turt2live | None | ||
MSC1866 | Add proposal for invite error code for unsupported room version | 2019-02-08 | 2020-04-20 | @erikjohnston | None | ||
MSC1884 | MSC1884: Proposal to replace slashes in event IDs | 2019-02-13 | 2020-04-20 | @richvdh | None | ||
MSC1915 | MSC 1915 - Add a 3PID unbind API | 2019-03-06 | 2020-04-20 | @erikjohnston | None | ||
MSC1930 | MSC1930: Add a push rule for m.room.tombstone events | 2019-03-15 | 2020-04-20 | @turt2live | None | ||
MSC1946 | MSC1946: Secure Secret Storage and Sharing | 2019-03-28 | 2020-06-20 | @uhoreg | None | ||
MSC1954 | MSC1954: Proposal to remove prev_content from the essential keys list | 2019-04-05 | 2020-04-20 | @neilisfragile | None | ||
MSC2002 | MSC2002: Proposal for adopting MSC1884 as v4 rooms | 2019-05-17 | 2020-04-20 | @ara4n | None | ||
MSC2077 | MSC2077: room v5 | 2019-06-04 | 2020-04-20 | @richvdh | None | ||
MSC2076 | MSC2076: Enforce key-validity periods when validating event signatures | 2019-06-04 | 2020-04-20 | @richvdh | None | ||
MSC2078 | MSC2078: Sending Third-Party Request Tokens via the Homeserver | 2019-06-05 | 2020-04-20 | @anoadragon453 | None | ||
MSC2134 | MSC2134: Identity Hash Lookups | 2019-06-15 | 2020-04-20 | @anoadragon453 | None | ||
MSC2140 | MSC2140: Terms of Service for ISes and IMs | 2019-06-20 | 2020-04-20 | @dbkr | None | ||
MSC2181 | MSC2181: Add an Error Code for Signaling a Deactivated User | 2019-07-16 | 2020-04-20 | @anoadragon453 | None | PR#2234 | |
MSC2197 | MSC2197: Search Filtering in Federation /publicRooms | 2019-07-29 | 2020-04-20 | @reivilibre | None | ||
MSC2209 | MSC2209: Alter auth rules to check notifications in m.room.power_levels | 2019-08-01 | 2020-07-29 | @lucavb | None | ||
MSC2230 | MSC2230: Store Identity Server in Account Data | 2019-08-13 | 2020-04-20 | @dbkr | None | ||
MSC2240 | MSC2240: Room version 6 | 2019-08-22 | 2020-07-29 | @turt2live | None | ||
MSC2264 | MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support | 2019-08-29 | 2020-04-20 | @turt2live | None | ||
MSC2263 | MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets | 2019-08-29 | 2020-04-20 | @turt2live | None | ||
MSC2290 | MSC2290: Separate Endpoints for Threepid Binding | 2019-09-12 | 2020-04-20 | @anoadragon453 | None | ||
MSC2313 | MSC2313: Moderation policies as rooms (ban lists) | 2019-10-05 | 2020-11-14 | @ara4n | None | ||
MSC2324 | MSC2324: Facilitating early releases of software dependent on spec | 2019-10-18 | 2020-05-21 | @turt2live | None | ||
MSC2334 | MSC2334 - Change default room version to v5 | 2019-10-30 | 2020-04-20 | @aaronraimist | None | ||
MSC2367 | MSC2367: Add reason field to all membership events | 2019-11-26 | 2020-10-07 | @erikjohnston | None | ||
MSC2399 | MSC2399: Reporting that decryption keys are withheld | 2020-01-02 | 2020-11-05 | @uhoreg | None | ||
MSC2414 | MSC2414: Make reason and score parameters optional for reporting content | 2020-01-18 | 2020-10-07 | @iinuwa | None | ||
MSC2432 | MSC2432: Updated semantics for publishing room aliases | 2020-02-10 | 2020-05-26 | @richvdh | None | ||
MSC2451 | MSC2451: Remove query_auth federation endpoint. | 2020-03-03 | 2020-04-22 | @clokep | None | ||
MSC2454 | MSC2454: Support UI auth for SSO | 2020-03-09 | 2020-05-11 | @clokep | None | ||
MSC2457 | MSC2457: Invalidating devices during password modification | 2020-03-12 | 2020-05-04 | @clokep | None | ||
MSC2472 | MSC2472: Symmetric SSSS | 2020-03-24 | 2020-06-20 | @uhoreg | None | ||
MSC2526 | MSC2526: Add ability to delete key backups | 2020-05-05 | 2020-06-02 | @uhoreg | None | ||
MSC2540 | MSC2540: Stricter event validation: JSON compliance | 2020-05-13 | 2020-07-29 | @clokep | None | ||
MSC2604 | MSC2604: Accept device information for the login fallback endpoint | 2020-06-04 | 2020-07-30 | @clokep | None | ||
MSC2611 | MSC2611: Remove m.login.token User-Interactive Authentication type from the specification | 2020-06-05 | 2020-07-28 | @richvdh | None | ||
MSC2610 | MSC2610: Remove m.login.oauth2 User-Interactive Authentication type from the specification | 2020-06-05 | 2020-07-28 | @richvdh | None | ||
MSC2630 | MSC2630: checking public keys in SAS verification | 2020-06-11 | 2020-07-23 | @uhoreg | None | ||
MSC2663 | MSC2663: Errors for dealing with non-existent push rules | 2020-07-03 | 2020-10-07 | @reivilibre | None | ||
MSC2689 | MSC2689: Fix E2EE for guests | 2020-07-15 | 2020-10-07 | @awesome-michael | None | ||
MSC2788 | MSC2788: Room version 6 as the default room version | 2020-09-23 | 2020-10-05 | @turt2live | None |
9.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 | 2020-05-16 | 1699-1 | @ara4n | None |
9.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 | 2020-08-21 | 531-1 | @Kegsay | None | |
MSC1209 | Server Side Profile API | 2016-11-01 | 2020-08-21 | 1209-1 | @erikjohnston | None | |
MSC1213 | Set defaults for m.federate | 2017-04-10 | 2020-08-26 | 1213-1 | @psaavedra | None | |
MSC1217 | Visibility of groups to group members and their non-members | 2017-10-30 | 2020-08-21 | 1217-1 | @lampholder | None | |
MSC1489 | Suggested Mentions Proposal | 2018-08-06 | 2020-04-21 | @Half-Shot | None | ||
MSC1680 | MSC1680: cross-signing of devices to simplify key verification | 2018-09-20 | 2020-04-20 | 1680-1 | @uhoreg | None | |
MSC1700 | MSC1700: Improving .well-known discovery | 2018-10-19 | 2020-04-20 | @turt2live | None | ||
MSC1714 | MSC1714: using the TLS private key to sign federation-signing keys | 2018-11-09 | 2020-04-20 | @richvdh | None | ||
MSC1722 | MSC1722: Support for displaying math(s) in messages | 2018-11-15 | 2020-10-19 | @uhoreg | None | ||
MSC1935 | MSC1935: Key validity enforcement | 2019-03-20 | 2020-04-20 | @turt2live | None | ||
MSC2233 | MSC2233: Unauthenticated Capabilities API | 2019-08-15 | 2020-04-20 | @anoadragon453 | None | ||
MSC2376 | MSC2376: Disable URL Previews | 2019-12-03 | 2021-01-14 | @Sorunome | None | ||
MSC2579 | MSC2579: Improved tagging support | 2020-05-25 | 2020-07-24 | @turt2live | None | ||
MSC2625 | MSC2625: Add mark_unread push rule action | 2020-06-10 | 2020-07-01 | @richvdh | None | ||
MSC2631 | MSC2631: Add default_payload to PusherData | 2020-06-12 | 2020-07-07 | @ismailgulek | None | ||
MSC2773 | MSC2773: Room kinds | 2020-09-11 | 2020-10-21 | @turt2live | None | ||
MSC2912 | MSC2912: Setting cross-signing keys during registration | 2020-12-15 | 2020-12-17 | @uhoreg | None |
9.11 obsolete
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 | 2020-04-21 | 455-1 | @KitsuneRal | None | |
MSC1196 | Matrix Escape Hatch (Versioned Rooms) | 2015-10-22 | 2020-04-21 | 1196-1 | @leonerd | None | |
MSC1238 | Voice messages | 2016-04-13 | 2020-04-28 | 1238-1 | @aviraldg | None | PR#310 |
MSC1202 | Profile Personae | 2016-07-15 | 2020-04-21 | 1202-1 | @erikjohnston | None | |
MSC441 | Support for Reactions / Aggregations | 2016-12-25 | 2020-04-21 | 441-1 | @pik | @ara4n | |
MSC1215 | Groups as Rooms | 2017-10-17 | 2020-04-21 | 1215-1 | @ara4n | None | |
MSC1223 | Replies event format | 2018-02-01 | 2020-04-21 | 1223-1 | @t3chguy | None | |
MSC1224 | Replies - next steps | 2018-02-03 | 2020-04-21 | 1224-1 | @t3chguy | None | |
MSC1235 | Proposal for Calendar Events | 2018-02-06 | 2020-04-21 | 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 | 2020-04-21 | 1226-1 | @richvdh | None | |
MSC1231 | Handling Consent for Privacy Policy | 2018-05-02 | 2020-04-21 | 1231-1 | @neilisfragile | None | |
MSC1194 | A way for HSes to remove bindings from ISes (aka unbind) | 2018-05-09 | 2020-04-21 | 1194-1 | @dbkr | None | |
MSC1220 | Rich quoting proposal | 2018-05-10 | 2020-04-21 | 1220-1 | @t3chguy | None | |
MSC1256 | Custom emoji and sticker packs in matrix | 2018-05-23 | 2020-04-21 | 1256-1 | @turt2live | None | |
MSC1270 | Proposal Add /_matrix/media/v1/resolve_url to Client-Server API: download and preview urls in the clients despite CORS | 2018-05-31 | 2020-04-21 | 1270-1 | @oivoodoo | None | |
MSC1308 | Proposal for speeding up review of simple spec changes | 2018-06-14 | 2020-04-21 | @ara4n | None | ||
MSC1310 | Proposal for a media information API | 2018-06-17 | 2020-04-21 | 1310-1 | @turt2live | 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 | 2020-04-21 | 1318-1 | @ara4n | None | |
MSC1410 | Proposal for Rich Bridging | 2018-07-12 | 2020-04-21 | 1410-1 | @Half-Shot | None | |
MSC1421 | Make a Discourse forum the canonical location for spec discussions | 2018-07-16 | 2020-04-21 | 1421-1 | @non-Jedi | None | |
MSC1687 | MSC1687: Encrypting recovery keys for online megolm backups | 2018-09-26 | 2020-04-20 | 1687-1 | @ara4n | None | |
MSC1695 | MSC1695 Message Edits | 2018-10-12 | 2020-04-20 | @Half-Shot | None | ||
MSC1731 | MSC1731: Mechanism for redirecting to an alternative server during SSO login | 2018-11-24 | 2020-04-20 | @richvdh | None | ||
MSC1777 | [WIPish] MSC1777: peeking over federation (via server pseudousers) | 2019-01-06 | 2020-10-28 | @ara4n | None | ||
MSC1776 | [WIPish] MSC1776: Implementing peeking via /sync | 2019-01-06 | 2020-09-05 | @ara4n | None | ||
MSC1849 | MSC1849: Proposal for m.relates_to aggregations | 2019-02-04 | 2020-07-27 | @ara4n | None | ||
MSC1888 | [WIP] MSC1888: Proposal to send EDUs to appservices | 2019-02-15 | 2020-04-20 | @Half-Shot | None | ||
MSC1943 | MSC1943: Set default room as v3 | 2019-03-27 | 2020-04-20 | @neilisfragile | None | ||
MSC1958 | MSC1958: Widget architecture changes | 2019-04-09 | 2020-11-23 | @turt2live | None | ||
MSC2229 | MSC2229: Allowing 3PID Owners to Rebind | 2019-08-12 | 2020-04-20 | @anoadragon453 | None | ||
MSC2261 | MSC2261: Allow m.room.aliases events to be redacted by room admins | 2019-08-29 | 2020-04-20 | @richvdh | None | ||
MSC2260 | MSC2260: Update the auth rules for m.room.aliases events | 2019-08-29 | 2020-04-20 | @richvdh | None |