MSC3087(MX-EXT0000): Standardised extensions

[erkinalp]

Standardised extensions procedure proposed.

[turt2live]

This smells strongly of trying to convert Matrix to XMPP style governance where clients have to list which extensions they support so users can pick an appropriate server. We do not want this.

The unstable feature process is deliberate to ensure MSCs/ideas end up in the spec, effectively making any extension system irrelevant. We are painfully aware of some MSCs taking a literal eternity to land, however with every MSC we push into FCP we are getting better at avoiding those scenarios.

This kind of MSC is the stuff we generally like to talk about in #matrix-spec before it is opened, as this is historically not an approach we have been willing to entertain.

[erkinalp]

My intent was more of a two-track system like ISO C++ WG and IETF RFCs use, a standards track and an extensions track, with more and more extensions being merged into the mandatory standards track over time.

[turt2live]

That is very unclear in this proposal. Considering the MSC process was originally created out of MSC1779, I'd expect something of similar detail to MSC1779 for any major change to the proposal process.

[KitsuneRal]

ISO C++ workgroups do not produce "extensions", and IETF RFCs are not "extensions" either. In both cases that's just a part of the standardisation process, a playground for proposals. Our equivalent to IETF RFCs is exactly MSCs. Hint for the future: provide references to explain your sources of inspiration, and examples to be clearer in what kind of problem and how you're trying to address.

[KitsuneRal]

I basically echo what Hubert and Travis said:

1. The MSC lacks detail to the point it feels like an attempt to put a name on things that don't yet exist; there's no substance in this.
2. It seems (there are really too few things described here to be sure) that this MSC tries to introduce something similar to XMPP extensions; in that case, this MSC should show understanding of the current process and its reasons (your "why" section rather shows lack of that knowledge) and clarify why it effectively reverses the current consolidated specification approach. And then it should at least aspire to have the same level of elaboration and (most importantly) references to other sources as the respective XEP has.
3. That's another MSC that entirely disregards the structure recommended in the MSC proposal template, for no apparent reason.

Due to the reasons above, it's not even a draft for me, it's a no-go.

[ara4n]

The reason we have a single spec (containing modules for different feature profiles) is to avoid fragmentation and ensure there is at most one official specified way to implement a given feature in Matrix (for a given version of the spec). Meanwhile folks can use MSCs to go wild and propose their own experiments, and the proven good ones get incorporated into the spec.

I see no value in this proposal over the current process, and instead it risks opening the same mess that XMPP has with XEPs, which Matrix deliberately is set up to avoid.

@mscbot fcp close

[mscbot]

This FCP proposal has been cancelled by #3087 (comment).

Team member @mscbot has proposed to close this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[erkinalp]

Self-close to pre-empt the SCT's backlog.

[turt2live]

@mscbot fcp cancel