Feedback needed

Learning Library Holochain Gym
#1

Hi! I just published the demo section for capability tokens:

Does it make sense? Would you need some more steps, descriptions or clarifications?

This is the first time that we use the “Run Steps” block, so I want to make sure that it’s useful to advance in using it in other exercises when appropriate.

5 Likes
#2

Gosh I love those interactive examples.

Tomorrow night I’ll have a go at the exercise and see how far I get, then I’ll provide some more detailed feedback. First impressions: good layout + concise presentation :+1: Another thing is that the Subconscious Checks subsection is interesting to read, and I think it’d be great to start off that section with a gentle (and brief) refresher of what the subconscious is and whether or not the developer needs to configure this later (with a guide in the advanced section) or if it’s truly ‘set and forget’. I don’t think we’ve encountered much talk about the subconscious so far, from memory…

1 Like
#3

Right yeah thanks, I think we need a section as the first intermediate part that explains that holochain is doing much more than you think under the hood. For example, this capabilities thing is nothing you can configure, it’s there by default and enforced by core as a matter of security. But other things are more configurable. Good catch :+1:

#4

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:

  1. Alice and Bob have unrestricted access to receive_cap_access function calls from all agents in the DNA via the init() call
  2. 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 test_access function
    c. Alice then calls Bob’s zome and writes via the receive_cap_access function the secret and her agent info.
  3. 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!

Questions/Comments:

Initially I couldn’t find the CapabilityGrant / CapabilityClaim structures that were being referenced in the Chapter page. I eventually dug down into: CapabilityGrant = CapabilityGrantEntry = hdk::prelude::ZomeCallCapGrant - Rust. Is there a reason this structure is named differently in the gym chapter?

Is the only difference between create_transferable_cap_access and 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.

:parrot:

#5

Awesome :smiley: Thanks @_pyramid.

So actually this exercise was done by @josh, so I’ll let him chim in and comment if he wants.

Holochain does handle everything under the hood, looking for an alive capgrant in your source chain that matches what function is being called.

Maybe we need to come up with a concrete use case to not have the functions so confusing, but instead have the captokens be a fundamental piece in the natural flow of the dna code? Any ideas @josh?

Thanks for the feedback :slight_smile:

2 Likes