Element shows fatal misconfigured error when default homeserver can't be reached

[bwindels]

Element shows fatal misconfigured error when default homeserver can't be reached.

Failed to start

Your Element is misconfigured

Invalid homeserver discovery response

Potential solution

See #11655 (comment)

[turt2live]

Are you logged in?

[bwindels]

Are you logged in?

No. Just tried again, and it only shows the error when logged out. Works fine when logged in.

[turt2live]

That's currently expected behaviour :(

[bwindels]

:(

[jryans]

@turt2live How complex would it be to change this case to be a inline warning in the auth flow instead of blocking the app like this?

Blocking the entire app for what might be temporary network failure out of the user's control seems too strong here.

[turt2live]

Not difficult but does have side effects such as us having a default server again and the config being untested.

We could also retry, or put a continue anyways button on it.

[neutralinsomniac]

I know this issue seems like a minor one since most anyone using matrix will be in an internet-connect environment, but my employer uses matrix/riot on a completely closed network, which means that this bug causes any new employees to be unable to use riot at all. Is there a workaround for this?

[t3chguy]

Change the default homeserver via config.json

[neutralinsomniac]

and rebuild a custom riot-desktop for every release that comes out?

Sorry, I guess I should've mentioned that this is more of an issue with the (harder to customize) desktop build.

[t3chguy]

Or ship a config.json via GPO? https://github.com/vector-im/riot-desktop#user-specified-configjson

[neutralinsomniac]

That'll work, thank you!

[tim-seoss]

Can I have confirmation that this is definitely a dupe of #15386 please?
If-so I think it is a significant UI problem, since it creates a very poor impression if it occurs on the first visit of a new user to Element / Matrix. An extract from the quoted issue:

This looks like a serious first-impressions failure unfortunately, when encouraging others to try Matrix / Element...
What I expected to see

I think Element should try hard not to show a message which is either baffling or flaky looking to users.

Perhaps it should either retry silently, prompt the user to retry, and/or display a more human-readable message.

Thanks!

Tim.

[t3chguy]

Yup sounds like it.

[rc0r]

I'm seeing this error as well. Tried adding a config.json to ~/.config/Element but that didn't change anything.

How am I supposed to log in when I see this error?

[t3chguy]

@rc0r what exactly did you put into that config.json file and what does starting the app from the command line say in your stdout?

[rc0r]

Here's my config.json:

$ cat ~/.config/Element/config.json
{
  "update_base_url": "https://packages.riot.im/desktop/update/",
  "default_server_name": "matrix.org",
  "brand": "Element",
  "integrations_ui_url": "https://scalar.vector.im/",
  "integrations_rest_url": "https://scalar.vector.im/api",
  "integrations_widgets_urls": [
    "https://scalar.vector.im/_matrix/integrations/v1",
    "https://scalar.vector.im/api",
    "https://scalar-staging.vector.im/_matrix/integrations/v1",
    "https://scalar-staging.vector.im/api",
    "https://scalar-staging.riot.im/scalar/api"
  ],
  "hosting_signup_link": "https://element.io/matrix-services?utm_source=element-web&utm_medium=web",
  "bug_report_endpoint_url": "https://element.io/bugreports/submit",
  "roomDirectory": {
    "servers": [
      "matrix.org"
    ]
  },
  "showLabsSettings": false,
  "piwik": {
    "url": "https://piwik.riot.im/",
    "siteId": 1,
    "policyUrl": "https://element.io/cookie-policy"
    },
  "enable_presence_by_hs_url": {
  "https://matrix.org": false,
  "https://matrix-client.matrix.org": false
  },
  "terms_and_conditions_links": [
    {
      "url": "https://element.io/privacy",
      "text": "Privacy Policy"
    },
    {
      "url": "https://element.io/cookie-policy",
      "text": "Cookie Policy"
    }
  ]
}

And stdout:

$ element-desktop
/home/rc0r/.config/Element exists: yes
/home/rc0r/.config/Riot exists: no

(electron:1779): Gtk-WARNING **: 17:03:13.351: Theme parsing error: gtk.css:2:33: Failed to import: Fehler beim Öffnen der Datei »/home/rc0r/.config/gtk-3.0/window_decorations.css«: Datei oder Verzeichnis nicht gefunden
Gtk-Message: 17:03:13.397: Failed to load module "appmenu-gtk-module"
Starting auto update with base URL: https://packages.riot.im/desktop/update/
Auto update not supported on this platform

[t3chguy]

"default_server_name": "matrix.org",

You are still trying to connect to matrix.org - so if its unavailable to then the app will refuse to start.
If you are trying to reach matrix.org then you have some network connectivity (firewall/jail/otherwise) issue.

[rc0r]

@t3chguy Thanks for your help. It was a proxy issue on my side.

[WestXu]

@t3chguy Can you provide a full config.json to those like me who simply host a server on a local network without internet connection?

Tried {"default_server_name": "http://{some-ip}:8008"} but it didn't work.

I just want a nice local IM service is all.

[t3chguy]

server_name should be just that, a server_name - not a URL.
e.g mozilla.org is a server_name, their URL is https://mozilla.modular.im as resolved via .well-known

https://github.com/vector-im/element-web/blob/develop/docs/config.md

[evan0greenup]

@t3chguy I understand this decision is to protect fresh user from 3rd part untrusted homeserver. But letting user know that matrix.org is unreachable is enough, making app completely not work doesn't make any sense.

As far as I see, it would be a good idea to give the user chance to let them specify homeserver when matrix.org is unreachable.

[t3chguy]

@evan0greenup see #11655 (comment) for the plan

[Subnet-Masked]

I just installed Element-Desktop, however I am n a network that blocks matrix.org - Because of this, I am getting the screen shown in the OP which is making it impossible to sign into my own homeserver which is approved on this network. This seems like a major oversight, a client application should not fail fatally if the default option is not available and should instead tell me that that server is unavailable and give me the option to input my own.

[rmalchow]

i think it would be a great improvement if, upon a failure here, the client would simply ask for a custom homeserver instead. maybe even with matrix.org prefilled.

[wioxjk]

I encounter this on fresh windows installs. Is there a workaround for this yet?

[cxzlw]

This is not an uncommon issue. In China, the GFW (Great Firewall) blocks matrix.org, while there still exists many homeservers that are easily to connect from China. However, as Element shows the misconfigured page when it is unable to connect to matrix.org, common Chinese users cannot enter the login page and switch to other available homeservers, which makes it difficult to introduce Element (and matrix) to Chinese users because they cannot use it directly.

[cxzlw]

Because it was a product decision to not let the app start with a faulty config and that includes the default hs being inaccessible. This decision is still being reworked.

But there are users who cannot access the matrix.org server. Also, for decentralisation reasons, Element should rely on a (specific one) server, while there are lots of server offering matrix service and should enable users to use it without matrix.org. So matrix.org won't be able to stop users from using Element.

[cxzlw]

Because it was a product decision to not let the app start with a faulty config and that includes the default hs being inaccessible. This decision is still being reworked.

Then add an option to easily set another homeserver, and do anything on that server instead of matrix.org. Relying on matrix.org should be erased because it (relying) is not decentralised.

[sg-qwt]

I agree with @cxzlw. This is not an uncommon issue. This is a blocking issue that prevent all element products(web, android, everything) from being used by users from areas with heavy internet censorship. In those areas, users mainly rely on private non-blocked instances where the element products just errored out and stuck when matrix.org is blocked without letting user to configure their instance in the next step.

Other clients like fluffychat does not have this issue and limit.

[cxzlw]

Although we can bypass the verification by editting the config, or even deploy a modded Element like what @askender has done, most people dont know how or dont want to do this.

Those common people that cannot access matrix.org easily and legally have to use a third-party modded Element application (assume they dont want to learn config editting. You know, they want to use a out-of-the-box client. ).

But using third-party Element instance (or modded Element application) is dangerous because they (common people) cannot determine if there is any malicious code such as account recorder or chat recorder.

It is irresponsible to force those pitful people to use Element at that risk. We should provide the method to bypass the verification in a simple, reliable and official way.

[SteveSWang47]

My friend is in China and he knows nothing about those config-editing stuff, and it's IMPOSSIBLE for me to explain how to do it.

This behaviour makes matrix.org the CENTRALISED SERVER WHICH ENABLES USERS TO USE THE OTHER SERVERS. Thus, it is REALLY against the philosophy of Matrix protocol.

[linuxtim]

In my opinion, this "decision" equals to PURE DISCRIMINATION.

This issue is still in the "Open" state, i.e. it has not been given the status of invalid/won't-fix etc. it is merely unfinished. There are many demands placed on the time of the Matrix developers (both those who are paid for their work, and those who are not). Whilst I appreciate that this situation is frustrating, since Element is open source, you do of course have the option of contributing a fix to this issue yourself and/or sponsoring someone else to do-so.

[t3chguy]

As linked before - there is a plan - just not enough people to action it right now #11655 (comment)

Contributions welcome.

[t3chguy]

This is fixed by #25682
For deployments that wish to avoid this behaviour they should use default_server_config (either alone or with conjunction with default_server_name) - the configs for the element.io deployments and Element Desktop/Nightly will be updated to do this.