[Story] Make Element Call widget URL configurable

[manuroe]

Description

• As a homeserver admin
• I want to make EX use a different EC widget URL than the default one
• So that EC works within my infrastructure.

Note: This is a temporary solution. In the future, the EC web app content will be fully embedded within the EX app. There will no more need to load it from the Internet. This setting will be then no more required.

The proposal is to use a new .well-known file: .well-known/element/element.json with the following JSON format:

{
"call": {
"widget_url": "https://call.server.com"
}
}

Acceptance criteria

• if the server provides a .well-known/element/element.json with the widget_url field, the app must use the provided URL to load the EC widget
• else, the app behaves as currently and loads https://call.element.io
• On EXA and EXI, we have a developer setting to use a custom call url. If such URL is set, it will be used and no call will be done to retrieve a custom URL from the .well-know file.
• error 404 should be consider as no custom url available (as described), but any other error (network error, etc.) should be treated as an error.
• .well-known url is built from the userId's domain, for instance @alice:domain.org -> https://domain.org/.well-known/element/element.json
• there is no cache to implement, as a first iteration, so the .well-known file is retrieved for each call.

Leads

• Tech: @bmarty

Size estimate

S

Dependencies

• None

Out of scope

• Later element.json will be used for other EC configurations or other Element Service. We focus here on widget_url as an initial step.

Open questions

Questions

Beta Give feedback

1. Should EW follow this configuration? -> Yes. We need it for ED
2. What about call.element.io links? They open the EX app if a user taps on such link. This is a build setting that cannot be changed at runtime --> We keep the default behavior. Let's see what we can do later

Subtasks

Android

Beta Give feedback

1. [Task] Make Element Call widget URL configurable element-x-android#3009
   T-Task +1
   

iOS

Beta Give feedback

1. [Task] Make Element Call widget URL configurable element-x-ios#2911
   T-Task +1

Web

Beta Give feedback

1. Make Element Call widget URL configurable element-web#27555
   A-Element-Call O-Occasional T-Enhancement T-Feature Z-Labs +5

Other

Beta Give feedback

No tasks being tracked yet.

Sign-off

Android

• QA sign-off on completion
• Product sign-off on completion

iOS

• QA sign-off on completion
• Product sign-off on completion

Web

• QA sign-off on completion
• Product sign-off on completion

[bmarty]

Note:

• On EXA and EXI, we have a developer setting to use a custom call url. If such URL is set, it will be used and no call will be done to retrieve a custom URL from the .well-know file.
• error 404 should be consider as no custom url available (as described), but any other error (network error, etc.) should be treated as an error.
• .well-known url is built from the userId's domain, for instance @alice:domain.org -> https://domain.org/.well-known/element/call.json
• there is no cache to implement, as a first iteration, so the .well-known file is retrieved for each call.

Edit All of the above has been accepted by @manuroe and moved to acceptance criteria

[gaelgatelement]

Hello,

I was just made aware of this issue, and I wondered what was the rationale in creating a new well-known file versus using the existing .well-known/matrix/client ?

It would have been much easier to use the existing file in ESS, whereas with this solution we need to implement a whole new file just for element call.

[manuroe]

It is driven by a separation of concerns between matrix.org homeserver configuration and an element.io service configuration, Element Call here.

Adding this widget_url parameter to .well-known/matrix/client would have required to create a new MSC which would have been rejected for the good reason that it is too element.io oriented.

[gaelgatelement]

It is driven by a separation of concerns between matrix.org homeserver configuration and an element.io service configuration, Element Call here.

Adding this widget_url parameter to .well-known/matrix/client would have required to create a new MSC which would have been rejected for the good reason that it is too element.io oriented.

Can we come up with a general element well known file that could be use by all the clients we build then ? So that we can add it as a long-term option in ESS ? Because I suppose such a feature could be also very useful to other clients ?

[manuroe]

We were not aware that creating new files could be a problem for ESS when we discussed it with @fkwp. Sorry for that.

I am not against having a more global solution using .well-known/element/element.json. We should probably keep each service configuration nested in the JSON file to avoid future decoding drama.
If we go .well-known/element/element.json, I would suggest the following JSON format:

{
    "call": {
        "widget_url": "https://call.server.com"
   }
}

Does it work for you @gaelgatelement ?
I will update the issue once we agree.

[bmarty]

Is it OK to add random keys in .well-known/matrix/client if their values are prefixed by domain, such as for instance:

{
    "io.element.call": {
        "widget_url": "https://call.server.com"
   }
}

I do not think it requires an MSC in this case?

[manuroe]

Discussed in a team meeting, we prefer to keep things separated and implement a separate .well-known/element/element.json file.

[manuroe]

We were not aware that creating new files could be a problem for ESS when we discussed it with @fkwp. Sorry for that.

I am not against having a more global solution using .well-known/element/element.json. We should probably keep each service configuration nested in the JSON file to avoid future decoding drama. If we go .well-known/element/element.json, I would suggest the following JSON format:

{
    "call": {
        "widget_url": "https://call.server.com"
   }
}

Does it work for you @gaelgatelement ? I will update the issue once we agree.

I updated the issue with this change. matrix-org/matrix-rust-sdk#3617 implements it.