-
Notifications
You must be signed in to change notification settings - Fork 22
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
[1.x] Externalize KeyPackageStorage and update join and write to storage generation API #209
Comments
Thanks for the write-up, Marta! This looks very nice to me. I believe that this will overall make all method calls to (Module any randomness that might be picked when the values are created, but semantically the values would compare equal after two calls.) |
You're right that |
Yeah, it makes sense that there is an in-memory state which can change! |
Yes, the good news is we already have this in place in order to support processing multiple messages before the user calls write to storage. |
@mulmarta was working on the write_to_storage story, and I feel like we can avoid key package interaction in there all together by just having a property of |
Closing in favor of #215 |
Background:
Part of #211
Before (0.x)
Join Group API
In the above,
join_group
internally finds the key package private key by calling KeyPackageStorage::get on (a clone of) thekey_package_store
with all key package references included in thewelcome_message
.Write to Storage API
In the above,
write_to_storage
internally deletes the key package private key used to join by calling KeyPackageStorage::delete on (a clone of) thekey_package_store
owned byclient
.After (1.x)
Join Group API
Client
joins a group in three steps. First, it parses the Welcome message which returns information needed to fetch the private key from the storage. The same function will be used to parse other MLSMessage types like Commit, Proposal. Second,Client
retrieves the private key and, third, it joins using the private key.The text was updated successfully, but these errors were encountered: