Hello @AdriaanB — I forked this off to a new discussion because it felt like a separate topic; hope you’re okay with that. If not, let me know and I’ll re-merge.
Holo Host is a weird situation. Sovereignty is the big selling point of Holochain, so we want Grandma to preserve her sovereignty. This is all about who has access to her private key, because that’s the key to her source chain. That’s easy with Holochain proper, because her private key lives on her device. But with Holo Host, if we let a host store her private key, it could impersonate her. So what do we do?
The browser generates the private key and keeps it in memory. When the tab is closed, the private key ceases to exist. So to answer half of your question, the private key is not stored anywhere.
But wait! With all those private keys being generated, how do we maintain a consistent identity? Easy: the key is always the same every time it’s generated, using a ‘seed’ made out of:
- Grandma’s email address
- Grandma’s password (which never gets transmitted over the wire)
- A public ‘salt’ value provided by Holo’s semi-centralised infrastructure
Read more in this dense but interesting article about Holochain, Holo, and DPKI.
Now for the second half of your question: where is data stored?
It’s stored on the host — in alpha, this’ll be one host per Grandma; in beta it’ll be five hosts per Grandma. Public data doesn’t need to be encrypted (and can’t, because the peers in that app need it), but private data is tricky. The host technically doesn’t need to be able to read it; only Grandma needs to. So I think the Holo dev team is exploring at-rest encryption for private entries.
Each app stores its own private data on its own source chain per agent, whether Holo or Holochain. As for HoloVault (now called Personals & Profiles), it’s just another app with its own source chain — it’s just a handy way to store data.
I think capability tokens are a perfect way to access private data. Consider a medical records app:
Healthcare providers and patients both live in the same public DHT. Dr Alice wants Bob’s medical records from a previous doctor. Here’s how it could work:
- Dr Alice asks Bob for a certain set of medical records.
- Bob creates a capability grant for the specific records she wants, then stories it as a private entry on his source chain. He shares the hash of the grant entry with Dr Alice; this is her capability token.
- Dr Alice stores this token on her source chain as a capability claim. Whenever she needs to, she requests records from Bob and presents the token to him.
- Bob checks the token against the privileges he granted to her. If all checks out, he retrieves the records and sends them back to Dr Alice.
This happens through node-to-node messaging, which means that both Dr Alice and Bob need to be online. I suppose you could do it async via encrypted public entries too.