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.
