You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Fractal we are trying to enforce that cross-signing and recovery are fully set up. We basically offer to set it up if it doesn't exist, recover if it exists or reset it if the user does not have the recovery key. All that with the Recovery API.
Some users have been complaining that the options we provide do not work when a backup exists on the homeserver but we don't have the key locally (it is not in the secret storage and it was not sent by a device after verification). The recovery state is indeed always Disabled, whether the backup exists or not.
At first, we did not check if the backup was available on the server so when it was Disabled, we would always offer to enable it. That fails with this error: "A backup already exists on the homeserver and the method does not allow to overwrite it".
Then we decided to check if the backup exists on the server and we offer to "reset" it. We do that by calling disable then enable on the Recovery API. This also fails during the call to disable with the error: "backups are not enabled", which seems to come from Backups::disable.
So it looks like there is no way with the current Recovery API to fix that state. Should it call Backups::disable_and_delete? Or even better, should it have a "nuclear" reset method that we can call directly?
The text was updated successfully, but these errors were encountered:
A nice other option would be for the SDK to detect the current problems with the recovery state, and suggest actions (possibly destructive) to take that the client can show to the user, and if the user accepts, apply those options.
In Fractal we are trying to enforce that cross-signing and recovery are fully set up. We basically offer to set it up if it doesn't exist, recover if it exists or reset it if the user does not have the recovery key. All that with the
Recovery
API.Some users have been complaining that the options we provide do not work when a backup exists on the homeserver but we don't have the key locally (it is not in the secret storage and it was not sent by a device after verification). The recovery state is indeed always
Disabled
, whether the backup exists or not.At first, we did not check if the backup was available on the server so when it was
Disabled
, we would always offer to enable it. That fails with this error: "A backup already exists on the homeserver and the method does not allow to overwrite it".Then we decided to check if the backup exists on the server and we offer to "reset" it. We do that by calling
disable
thenenable
on theRecovery
API. This also fails during the call todisable
with the error: "backups are not enabled", which seems to come fromBackups::disable
.So it looks like there is no way with the current
Recovery
API to fix that state. Should it callBackups::disable_and_delete
? Or even better, should it have a "nuclear"reset
method that we can call directly?The text was updated successfully, but these errors were encountered: