Let’s say I want to have agents, but then I want to have an agent registry where they can update their current IP address and other “app level” data. What would you assemble this architecture? Like let’s say there is a mainchain that is 6GB, and each node only needs a few MB of data that they control, how would you create this? I was just wondering if this would need to be a centralized backend, or could you have a more traditional blockchain that maintains app level data, and use holochain for the agent-centric architecture? It would be really nice if there was interoperability between these two layers as well.
Hello, and welcome to the weird world of Holochain development 
We’ve found that most things can be modelled without a ‘main chain’ of any sort. Even things that require a central registry can often be done without a main chain. The big question to ask is:
- Can each member safely update their data without causing conflicts with other members’ data?
If the answer is yes, then it’s really easy and no consensus is needed. If the answer is no, it’s a bit tricky but still possible to do without main chains. Global ledgers or main chains (e.g., blockchain) aren’t necessary for collecting data and making it accessible in a central place; they’re only for getting global agreement on what hasn’t happened — this is mostly related to enforcing uniqueness (you can’t double-spend a token, no two people can register the same domain name or hold title on the same piece of land, etc).
There are simpler solutions for making data discoverable. To use your example, of agents advertising their most recent IP address, there’s no need for global consensus on uniqueness of IP addresses. If two people claim the same IP, that probably just means they’re using the same computer. So they just commit the new record to their chain, publish it to the DHT, and make it easy for others to find it.
There are different ways to do this, but they all look pretty much the same. On the unstructured DHT, which is just a big pile of data, there’s a special type of metadata called a ‘link’. It’s attached to one piece of data and points to another. Here’s an article about it:
And some design patterns related to the idea:
Note that none of these patterns guarantee uniqueness; they just let people make claims. In the example in link #1, it would be perfectly okay for two people to register the username @alice_ukulele.
If you need uniqueness guarantees in your data, it would be easy to drop in an ‘authority’ node who holds a ‘main chain’ of unique tokens and transactions. And this piece of centralisation might be appropriate for certain use cases. But it’s also possible do it without centralisation. That is another story though… for another time 
Let me know if this is clear to you and if you want help understanding certain concepts. I kinda took you on a deep dive here 
1 Like
thanks for the thorough response, this was really helpful. I’ll take some time to dig into the design patterns you recommended, and follow up with any questions. Again, thanks for the thorough response!
1 Like
Hey I was revisiting this and wondered if you could elaborate on what you meant when you said “But it’s also possible do it without centralisation.”
yeah, you bet! I kind of don’t want to talk about it, because these theories of mine are thoroughly untested, but they should work.
So one of the big things Holochain is supposed to do behind the scenes is make sure nobody’s source chain is forked, kind of like what mining is supposed to do. It’s not fully implemented yet, but here’s my understanding of how it works:
- Every time a node publishes an entry, they:
- Publish the entry’s content on the DHT
- Publish the entry’s header as a separate record on the DHT
- Publish a piece of metadata on their own agent ID, pointing to the header entry. This says “This is my newest header.”
- The validators who hold copies of this node’s agent ID entry receive the metadata and add it to the entry. If there’s already a piece of metadata that clashes with it, the validator flags the conflict and shares it with their peers.
- You can fool some people some of the time, but not all people all of the time. Holochain depends on the statistical unlikeliness of all validators in the agent’s neighbourhood being in collusion with that agent. Even if they ‘mined’ their DHT addresses into one neighbourhood, some honest agent could join that neighbourhood and blow the whistle. You can read more about it here and here.
Okay, with the basics out of the way… how can you track the uniqueness of a resource (e.g., a currency token or property claim) without a central ledger? By tracing the the resource through all of its transactions all the way back to its creation, and trusting Holochain to prevent ‘double spends’ by detecting source chain forks.
So, what do I mean by tracing the resource all the way back to its creation? Well, in order for Alice to give Bob a resource (transfer property ownership, pay him with tokens) she has to prove that she owns it. These equirements must be met:
- She hasn’t given it to someone else already,
- She either:
- received it from Charlie, who proved that he owned it using these same requirements (you’ll notice that this is recursive), or
- legitimately created it herself (this is the endpoint of the recursive proof)
Each user has a chain of all the actions they’ve taken. It’s simple for Bob to scan Alice’s else’s chain to see if she’s already given away the resource that she’s currently trying to give him. And it’s also simple to see the point at which she either created it or received it from Charlie, at which point Bob picks up the trail on Charlie’s chain and repeats. Eventually Bob gets to the resource’s creation event, and checks it for legitimacy too.
This is computationally simple if it’s a linear ownership history, like title to a piece of land or registration of a human-readable name (although the generation event is still hard to decentralise, because someone still has to ensure unique first rights — this is not true with currency tokens, because one person’s random value is not likely to clash with someone else’s). But what about more complex histories, like coins that can be split and recombined? You’re looking at a really messy DAG that weaves its way through potentially millions of people’s chains. This isn’t practical when all you’re trying to do is pay for a coffee.
But Holochain offers a nice shortcut: when Bob wants to validate whether Alice owns the resource she’s trying to give him, all he needs to do is trust the validators that already checked the transaction where Charlie gave Alice the resource, assuming that other validators have done the same for the transaction where Diana gave Charlie the resource. Yes, it does involve trust, but depending on the size of the DHT, statistics are in your favour.