Private vs Public DHT

rlkel0 · October 31, 2019, 12:35am

I notice in the docs it says here https://developer.holochain.org/docs/guide/zome/read_and_write/#entry-sharing

I was wondering if you had an example of updating your private chain but allowing other entities to view it. I’m just curious how you could allow an agent to make a todo list and then make an address whitelist. This seems pretty close: https://developer.holochain.org/docs/guide/zome/capabilities/#grant-capabilities and this example https://github.com/holochain/holochain-rust/tree/f6d4e7141caecd7bf603c19174cf44a5318b5638/app_spec_proc_macro/zomes/blog lay out some of the foundations.

github.com

holochain/holochain-rust/blob/f6d4e7141caecd7bf603c19174cf44a5318b5638/app_spec_proc_macro/zomes/blog/code/src/blog.rs#L133


}


fn memo_entry(content: String) -> Entry {
    Entry::App("memo".into(), Memo::new(&content, "now").into())
}


pub fn handle_post_address(content: String) -> ZomeApiResult<Address> {
    hdk::entry_address(&post_entry(content))
}


pub static BOB_AGENT_ID: &'static str =
    "HcSCJCqoIY3uwiw34acyvNmJMyzkk4y9groHdYKBekqp7y48mvwfVTQQkzcjnfz";


fn is_my_friend(addr: Address) -> bool {
    addr == Address::from(BOB_AGENT_ID)
}


pub fn handle_request_post_grant() -> ZomeApiResult<Option<Address>> {
    // we may want to extend the testing conductor to be able to make calls with
    // arbitrary provenances.  If so we could get the caller we want from the
    // CAPABILITY_REQ global like this:

Another example might be this: Say I would like to have a blog on my private chain and I want to have a whitelist of people that can comment on it. People request to add a comment, and then once I approve it they’re added to my whitelist. And let’s say add to my whitelist is a private function on my personal chain. I don’t see any examples of private functions yet, and I’m not sure the right way to implement this pattern.

I realize these are a little off, but I’m looking to figure out the general idea around something like this:

fn add_to_whitelist(address).  // a private function to add a user to my whitelist
pub fn request_comment(address, comment). // a public function to request to add a comment
fn approve_comment(address) // private function that approves adding a comment
pub fn get_post(address) // gets a post and all approved comments for it if you're on the user's whitelist

pauldaoust · October 31, 2019, 3:54am

Ahhh @rlkel0 it warms my heart to see you digging in so deep and grokking Holochain so quickly. I would say that you’re bang-on in exploring capabilities for giving selective access to your private chain entries. It’d be good for super-private things like password managers, health records, etc. The ‘address whitelist’ would be built by creating ‘assigned’ grants for each privileged reader’s public key.

The private blog with commenting is an interesting application. While you could definitely keep the blog private on your source chain and allow agents to read and publish by granting them corresponding capabilities, it feels more idiomatic to set up a private DHT for your blog and all its authorised readers. You can’t selectively grant/deny read access in this case — access to the private blog DHT implies total access to all blog entries and other people’s comments — but it does give commenters the power to post comments on their own chains.

Also keep in mind that capability-based security is all about granting others access to a resource you control (that is, your source chain and your running DNA instance) so it only works when you’re online. That’d be another good reason to explore the ‘private DHT’ idea for the blog scenario; others could replicate your posts and read them while your device is turned off.

Here are some patterns to explore for capabilities, private DHTs, and selective write privileges:

Capability Delegation
Member Whitelist
Membership by Invitation and Lobby (some features required for these patterns aren’t implemented yet)
Benevolent Dictator
Privilege Certificate

rlkel0 · October 31, 2019, 7:09am

I’m glad to hear we’re on the same page. I’m just really concerned, as someone that has worked in app development, about authentication. When I build a REST or graphQL API, one of the first things I try to set up, even if it’s trivial, is a pattern for authentication/security. So as I study holochain, I am immediately interested in questions pertaining to permission. Here’s an idea I’d like to explore.

Let’s use a doxing as an example of a deplorable act that happens in social media.

If I have a distributed twitter, and someone doxes me, how do I erase this entry? I completely agree with the concept that it’s impossible in a blockchain because that goes against the definition of a “block chain”. In holochain there are other patterns that could be used. From what I understand, the commonly accepted example is a “forgettable” chain that isn’t commited until it’s ready, at which point the user commits it to their permanent chain, and they are responsible for its implications. This seems very coherent, and like any form of data, it will die if people stop caring about it. I could regularly fork my chain, and my followers would just keep up with it.

My concern is in building a scalable application, if a user uses their private key to cosign a transaction, that might be more powerful an action than the user might realize and people could unknowingly contribute to a doxing. So I would like to allow people to say, through their ledger: “you did this but I do not approve and I will not persevere it”.

Anyways, this is a challenge for me to build an application on an immutable ledger, and I’m excited to continue the dialogue. I find the patterns you present extremely interesting and helpful in understanding the underlying tools, but I struggle relate them to the hdk at times. How would you create interoperability between these temporary chains and a longer lasting chain?

I’ll follow up later with a more technical explanation of the issue I’m running into.