Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to disconnect from IS if the server is unavailable #10909
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.
We just want to warn users when this occurs so that they can make an informed decision within the limitations of Matrix.
then we pop up a warning saying something like:
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:
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:
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.
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
[ Go back ] [ Disconnect anyway ] (greyed out, unclickable)
Or if we cannot reach it, then the (slightly) more succinct: