Private keys system

Technical Discussion App Development
, ,
#1

Hi :slightly_smiling_face: I’m a student of the University of Bologna (Italy), we’ve started a new school project with the Holochain technology. We’re searching for a project examples or specific implementing documentation about the private keys system (eg. like wrote here: https://developer.holochain.org/docs/glossary/#public-key-cryptography). Could you kindly help us please?

Really many thanks!

Chris

#2

hey, exciting to hear you’re using Holochain for your project! Could you tell me a bit more about your project and how it’s using public/private key cryptography? Then we can talk about what already exists in Holochain and what would need to be hand-built for your project.

#3

Hi @pauldaoust :slight_smile: thanks for your reply!

We’re making a project to handle personal data with the Holochain technology. We’d like that a user can store its personal data in Holochain and decide who share them with (i.e. a fake hApp “Facebook”). Could you recommend us how could we reach this goal? Should we use only public entries (that allow anyone to view the content) or also private entry, where the “Facebook” ask the user to view its data and the user can allow or deny …? With the private entries however when a user is disconneted the “Facebook” will not be able to ask the data, right?

Really many thanks!

#4

RIght, and that’s both a bad thing and a good thing – bad for UX but good for user agency :slight_smile: There are a few different patterns that balance privacy and availability of data:

  • Private entries are the ultimate in privacy but require the user to be online if anyone else wants the data
  • Public data is accessible to everyone in the group
  • You can ‘fork’ one DNA to make multiple little DHTs to emulate private groups, though I think discrete groups don’t accurately model the wonderfully messy web of overlapping social circles and the varying degrees of privacy I want to exert in each circle – and the smaller the group, the less resilience there is in the DHT data (sometimes everyone’s offline)
  • Encrypting public data before sending it to the DHT lets you share it with exactly who you want to share it with – you just create one symmetric key and encrypt it separately with each recipient’s public key, so only they can access the symmetric key. The tricky thing with this is that, unlike with private entries or private group DHTs, you can’t revoke access later.

As you can see, each of these involves a trade-off of some sort.

#5

Is it possible to set a fixed date, after which these entries cannot be read and i’m able to permit access for public again or not?

#6

unfortunately not. If someone has the decryption key and the encrypted data, they can do whatever they like with it. You could, however, increase friction re: accessibility of that deleted stuff by writing your app’s “get posts from user” function to filter out entries marked as deleted – at least then the user would have to be a programmer in order to get that stuff off the DHT.

One advantage that private (forked) DHTs have over encrypted public data is that you can control access in a more granular way. At some time in the future at least, you’ll be able to delete an agent ID entry and effectively expel them from a DHT (with a suitable validate_delete_agent_id, of course, to make sure only the right people can expel others). Heck, maybe that already works! I know the validation function does, but I don’t know if it actually results in the owner of deleted agent ID getting bumped from the network.

#7

Hi @pauldaoust! :slight_smile:

We’d really like to describe you our idea of ​​project. We’re going to create a very very simple “Facebook” in Holochain. I attach a behaviour schema screenshot of it. We think about a single hApp, maybe with a single or more zomes, where a every single agent (a human person) can start its application, where first of all in the init () function it attaches its public key to the DNA hash (that it’s public and common among all agents), with a specific tag “registered_user” (this will be useful later) like:

hdk :: link_entries (&dna_hash, &entry_address," registered_user "," ")?

The first homepage of our dummy “Facebook” show a list of all users (since we take it for granted that all agents will be registered) with all nicknames, and when a user click on one of that nicknames will enter in its “profile page”. Here will be shown personal informations (stored as public and/or private entries) and posts (again stored as public and/or private entries).

An agent can store its personal information (maybe organized in a some structured data type - like name and surname, email and so on) and posts (public or private, with only simple text) in a public or private entry linking it to his personal public key, like:

hdk :: link_entries (&agent_address, &entry_address," personal_data "," ") ?;
hdk :: link_entries (&agent_address, &entry_address," post "," ") ?;

A user can retrieve all registered nicknames (same as personal information or posts) with:

hdk::utils::get_links_and_load_type( &agent_address, LinkMatch::Exactly("registered_user"), LinkMatch::Any, )

Finally, in the “Facebook” homepage we’d like also to show a small list of latest posts.

When we talk about private entries we meaning that an agent that try to retrieve such information will ask for them, starting from the desired agent’s public key, and will be [automatically] approved only if the desired agent is online; because if he’s offline data won’t be retrieved.

This maybe could be similar to the 6th and (unfortunately) last tutorial on Holochain developer site, called “[Simple Micro Blob Tutorial] (https://developer.holochain.org/docs/tutorials/coreconcepts/simple_micro_blog/)”.

Schema
Schema1920×1080 193 KB

Really many thanks,
Chris

#8

Hi, Chris. Thanks very much for this detailed concept – it really helps me understand what you’re thinking, and moreover it shows me that you really ‘get’ how to use Holochain’s tools to design your app! :clap: :clap: :clap:

Your basic ideas are all really solid and I think they’re all you need to get going on a good design.

That said, I have possibly unhappy news for you: we’ve dropped support for the version of Holochain that you’ve been drafting a design with, because there were some architectural issues that made it hard to ensure the correctness of the codebase. That meant that there were bugs – lots of them, hard to debug, and we ultimately made the hard decision to scrap the codebase.

Fortunately we’d already started rebuilding a new version of Holochain with a simpler, faster design, and as of this week it’s proven in real-world tests that it’s working exactly as it was supposed to work :tada: What that means is that you’ll have to reframe your ideas in a new SDK. (I hear from devs that the new SDK is a lot nicer/simpler though.) Here’s a guide that will help you update your code.

The biggest two differences that you’ll need to concern yourself with are:

  • Links now have no type – just a tag, a bunch of bytes, but you can put a ‘type’ in your tag and do a get-links search on that text. If you want to add extra information into the tag, the tag search is a ‘starts-with’ search so that should be easy.
  • Rather than using node-to-node messaging to ask someone else to give you their private entries, you can just make a call to one of their zome functions. The new Holochain exposes a DNA’s public functions to both the user’s UI and to all other peers on the network – but the user has to grant them access first. This is done via capability grants/claims, and we’ll be publishing a new Core Concepts in the next couple weeks that talks all about remote function calls and capabilities.
  • One last thought about linking everyone’s usernames to the DNA hash. While this is possible and would make usernames very discoverable, the risk is that it creates a ‘DHT hot spot’ – the poor peers responsible for that DNA hash will have to store a lot of links and serve a lot of get-links queries. Better to do it with an anchor (see the Core Concepts page on links; it talks about anchors) and ‘shard’ it – that is, break it into a bunch of sub-anchors. The new SDK has anchors built right into it, with sharding support. The default sharding strategy just breaks an anchor into pieces – for instance, an anchor like all_users might become a, al, all, all_, all_u, all_us, and so on. This means the anchor is the responsibility of nine neighbourhoods who each only have to store one-ninth of the links, though it does mean that anyone who wants to get the list of users will have to query all nine neighbourhoods, so it’s a limited strategy. A good sharding strategy that supports type-ahead username search might be to create a root anchor like all_users, then create sub-anchors as needed to hold usernames by the first n letters. For instance, registering the username krystian95 would cause the sub-anchor all_users.kry to be created and linked to all_users, then your username would be linked to that sub-anchor. That way, when people start typing in your username they will only be putting a demand on one small part of the DHT – and they don’t to retrieve and sort through as many links! And in addition to that, you could add the entire username to the link tag and do starts-with search to narrow the results even further. Just some thoughts for better UX – depending on who’s using your experiment, you may not need this level of optimisation.

Edit: Here’s a link to the new Core Concepts, currently in draft mode. Core Concepts RSM-Working Doc - Google Docs

Edit #2: @carolyn @bear @e-nastasia @guillemcordoba @hedayat @sidsthalekar are there any ‘architecture/design best practices’ resources we can share with Chris and his team?

#9

Not formalized that I know of. @hedayat - do you know?

Also, @robot5x - this might be helpful and/or of interest to you -

1 Like
#10

At the moment we have no public architect material, especially with this need and especially on RSM.

But I would like to ask @Krystian95 to continue this thread. Please keep going and share more about your challenge in design.

#11

Hi :slight_smile:

We’d like to get some clarification on how private data is handled in the Holochain.

We did some tests, for example with 3 peers. If one of these 3 goes offline (closing the terminal window) and then comes back online, the public entries are still visible (probably due to the gossip among the peers) but what that we don’t understand is how private entries work. When the peer comes back online all its private entries no longer exist, the same goes for the headers of these private entries (stored in the DHT). Is it the normal functioning of Holochain or am we’re doing something wrong?

Another question we have about private data is whether the owner of the data can give permission to other peers to read his private data or if the private entries can only be seen by the owner?

Really many thanks to all!

PS: soon we’ll update you all with our progress. We’ve created up to now a “public_post” entry, that’s linked both from an anchor “anchro_public_post” (to easly retrieve all public post to show in the Homepage) and from the user address (agent_id). We’re currently doing the same for the “user_data” entry (some - public - informations about users, that they can save in our application). And the same we’ve also already done for the “registered_user” entries, all linked to a public anchor “anchor_registered_user”, to easly retrieve all registered user - to show in the Homepage (automatically registered while page loading - with their agent name).

Chris

#12

Thanks @pauldaoust I think this is what I’m hanging out for! and this is also the answer to @Krystian95’s second question. If there is any examples available for this I would love to see it, since it is the core of what I’m trying to do with a healthcare proof of concept for my research (my question asked here).
Sorry to hijack the thread, @Krystian95 would love to know if you make progress with capability grants or any other issues you identify with access control in holochain! thank you.

#13

holochain-run-dna by default is temporary, it means your data will be lost when you exist conductor. So this one can cover loosing private entries topic. Why you have access to DHT entries or public data? maybe because of another running instance of conductor.
holochain -i can support you to maintain the data after closing conductor.

if you face other scenarios, please share more detail.

This is the exact meaning of Capability token. Please read this blog and search it concept in the forum.

and in this document read Chapter:
08. Calls: Communicate With Other Components And Peers

#14

This is a little bit old, from Barcelona Hackathon 2019. But you can receive an overview of Capability in practice.

#15

thank you very much. I will start another thread about this link so I don’t hijack OP’s post.