[Story] Make Element Call widget URL configurable

manuroe commented 3 weeks ago

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
- [x] Should EW follow this configuration? -> Yes. We need it for ED
- [x] 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
- [ ] https://github.com/element-hq/element-x-android/issues/3009
- [ ] https://github.com/element-hq/element-x-android/issues/3124

### iOS
- [ ] https://github.com/element-hq/element-x-ios/issues/2911

### Web
- [ ] https://github.com/element-hq/element-web/issues/27555

### Rust
- [ ] https://github.com/matrix-org/matrix-rust-sdk/pull/3617

### Other

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 commented 3 weeks ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 6 days ago

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 commented 6 days ago

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 commented 5 days ago

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

manuroe commented 5 days ago

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. https://github.com/matrix-org/matrix-rust-sdk/pull/3617 implements it.

manuroe commented 7 hours ago

Will be available on the next EX RC: EXA 0.4.16 and EXI 1.6.13.

element-hq / element-meta