Store identity server in Account Data and support choosing identity server integration in User Settings

[lampholder]

Additional requirements:

• when we change IS, we'll need to fetch its policy docs and capture that the user has agreed to them
• we should probably also validate that it's really an IS
• we should also somehow validate that the HS permits access to this IS if it maintains a whitelist...

[nadonomy]

After validating today, latest comps are in Zeplin: https://zpl.io/brMdWo3

[dbkr]

One thing that's not clear on this is how this should work with all the other places that specify ISes, ie. if the one you had at login time (be that from your client's default, .well-known or entered), is that then discarded in favour of using the one in your account settings? I'm going to assume so for now.

[jryans]

Another complexity is that (similar to the Disconnect button in #10425), we need to ensure all your 3PIDs are unbound (both on the IS itself and also the HS record of where your 3PIDs are bound) before actually changing the IS.

[lampholder]

One thing that's not clear on this is how this should work with all the other places that specify ISes, ie. if the one you had at login time (be that from your client's default, .well-known or entered), is that then discarded in favour of using the one in your account settings? I'm going to assume so for now.

We should no longer have an IS 'supplied at login time' - rather there is a 'default' that is 'the Identity Server the client would prompt to use if asked to do something identity servery and the user has not made an active choice to use either a different identity server or no identity servrer at all'.

This 'default' could be specified in the config.json or in .well-known (I can't think of anywhere else sensible to provide this at the moment), or it could not be specified at all.

There is an unanswered question about what we do if an admin wants to provide a matrix stack with a locked-down IS choice. I think answering this question is hard, so despite the risk of our painting ourselves into a corner with the proposed, I'd like to keep a lid on this for now and tackle it if/when we have a concrete usecase to consider.

[dbkr]

The nice inline terms dialog has been spun out to #10539 as it's not as critial-path as the rest of this.

[dbkr]

Second part of this is done. I think @turt2live is working on the first part.

[manuroe]

Kamino cloned this issue to vector-im/riot-ios

[turt2live]

I've reclaimed this for the storing in account data part. matrix-org/matrix-react-sdk#3300 has been added to "in test" for Dave's portion of the work.

MSC I need to care about: matrix-org/matrix-spec-proposals#2230