Unable to disconnect from IS if the server is unavailable

[jryans]

We've added too many helpful steps to the disconnect from IS flow which try to list existing 3PIDs that may be bound. Unfortunately, this leads to an error case where you can't disconnect if the IS is unavailable.

Riot should improve messaging and error handling for this case, as it's possible your IS could be permanently unavailable, for example.

[lampholder]

We just want to warn users when this occurs so that they can make an informed decision within the limitations of Matrix.

I'd suggest:

• If the user chooses to disconnect from identity server X, and
• Identity server X is at that point in time unavailable (meaning we cannot check to see whether the user has published any third party identifiers to identity server x

then we pop up a warning saying something like:

You should remove your personal data from **identity server X** before disconnecting. Unfortunately, **identity server X** is currently offline or cannot be reached, so we can't check if it is currently processing your personal data.

We recommend that you:
- check your browser plugins for anything that might block the identity server (such as Privacy Badger)
- get in touch with the administrators of **identity server X**
- wait and try again later

                                                                               [ Disconnect anyway ] [ Try again later ]

With Disconnect anyway having the green-on-white non-default-option styling, and Try again later styled white-on-green.

The above wording is very long and very boring and probably quite confusing. We don't expect this eventuality to occur often, so it might be fine, but I wonder if @nadonomy can think of anything more succinct that gets across:

• the situation (that we can't check if your data is on the identity server because it's down)
• the recommended actions, and
• the fact that you can still disconnect if you like

[nadonomy]

What's the users context (i.e. what copy have they read) to arrive at this point? If it's implicit they're removing data from the IS can we simplify the message to:

We can't reach the identity server your disconnecting from. Try again later, or get in touch with its administrator.

[Cancel] [Disconnect anyway]

[lampholder]

It's not implicit - you can 'disconnect' your riot instance from an identity server (either by 'connecting' to a different one or choosing not to use an identity server at all). At the point of doing this, you may have threepids still publicly associated with your mxid on the identity server you're leaving behind.

In an ideal world, we'd be able to robustly cause your data to be deleted from the identity server at the point of your saying you want to disconnect. However, this is tricky to do in a robust way - we'd need a whole new layer of infrastructure for the homeserver to accept instructions to delete data from an identity server, then robustly try and get those requests to the identity server (retrying in case of failures), then asynchronously communicating the eventual success/failure state to the user, then giving the user a way to handle this state.

So instead of all that, we just query the IS to see which threepids are publicly bound, and if there are any, tell the user they should use the regular unbinding UX to delete that data before disconnecting.

But, if the IS is not available, we can't make that check.

Sometimes the IS will not be available because of a temporary failure, sometimes because of browser plugin blocking traffic (I'm looking at you, privacy badger), and sometimes because the identity server has been unplugged and thrown into the sea. If it's the first case they should try again later, if it's the second they should tweak privacy badger settings and if it's the third they should brute force disconnect because the server's never coming back to do the check.

When we can't reach the identity server we can't know what is the cause of failure.

[lampholder]

Thinking again about the UX for this, Ryan pointed out that it will usually take a little while to discover that the IS is not available, so we need both to agree a human-friendly timeout, and to include a representation of this waiting into the UX.

So I reckon it should look something like:

---

Disconnect identity server

Trying to contact identity server vector.im

(spinner)

[ Go back ] [ Disconnect anyway ] (greyed out, unclickable)

---

Then either the modal we have today (if the IS is successfully reached):

Or if we cannot reach it, then the (slightly) more succinct:

You should remove your personal data from **identity server X** before disconnecting. Unfortunately, **identity server X** is currently offline or cannot be reached.

You should:
- check your browser plugins for anything that might block the identity server (such as Privacy Badger)
- contact the administrators of **identity server X**
- wait and try again later

                                                                            [ Go back ] [ Disconnect anyway ] 

[lampholder]

And yes that is three different ways of representing UX in a single github comment; you're welcome :P

[jryans]

@lampholder What would a human-friendly timeout be here? 10 seconds?