Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle absence of ValueState #130

Open
afterdusk opened this issue Jan 21, 2022 · 3 comments · Fixed by #161
Open

Handle absence of ValueState #130

afterdusk opened this issue Jan 21, 2022 · 3 comments · Fixed by #161
Labels
enhancement New feature or request

Comments

@afterdusk
Copy link
Member

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.

@afterdusk afterdusk added the enhancement New feature or request label Jan 21, 2022
@afterdusk
Copy link
Member Author

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.

@slawlor
Copy link
Contributor

slawlor commented Feb 9, 2022

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.

@slawlor
Copy link
Contributor

slawlor commented Mar 15, 2022

Should not have closed with #161 (magic words)

@slawlor slawlor reopened this Mar 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants