Giovanni S | Flow (2024-05-08)
Question about private Capability migration.
Lets say I have some resource
R in storage and I hand out private Capabilities, each time linking the Capability at a private path which includes the recipient's address - say /private/r_0x123
Just prior to migration, say I have three Capabilities all targetting the same R in storage but each at unique private paths. Will I still have the same granularity of control over those private capabilities after they've been migrated?
As I understand this statement from the CapCon FLIP
All existing storage links and all storage capabilities will get grouped by target storage path (/storage), and a CapCon with a unique ID will be generated for each group.I take that to mean that all three would be controlled by the same CapCon ID, meaning that I now have no way to revoke a single Capability - I'd have to revoke all of them and re-issue new private caps so I can revoke a single cap the same way I could prior to the migration. Is that right?
7 Replies
I've created a thread for your message. Please continue any relevant discussion in this thread.
You can rename this thread using
/title <new title>
If this is a technical question that others may benefit from, considering also asking it on Stackoverflow: https://stackoverflow.com/questions/ask?tags=onflow-cadenceNo, this isn't actually how the migration got implemented, this needs to get updated it seems.
For each private or public link a new storage or account capability controller gets issued. Unique source paths translate to unique capability controller IDs
@Giovanni S | Flow do you have a link where you have this from?
Found here - https://github.com/onflow/flips/blob/main/cadence/20220203-capability-controllers.md#migration-of-existing-data
GitHub
flips/cadence/20220203-capability-controllers.md at main · onflow/f...
Flow Improvement Proposals. Contribute to onflow/flips development by creating an account on GitHub.
That makes sense, thank you
not sure what I was thinking back then, and it's only been a year 😅 even the original version mentioned grouping by path (but wasn't clear source or target) https://github.com/onflow/flow/commit/4dc251c32ef8b91348bef3deff8e8b1c103509f8, and then I updated it to make it clear it's by target path https://github.com/onflow/flow/commit/9a4f57dd8c184a24e4e4503fef84c2e357541f53
but I can't think of a reason why we would have to or should do that. as you pointed out, that would result in separate links which were issued for separate control, to be grouped for no reason
I can imagine the answer is no, but asking anyway - do we have a way of knowing the capability IDs of migrated capabilities prior to migration?
not at the moment, no