How to model: cannot see each other, one can see all

As part of our energy market solution, we have the need for each bidder in the market to not be able to see the other bidders’ data, but one node (“the Market”) to be able to see all other agents’ data. These are mostly private chains but somehow shared with the Market agent, so perhaps a series of two-node DHTs.

This seems inefficient and also not all that distributed. If an agent for some reason cannot see their local ledger (or cannot keep up), the bid is lost unless the write to the Market node is counted as redundancy, but this puts a burden on the Market node.

In the concept of membranes, is there a way for all participants to share a DHT without the ability to see the contents? I don’t believe so.

Interested in your thoughts.

I suppose the DNA validation rules could handle this: if agent_id of record is me, allow read access. This is rather simple and an attempt to read other records would be flagged as illegal.

Not strictly validation rules, which check on commit, but being built into the DNA still an inviolable rule.

Hi Mike,

Thank you for sharing this topic!
I think it would be relevant to other use cases as well.

Some recent hackalong discussions and reading is leading me to believe that the safest way, for now at least, is to enforce data privacy & access management through combination of source chain and capability token that grants specific agents certain access to data on private chains.

Some discussion/articles on capabilities:


So in this case, if only the authoring agents and the market agent should see the info, then the authoring agents would grant capability token to the market agent. There are some logistic details in the capability grant/claim flow that need to be looked at.

The market node would have to be scalable and be highly available, right? Maybe you need to create a separate DHT for market nodes (more than one?) ?

Maybe @pospi had encountered and looked at this for HoloREA use cases.

I think of the DNA rules as the rules that the app wants the network to validate before committing the entry, which in this case would probably be some criteria that have to be satisfied when an entry is put into the marketplace (some constraints on the bid or offer maybe?). I think that adding data access check into DNA rules might be putting multiple concerns in one place and is probably not optimal.

What’s the real-time requirement of this app?

Thanks, Mike.
Lily

Funny how the title describes a panopticon which is exactly the opposite of what we want to achieve with Holochain (holopticon). But I guess in some temporary and niche use cases it can still be useful.

I see several solutions depending on the validation rules you need.

  • If there is none, you could simple have the entry be encrypted with the Market’s node public key.
  • If you need some validation rules on the content, you could encrypt just the field in the entry that requires confidentiality.
  • If you need validation on the confidential data itself than it can’t sit in the DHT, only on private source chains. Unless maybe there is a way with homomorphic encryption that you are able to provide yourself.

Hey Damien, that observation didn’t escape us. But yeah, the real world intrudes. We have been looking at five options and encrypting part of the payload is one of them. Another is sending a Holochain message to the market to share our info from our private chain. The problem with this second approach is no resiliency. We are good for now but I do want to utilise the full power of a DHT. We can post our results in due course. Cheers