Make registration fields respond to available registration flows from the HS

[lampholder]

We're making a change to make support for registration by phone number configurable on the HS.

Riot should detect the avialable registration flows and update its UX accordingly - i.e. if there are no registration flows for msisdn (phone number) it should not show the phone number field.

It should update live, so if the user choses another homeserver/switches to anohter homeserver using .well-known, the registraiton UX should update. Ideally we should find a way for this not to be visually too jarring.

This doesn't affect login, which should stay the same. It also doesn't stop users from associating their account with a phone number later on in user settings.

[turt2live]

This doesn't affect login, which should stay the same.

We should also be responsive to the login flows on login while we're at it, imo. Assuming we aren't already.

[jryans]

We should also be responsive to the login flows on login while we're at it, imo. Assuming we aren't already.

Is there an API that will list which 3PIDs the HS accepts at login time? I can't seem to find it. I assume such an API is needed to hide the same fields at login time.

The current detection request at login time (GET /_matrix/client/r0/login) only replies with:

{"flows": [{"type": "m.login.password"}]}

[turt2live]

Is there an API that will list which 3PIDs the HS accepts at login time?

Some discussion somewhere revealed that in fact the flows are not great to do this kind of parsing. We might want to consider an MSC to change the flows to be useful, or introduce a capability to detect this kind of thing. Capabilities are a bit awkward in their current structure, however. They require authentication to read, which is obviously not possible prior to registration/login. So long story short, changing/fixing the flows for login/registration make the most sense to me.

[jryans]

Fixed the registration flow in matrix-org/matrix-react-sdk#2551.

For login, it sounds like we'll need something else, and so we should probably file a separate issue to track it.