add org.matrix.msc4143.rtc_foci information to .well-known/matrix/client

[fkwp]

No description provided.

[turt2live]

per internal discussion - the namespace appears incorrect

[richvdh]

I'm somewhat uncomfortable about unspecified features like this being enabled on the matrix.org homeserver at all, irrespective of whether there is an MSC to document them.

In short, experience suggests that once it's turned on on matrix.org, people forget about the tedious work of actually specifying the thing, and before long matrix.org is implementing a whole load of unspecified features that only work with Element clients, which, apart from being a massive conflict of interest between the Foundation and Element, isn't actually great for Element because we have no coherent spec to work against.

https://handbook.element.io/books/backend-team/page/experimental-features-policy#bkmrk-widening-the-net has a bunch of detail about our policy here. It's somewhat focussed on Synapse features rather than .well-known settings, but I believe most of the ideas apply.

In particular, I'd like to see a written record of why we believe this is the best approach, and how we'll avoid falling into the traps of this becoming a de-facto part of the specification.

[fkwp]

In particular, I'd like to see a written record of why we believe this is the best approach, and how we'll avoid falling into the traps of this becoming a de-facto part of the specification.

still WIP and at an early state. Here is the corresponding MatrixRTC MSC

[fkwp]

I'm somewhat uncomfortable about unspecified features like this being enabled on the matrix.org homeserver at all, irrespective of whether there is an MSC to document them.

In short, experience suggests that once it's turned on on matrix.org, people forget about the tedious work of actually specifying the thing, and before long matrix.org is implementing a whole load of unspecified features that only work with Element clients, which, apart from being a massive conflict of interest between the Foundation and Element, isn't actually great for Element because we have no coherent spec to work against.

https://handbook.element.io/books/backend-team/page/experimental-features-policy#bkmrk-widening-the-net has a bunch of detail about our policy here. It's somewhat focussed on Synapse features rather than .well-known settings, but I believe most of the ideas apply.

In particular, I'd like to see a written record of why we believe this is the best approach, and how we'll avoid falling into the traps of this becoming a de-facto part of the specification.

With MSC4158: MatrixRTC focus information in .well-known we now motivated why we think the well-known approach is the right thing to do

MatrixRTC can use different infrastructures.
Until now backend infrastructure is provided by the homeserver. To also conform to this pattern
for MatrixRTC the most reasonable to place for the MatrixRTC focus information is the homeserver.
This puts the homeserver admin in control what infrastructure their users use for calls.
(The same as the homeserver now does for Matrix events)

Note the actual used backend infrastructure is determined for each call individually based on the various m.call.member event proposals of each participant of that specific call, where each backend infrastructure proposal is based on the individual homeserver's well-known/matrix/client -> rtc_foci information.

(There is currently a discussion ongoing if we need a separate MSC or have it as part of MSC4143: MatrixRTC with a bias toward merging it with MSC4143)

[richvdh]

In particular, I'd like to see a written record of why we believe this is the best approach, and how we'll avoid falling into the traps of this becoming a de-facto part of the specification.

To be clear: I was asking for a written record of why we believe the best option is to deploy unspecified features on the matrix.org homeserver

[fkwp]

To be clear: I was asking for a written record of why we believe the best option is to deploy unspecified features on the matrix.org homeserver

MatrixRTC will be part of the Matrix 2.0 story and will be an important part of the upcoming MatrixCon. Being able to demonstrate and ramp up MatrixRTC to a wider range includes matrix.org users as well. While the MSCs are not yet ready for FCP the bits and pieces around declaring MatrixRTC backend infrastructure via well-known and its specific JSON formatting are not controversial.

Hence, we are happy to take the risk of potential tech debt (in the MatrixRTC space) if things might turn around. I propose we approach this PR in a time boxed manner say until end of this year. After that deadline we either remove the unstable prefix from org.matrix.msc4143.rtc_foci or remove that key entirely. If we agree on that I will create the necessary follow-up draft PRs or issues.

cc @joshsimmons

[richvdh]

Hence, we are happy to take the risk of potential tech debt (in the MatrixRTC space) if things might turn around. I propose we approach this PR in a time boxed manner say until end of this year. After that deadline we either remove the unstable prefix from org.matrix.msc4143.rtc_foci or remove that key entirely. If we agree on that I will create the necessary follow-up draft PRs or issues.

Thanks Florian. It might be good to document what the expected behaviour on applications will be if the key is unceremoniously removed, to confirm we are happy with that happening.

[fkwp]

Hence, we are happy to take the risk of potential tech debt (in the MatrixRTC space) if things might turn around. I propose we approach this PR in a time boxed manner say until end of this year. After that deadline we either remove the unstable prefix from org.matrix.msc4143.rtc_foci or remove that key entirely. If we agree on that I will create the necessary follow-up draft PRs or issues.

Thanks Florian. It might be good to document what the expected behaviour on applications will be if the key is unceremoniously removed, to confirm we are happy with that happening.

SFU backend is determined by several sources:

• already present m.call.member events present in the room
• .well-known (if available)
• fall-back: hardcoded in the MatrixRTC client

so it would "fail" gracefully

[richvdh]

Ah, so applications will continue to hardcode a fallback (call.ems.host or so?), so removing the setting from matrix.org's .well-known will simply cause users to fall back to that? SGTM in that case.

Let me reiterate once more for the public record: it's disappointing not to have seen more engagement on MSC4158 in the three months since it was opened. As the SCT, we encourage implementation developers to engage with the spec process to get changes into the spec, to avoid the necessity to roll out unspecified features to significant sections of the ecosystem at short notice. If anything, it's particularly incumbent on teams within Element to do so, to avoid the perception of the Foundation giving Element special treatment.

Nevertheless: we are where we are, and this seems like a pragmatic way forward with little downside. Thank you for taking the time to set out the situation clearly 👍 .

[bluesomewhere]

@fkwp @richvdh thank you so much for the thoughtful approach here! I'm excited to see things moving forward and where the ecosystem goes with this. Please let me know if there's anything you need from me in order to keep moving 🚀

the changes got made

[ara4n]

right, i'm going to merge this based on the above sunset plan. thanks all.