@AdriaanB it took me quite a while to grok capability tokens and what they can be used for. I eventually figured out that capability-based security is only relevant when one entity has total custody over a resource. At the OS level, that could mean that only the kernel has direct filesystem access, and when processes think they’re writing to a file they’re actually writing to a stream that the OS provides. Within Holochain, that could mean that Alice gives Bob the permission to ‘call’ zome functions in her instance, but actually what’s happening is that Bob asks Alice to call the functions and she does it on his behalf.
Public data on the DHT is different, though, because everything’s out in the open (even encrypted data that’s ‘hidden in plain view’). You can’t control access, because it’s kind of a data storage commons. So what you do instead is have a set of shared rules, enforced by the commons, about what can and can’t be done. Here’s how it applies to Holochain:
What can and can’t be done: The way you ‘do’ things in Holochain is by publishing an entry. That’s how you make actions real. Examples:
- Publishing a DNA entry at the beginning of my source chain is me saying “I’ve seen the rules and I agree to abide by them”. The action is me committing to the shared rules of the commons.
- Publishing my agent ID entry as the second source chain is me saying “I claim that I have a right to participate in this space as an agent”.
- Publishing any ‘app entry’ could constitute any sort of action — proposing or accepting a transaction, sending someone a message, revising a wiki article, etc.
- The shared rules are the validation functions that allow my peers to check whether my ‘actions’ (the entries I publish) are legitimate. If they’re proven invalid, that gives my peers the authority to take action against me (refuse my data and blacklist me).
- The commons is the DHT of peer validators.
The design for this can look a lot like capability tokens — you’re given a ‘token’ of some sort that proves that you have permission to do it — but the guts look different because of how the resource is controlled (or not controlled, in the case of public data). I’ve written about it a bit in the Privilege Certificate pattern.
I’m having a hard time figuring out where your example falls — giving access to public encrypted data by handing out the decryption key. Sorta feels like halfway between capabilities and privilege certificates, eh?
(NB this pattern language section of the forum is very new. I encourage you all to critique the first few articles, comment, make edits, add new patterns, etc.)