Open afterdusk opened 2 years ago
There's two parts to this:
ValueStates
Clearing stale ValueStates
helps avoid retaining information in storage that is no longer required for operation of the underlying service. In the example of end-to-end encrypted messaging, this would correspond to outdated Identity keys. The library is already able to handle such deletions and can continue to operate as long as the most recent ValueState
for a user is present.
ValueStates
Non-stale (i.e. most up-to-date) ValueStates
will need to be deleted when users leave the underlying service. In the E2EE messaging scenario, this corresponds to the messenger service deleting a user's most recent identity keys when they delete their account.
While AKD is able to continue to operate when these states are deleted, the problem arises when a user with the same label re-joins the service. When next publishing for the user, AKD will be unable to deduce the next version number to use, given that all previous ValueStates
have been deleted. Furthermore, it's not clear if the new user should share the same series of version numbers as the previous user, even if their labels are the same. In the E2EE messaging context, a new user could be the new owner of a number (and therefore label), but an entirely different person from the previous owner of the number.
For 2) I think that we could deduce the version number, in the event a node exists but there is no value states, by simply enumerating the child states of the node. N+1
would be the new version number, and we could move forward as such.
Should not have closed with #161 (magic words)
In a production system, data in storage is pruned to manage storage size and adhere to privacy commitments. For AKD, the only prunable record is
ValueState
, which contains the data payload (key material for E2EE messaging).Today, operations fail when
ValueState
cannot be retrieved. We need to modify the library to handle the scenario gracefully and propagate the information to the caller.