-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3087(MX-EXT0000): Standardised extensions #3087
Conversation
Signed-off by: Erkin Alp Güney <erkinalp9035@gmail.com>
proposals/3087-stdex.md
Outdated
Currently, there is a Matrix specification, which comprises of two main | ||
documents and many supplemental addenda. The protocol itself is designed | ||
to be easily extensible, however, there is currently a gap between spec | ||
and implementation defined extensions. This defines a new RFC process | ||
akin to the one we have on MSCs, with a few differences: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Signed-off by: Erkin Alp Güney <erkinalp9035@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I basically echo what Hubert and Travis said:
- 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.
- 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.
- 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.
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 |
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: 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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Self-close to pre-empt the SCT's backlog. |
@mscbot fcp cancel |
Standardised extensions procedure proposed.