How it Works

Bob installs the core of application 1, called a DNA, into his Holochain runtime. The DNA contains functions for writing and accessing data, connecting with peers, and validating data.

On application startup, Holochain creates a source chain, a journal for all the data Bob's DNA will create. This journal is a ‘hash chain’, a cryptographically tamper-evident data structure. Each entry in the journal is signed by his private key.

At the beginning of the source chain is the fingerprint of the DNA; this shows that Bob’s computer has seen the rules and agrees to abide by them.

After the DNA fingerprint comes an optional membrane proof. For applications that restrict membership, this journal entry shows that Bob is allowed to join the network. It can be an invite code, proof of dues, or a vouch signed by an existing member — whatever the application needs to protect itself.

After the membrane proof comes Bob’s agent ID. This is the public complement of his private key, and it serves as both his unique identifier in the network and a means of verifying the signatures on his journal entries.

After writing these first three entries, Bob tries to join the application’s peer-to-peer network. He publishes his first three journal entries to the network’s distributed hash table (DHT); if his peers determine that they’re valid, they admit him into the network.

Bob’s peers in the network also have their own copy of the DNA with their own agent ID and source chain.

Bob starts using the application, writing application data to his source chain. Public data is shared to the DHT to be validated and stored, while private data stays on his device.

Bob and all his peers maintain their own DHT shard, containing copies of a small, random portion of all the public data that’s been published.

Bob’s DNAs can bridge to each other to share functionality and data. Each DNA has its own separate network, and access is controlled by a consent-based capability security system.