Simplify the relationship between /welcome /login /register config.json .well-known and guest users

[lampholder]

Things which I would like to be true:

• /welcome /login and /register can be accessed without creating a guest user, and accessing them does not create a guest user
  • in fact, I'd like us to create guest users as late in the process as possible
• config.json can only specify a default_server_name or a default_hs_url - if you specify both, we fail completely and obviously
• we don't default to matrix.org. It's just an unexpected trap for people to fall in through misconfiguring
• if the homeserver location has been in any way derived from user input (and we fail to reach the homeserver) we tell the user to check their input
• if the homeserver location has been derived from admin configuration (and we fail to reach the homeserver) we tell the user to contact the administrator of the homeserver
• whenever we have a homeserver name available, use it in the Sign into your Matrix account on ${homeserver_name} string

Outstanding items:

• can we know the administrator of the homeserver?

---

Task list for Travis:

• Implement new default_server_config config.json option
• Validate config before the app loads, blocking if needed
• Short timeouts on validation of homeserver config (.well-known, proof of life checks, etc)
• Simplify phases behaviour for custom server options
• Fix fallbackHsUrl behaviour
• Actually implement tooltip for underlined server name
• Reintroduce .well-known lookup when someone enters their full MXID
• is_url and hs_url handling from query params
• Misc cleanup of Use validated server config for login, registration, and password reset matrix-org/matrix-react-sdk#2941
• Test cases at the bottom of https://docs.google.com/document/d/1JOJO0n2BPKCcdcchYD7zhLyORjNXWQDcdvF7CCmnZm8/edit
• Mobile guide
• Merge travis/feature/wellknown2 into develop (PR: Fix relationship between guests, .well-known, and auth matrix-org/matrix-react-sdk#3001)

[lampholder]

Related issues:

• .well-known lookup isn't playing nicely with custom servers which don't support .well-known #7875
• .well-known error is not helpful to non-expert users #7925
• Clicking login/register from the homepage's banner doesn't stop the guest's MatrixClient #8043
• Registration should also do .well-known discovery #8309
• Unable to login via .well-known to custom HS with Riot Desktop 0.17.9 #8428
• Use the homeserver in the Matrix ID if server discovery failed #8818
• Support HS display names defined in .well-known client metadata #8826
• If default_server_name is set and that server is down, Riot spins forever on startup #9112
• .well-known not honored/read on initial loading of "sign in" page #9224
• Ignore unusable identity server #9269

[turt2live]

/welcome /login and /register can be accessed without creating a guest user, and accessing them does not create a guest user

This is problematic for /welcome because of the room directory button.

we don't default to matrix.org. It's just an unexpected trap for people to fall in through misconfiguring

We have to default at some point, unless the goal is to error obviously when neither a server_name/hs_url is specified?

[lampholder]

This is problematic for /welcome because of the room directory button.

Ah yes, could we create the guest user upon first viewing the directory? Or could viewing the directory also not require a guest user?

We have to default at some point, unless the goal is to error obviously when neither a server_name/hs_url is specified?

Sounds good to me. We can (and should) ship a default config.json that sets the default_server_name to matrix.org, but having no option default to anything makes it too easy for it to look like it's working when it isn't.

This does raise a question about people migrating to the new version, but we can do a noisy blog post (and if it fails fast with easily remedyable config.json changes to fix then dilligent riot install managers won't get tripped up anyway)

[turt2live]

Ah yes, could we create the guest user upon first viewing the directory? Or could viewing the directory also not require a guest user?

Not requiring a guest leads into the question of "which homeserver are you viewing the directory for?", and discovering that, at which point you'd might as well create a guest because people are likely to click on rooms. I'd generally recommend having a guest account be created because it can be slow (see also: matrix.org)

This does raise a question about people migrating to the new version, but we can do a noisy blog post (and if it fails fast with easily remedyable config.json changes to fix then dilligent riot install managers won't get tripped up anyway)

I think in practice most people are already using matrix.org as a default, or have changed the strings as appropriate. Screaming in bright red text saying "config.json error: no default homeserver specified" is probably okay. Would we want users to still be able to log in despite this error? (using full mxids, for instance, or changing the URLs manually).

[turt2live]

Summarizing from the discussion on April 10th, UK Afternoon:

• We're going to change the config to support a wider range of options
• We'll block the UI on .well-known (with a relatively short timeout) before trying to render anything useful
• We will be more aggressive about configuration errors, to the point of not defaulting to matrix.org if the config is set up appropriately.

New app logic:

• If well known data is in the config...
  • Error if a server name or hs_url is set
  • Use the object
• else if a server name is set...
  • error if a hs_url is set
  • 10s timeout on fetch
  • loud errors on failure
  • block ui
  • use the returned config, if valid. Otherwise error
• else if a hs_url is set
  • do a proof of life call
  • if not dead, use it. If dead, error

when the user types a full mxid into login:

• if the server name matches the config, use the config
• else do lookup, normal process
• same applies to custom hs_url options

[turt2live]

also most (all?) of the issues listed above should be fixed with this new behaviour definition

[Ryonez]

Would the config issues here affect integrations and lab settings setting in the config?

As far as I can tell, the only thing being respected is the "brand" variable.

[turt2live]

Unlikely, that sounds like a different problem.

[turt2live]

After weeks (months?) of work, it's now finally up for review: matrix-org/matrix-react-sdk#3001 and co.

[turt2live]

Fixed by matrix-org/matrix-react-sdk#3001 - it won't make it into 1.2.0, but should be in the next regularly scheduled release.