facebook / akd

An implementation of an auditable key directory

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Handle absence of ValueState

afterdusk opened this issue · comments

commented

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.

commented

There's two parts to this:

1. Stale 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.

2. Non-Stale 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)