Unable to deploy .well-known file to disable E2EE by default. Consider config.json alternative

[tgurr]

Description

Trying to implement #13914 I run into an issue.

I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:

{"m.homeserver": {"base_url": "https://matrix.corporate.local/"}, "m.identity_server": {"base_url": "https://matrix.corporate.local"}, "im.vector.riot.e2ee": {"default": false}}

and also in config.json of riot

    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.corporate.local",
            "server_name": "Corporate Local"
        },
        "m.identity_server": {
            "base_url": "https://matrix.corporate.local"
        },
        "im.vector.riot.e2ee": {
            "default": false
        }

Now my question is if that isn't enough and if not if we could please have the option to specify this via config.json of riot as well since that doesn't seem to work right now(?).

Because our synapse is running on matrix.corporate.local in a corporate environment where corporate.local points to the active directory servers on which I can't and also don't want to run a webserver to just serve a .well-known for the domain.

Steps to reproduce

• Have a setup like described above
• Try to implement Add e2ee-default:false docs #13914
• See Riot still creating DMs and rooms with encryption enabled by default

Version information

• Platform: web (in-browser)

For the web app:

• Browser: Chrome, Firefox latest versions
• OS: Windows, Linux
• URL: self hosted, latest riot web 1.6.6-rc.1

[t3chguy]

and also in config.json of riot

It is not a config.json option.

What do your user names look like, @bob:matrix.corporate.local? or is it just :corporate.local ?

[tgurr]

and also in config.json of riot

It is not a config.json option.

Hence my request to please add such an option.

What do your user names look like, @bob:matrix.corporate.local? or is it just :corporate.local ?

They're just :corporate.local.

[t3chguy]

Hence my request to please add such an option.

Product team specifically said well-known only

They're just :corporate.local.

Then your well-known URL is wrong;

I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:

It should be

https://corporate.local/.well-known/matrix/client

[tgurr]

It should be

https://corporate.local/.well-known/matrix/client

As I explained corporate.local points to the active directory domain controllers on which I don't want and won't install an additional web server in any form. I'm pretty sure I'm not the only one with that problem.

[t3chguy]

Sorry, missed that.

Well as per the Matrix spec, that is the only place the well-known is looked up.
https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri

[tgurr]

Hence my request to please add such an option.

Product team specifically said well-known only

Well as per the Matrix spec, that is the only place the well-known is looked up.
https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri

Maybe the product team could reconsider it's decision as there obviously seem to exist use cases for that. I fail to see where having an additional configure option would hurt.

[t3chguy]

It wouldn't apply to riot-android, riotX-android, riot-ios
the well-known route was chosen for consistency between clients (not that they support it yet but still)

the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product

[tgurr]

It wouldn't apply to riot-android, riotX-android, riot-ios
the well-known route was chosen for consistency between clients (not that they support it yet but still)

the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product

Which wouldn't be a problem (in our case) as I can and have configured a proper https://corporate.local/.well-known/matrix/client reachable from the outside/internet perfectly well. We could argue how stupid it is to have the same domain internally and externally but it's how it was done and out of my control.

[jryans]

We'll track this as a suggestion for now. I would helpful to hear from other deployments that might also be in this situation of being unable to deploy .well-known so we can consider alternative options.