Holochains, by design, should be used in the context of a group operating by a shared set of agreements. Generally speaking, you don't need a holochain if you are just managing your own data.

These agreements are encoded in the validation rules which are checked before authoring to one's local chain, and are also checked by every DHT node asked to publish the new data.

These ensure Holochain participants operate according the same rules. Just like in blockchains, if you collude to break validation rules, you essentially have forked the chain. If you commit things to your chain, or try to publish things which don't comply with the validation rules, the rest of the network/DHT rejects it.

1. DNA / Holochain configuration

At this stage, a developer needs to set up the technical configuration of the agreements enforced by a Holochain. This includes such things as: the Holochain name, UUID, address & name spaces, data schemas, validation rules for chain entries and data propagation on the DHT.

2. Local Source Chains: Individuals Authoring Content

As an individual, you can join a Holochain by installing its Holochain configuration and configuring your ID, keys, chain, and DHT node in accord with the DNA specs.

Your chain is your signed, sequential record of the data you create to share on the Holochain. Depending on the Holochain's validation rules, this data may also be immutable and non-repudiable. Your local chain/data-store follows this pattern:

1. Validates your new data

2. Stores the data in a new chain entry

3. Signs it to your chain

4. Indexes the content

5. Shares it to the DHT

6. Responds to validation requests from DHT nodes

2. DHT Node: Sharing Information across the Network

For serving data shared across the network. When your node receives a request from another node to publish DHT data, it will first validate the signatures, chain links, and any other application specific data integrity in the entity's source chain who is publishing the data.