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
I'd rather focus on development at the moment, but briefly:
The reason this is so is because identities are tied to long-term keys that are generated at contract creation. These keys can be rotated, but there always is a chain of trust that ultimately can be linked to these initial keys. In GI, when one uses a password, the account is 'recovered' and these main keys are recovered.
Drawing a parallel to Signal, these keys are local to the device, and so, installing Signal again (or getting a new device) involves re-registration, with the effect that the account is essentially 'fresh'. I'm not sure if the folks at Signal have addressed this with cloud or other backups, but theoretically they could handle it this way.
Whether this is desirable or not (referring both to Chelonia and Signal) is debatable and depends on the trust model and underlying assumptions made. However, I think Chelonia is superior because:
Re-registration can happen if desirable
Nothing stops an implementation from making device-local keys only
Nothing stops an implementation from showing key rotations, even without re-registration. This would help maintain a long-term identity with device-local keys while still showing counterparties that a new device is in use.
Problem
The docs don't mention something important that people might want to know about SP:
Solution
Explain why this is and how it works.
The text was updated successfully, but these errors were encountered: