-
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
MSC3923: Bringing Matrix into the IETF process #3923
Conversation
That is such a nice idea that hopefully leads to more acceptance and usage of Matrix. 🙂👍 |
@@ -0,0 +1,109 @@ | |||
# MSC3923: Bringing Matrix into the IETF process |
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.
Just capturing some in-person early feedback from IETF: This appears to be a good way to approach the problem of governance, particularly when trying to integrate with the IETF.
This should be demonstrative of what we're thinking about for Matrix within the IETF process now. Please take a look so we can continue moving forwards with the plan :) What does acceptance of this MSC mean? @mscbot fcp merge |
Team member @turt2live has proposed to merge 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. |
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 looks sensible to me. I would caution branding this as "LTS Matrix" too widely however, lest implementations intended to use the wider Matrix network begin to only implement those versions. I can appreciate it being used as a framing device in MSCs though.
Just some wording changes and a clarification. Otherwise LGTM.
other process, it's very possible that one doesn't work with the other anymore. This should be quite | ||
easy to mitigate, however: because we're using room versions to contain the core protocol, servers | ||
intending to support both LTS and non-LTS versions simply implement both room versions and they'll | ||
be covered. |
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.
Does that imply effectively having two incompatible higher-level over-protocols (mainly, room versions) coexisting over the same under-protocol (the federation and a common foundation of the two room versions), segregating the ecosystem into those flying MIMI and those flying Matrix, with a small overlap where not just servers but also the consuming parties agree to use both over-protocols? Would that be different from, for example, Google/Facebook taking XMPP, with only a basic common set supported by both and therefore usable from Pidgin; or UCaaS players taking SIP and growing something on top of it that a modest Asterisk PBX has not much to do with? Not that I have a better solution, just trying to map a potential direction it would take.
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.
We're not expecting the IETF spec to diverge from regular Matrix too far, but it's certainly possible. The plan to handle this is to ensure the protocol is structured such that it can be contained to purely room version changes (API/transport differences are also possible, though less likely and more easily mitigated). By keeping everything in a room version, it means we can literally copy/paste the IETF spec into regular Matrix as needed (through the MSC process, still1): server implementations honouring the regular Matrix spec will therefore be encouraged to implement that room version, just as they would be today if we introduced a whole new version.
Today's server implementations shouldn't see much impact, if any at all: room versions going to the IETF should effectively be clones of what Matrix already has, just renumbered to handle the risk of change. Worst case is Matrix ends up shipping two room versions in close proximity (say, 11
and I.1
) with different semantics, though that's no different than us dropping v3 on the world and a month later releasing v4: it's still [annoying] effort, but contained to room versions. IETF room versions are expected to be every N years as well, making the chances of an annoying conflict even smaller (or less dramatic, at least).
Footnotes
-
The expected flow for room versions is regular Matrix to IETF, however changes are possible in the IETF process and we'd need to solidify the number anyways. The MSCs which bring the IETF room versions back to regular Matrix would intentionally push all improvements out to other, dedicated, MSCs (like we've done for edits, reactions, etc). The FCP on these MSCs would be asking if there's any good reason to not include that room version in Matrix, such as in an extreme worst case where the IETF room version violates the principles of Matrix (which shouldn't happen anyways: IETF is pretty aligned in the areas that matter). ↩
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.
for the record, out of band we're talking a lot about how an LTS version of Matrix might work, or at least the stepping stones to get there. There's still belief that the process proposed here will function, though there might be some work to get to this point - more to be revealed as we continue to explore this space :)
Co-authored-by: Andrew Morgan <[email protected]>
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
This doesn't have spec writing considerations: merged 🎉 |
Rendered
Note: This MSC does not require an implementation, as one is not possible. This MSC exists for discussion purposes relating to the governance of the Matrix.org Foundation and the surrounding specification.
FCP tickyboxes
What does FCP mean on this?