Ok, I’ve been staring at the Capability Token exercise for a couple of hours now, time for feedback!
My understanding of the test/solution flow goes like this:
- Alice and Bob have unrestricted access to
receive_cap_access function calls from all agents in the DNA via the init() call
- Alice first calls the
create_transferable_cap_access function where:
a. A secret is generated
b. To her own source chain, a cap grant is written, allowing anyone with the secret (a) to access her theoretical
c. Alice then calls Bob’s zome and writes via the
receive_cap_access function the secret and her agent info.
- Bob then performs
get_cap_tokens, which is effectively a crawl through his own source chain looking for any entries with alice’s ID. He finds 1. He can now, if desired, call_remote into Alice’s world and use her test_function.
3-4. the same process but in reverse with a slight difference - the function call is an assigned grant vs a transferable grant.
Hope I got that right!
Initially I couldn’t find the CapabilityGrant / CapabilityClaim structures that were being referenced in the Chapter page. I eventually dug down into: CapabilityGrant = CapabilityGrantEntry = https://docs.rs/hdk/0.0.100/hdk/prelude/struct.ZomeCallCapGrant.html. Is there a reason this structure is named differently in the gym chapter?
Is the only difference between
create_assigned_cap_access functions that the access variable is a cap secret vs a cap secret + agent name. Do we actually need separate functions to delineate these two? There’s a lot of redundant code just for 1 line to change, especially in that inputs/outputs are of the same type.
Would love to see a test actually implement access to the
test_access function before and after the claims to prove it works.
How does Bob know to check his
capAccess; will he call this when he’s rejected from accessing Alice’s
test_function, or do we have to do this periodically, or does Holochain handle it.