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).