Expose server_name as a Riot config.json option independent of default_hs_url.

[lampholder]

I think the only consequence of this would be that the mxid dropdown on the login page could read:

Sign in with [ lant.uk Matrix ID    ▼ ]
             | Email Address          |
             | Phone                  |
             `¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯`

rather than

Sign in with [ matrix.lant.uk Matrix ID ▼ ]

Which is nice for hosted homeservers.

[turt2live]

Wouldn't this be fixed with .well-known and the eventual redesign that drops the entire dropdown?

[lampholder]

When .well-known is in place would we just replace the default_hs_url config option with a homeserver_name one and expect riot to resolve the server name lant.uk to matrix.lant.uk via .well-known?

[turt2live]

I don't imagine we'd replace the option, but it would mean that people logging in with @alice:example.org would see "example.org" instead of "matrix.example.org"

[lampholder]

Even with .well-known in place, it will be common for people to run their own instance of Riot and provide a default homeserver (the one people will try to log into if they only provide a username and not a full mxid). Unless we want to change the UX globally for people to consider their full mxid as their primariy identifier (rather than the username), we will need the login page to advertise which homeserver it considers its default.

The default HS is and will remain a property in config.json. The question is, what value are we putting in there? Our options are:

1. just the server URL (e.g. https://matrix.lant.uk), leaving the client unable to use the server name as part of its UX (what we have today)
2. just the server name (e.g. lant.uk), leaving the client to do a .well-known lookup every time to find the server URL
3. both (e.g. {"serverName": "lant.uk", "serverURL": "https://matrix.lant.uk"})

I think option 3 is neatest, since it means we don't have to do a .well-known lookup every time (also meaning that people running matrix homeservers don't have to set up .well-known in order to operate their homeserver).

@turt2live what do you think?

[turt2live]

The whole concept of a default server seems to be at odds with the redesign. As far as I can tell, the redesign assumes the user will be logging in with their full identifier, therefore not requiring a default server.

If we are adapting that concept to have a default server, I'd be more in favour with having the client do a transparent .well-known lookup. In practice, synapse should be supplying it for everyone and it means having the url in less places. If the url ever has to change (which does happen), the config.json is something that can easily be forgotten. Although there's also concerns that changing the url without considering existing clients will break a lot of users.

[nadonomy]

The whole concept of a default server seems to be at odds with the redesign. As far as I can tell, the redesign assumes the user will be logging in with their full identifier, therefore not requiring a default server.

Fwiw, this part of the redesign is pretty short sighted and doesn't really represent either how things work or how we want things to work. I have on my list to tackle this and get more clarity on the login/sign up flows within the next week.

[lampholder]

After discussion, we agreed:

• we would very much like configuration of riot to be simple, so we'd like to encourage the setting of a single parameter (serverName?) in config.json, which riot would then apply the .well-known lookup to to discover the homeserver url
• to allow for usecases in which setting up .well-known is not possible, we would still allow the default_hs_url to be specified - this would be discouraged rather than deprecated/disabled.

@turt2live does that sound right?

[turt2live]

After some more discussion, we came to the conclusion that a server_name and hs_url specified in the config at the same time is invalid. Independently however, they can be used. When using a server_name, we do a .well-known lookup to acquire the default homeserver info whereas just the hs_url leaves us with the current behaviour today.

[turt2live]

Fixed by matrix-org/matrix-react-sdk#2327