MSC3923: Bringing Matrix into the IETF process

[turt2live]

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?

[vrifox]

That is such a nice idea that hopefully leads to more acceptance and usage of Matrix. 🙂👍

[turt2live]

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.

[turt2live]

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?
If accepted, the SCT continues its mission to propose Matrix as the standard for Interoperable Messaging within the IETF, using the guidelines/process defined in this MSC. Acceptance does not mean we're unable to adapt this process: just that we think the approach will work well enough to try it (and that the risk of trying the approach is reasonable).

---

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge 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.

[anoadragon453]

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.

[KitsuneRal]

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.

[turt2live]

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, still¹): 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

1. 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). ↩

[turt2live]

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 :)

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

This doesn't have spec writing considerations: merged 🎉