-
Notifications
You must be signed in to change notification settings - Fork 142
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
Separate principal and origin information in IndexedDB storage #2578
Conversation
This PR introduces the storage layout v4 which keeps separate digests for principals and origins. That way it will be possible in the future to determine whether a specific principal was last derived for a particular origin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just minor comments
expect(storageV4).toBeTypeOf("object"); | ||
expect(storageV4.anchors["10000"]).toBeDefined(); | ||
expect(storageV4.anchors["10001"]).toBeDefined(); | ||
expect(storageV4.anchors["10003"]).toBeDefined(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also check here that getAnchorByPrincipal
works as expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, known principals are not migrated. They cant be migrated, because the digest scheme has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using getAnchorByPrincipal
on 10003
won't work in this scenario?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it will return undefined. But the VC flow is currently the only usage of that (and it will be restored after the next login) so the impact for users should be acceptable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, understood. Thanks for the explanation.
/** | ||
* V4, indexeddb["ii-storage-v4"] = { anchors: { 20000: ... } } | ||
* */ | ||
type StorageV4 = z.infer<typeof StorageV4>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frederikrothenberger Why is there a V3 and a V4?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requirements have changed. The V3 (which was in use since December 2023) no longer stored enough information for the auto-selection for the most recently used principal.
Hence it was changed to V4, which stores the principal and origin digests separately. We still maintain compatibility with old storage layouts to prevent people losing their prepopulated identity numbers.
The errors in the comments were introduced in #2578.
The errors in the comments were introduced in #2578.
This PR introduces the storage layout v4 which keeps separate digests for principals and origins. That way it will be possible in the future to determine whether a specific principal was last derived for a particular origin.