Holochain Glossary

As you go through our documentation, you’ll probably find some unfamiliar terms, or familiar ones used in surprising ways. Here are the definitions we use.

Action

A piece of data that represents a record on an agent’s source chain. Everything an agent does in a Holochain application is expressed as actions, stored on their source chain as records. When the source chain records a piece of data, it’s most accurate to say that it’s recording the agent’s act of creating it. Actions link to the hash of their previous action, which creates a tamper-evident journal or ledger of all their actions in an application.

Address

  1. DHT address, synonymous with base
  2. Transport address

Address space

The entire range of possible DHT addresses. This space is circular, meaning the last address is adjacent to the first address.

Agency

The power of an agent to act in their environment.

Agent

  1. Anyone or anything acting with agency, such as a human or bot.
  2. An agent (see definition 1) who participates in a Holochain network through their cell.

Agent activity

Records of all the source chain actions that an agent has published, along with any warrants against them for malicious activity.

Agent activity operation

A DHT operation produced by the author of a source chain record, notifying the validation authorities for the author’s agent ID entry that they’ve published something. The base of an agent activity operation is the agent ID of the operation’s author, which means that the author’s neighbors, as peers whose agent addresses are near to theirs, are the validation authorities for their agent activity data.

Agent-centric

Describes any distributed system that puts agents at the center of the design, giving them agency over their online identity and the data they create. Agent-centric systems are usually decentralized and use public-key cryptography to identify agents. Git, Holochain, Dat, and Secure Scuttlebutt are highly agent-centric, while client/server and blockchain systems are less so.

Agent address

The address of an agent ID entry on a Holochain DHT, calculated from the agent’s public key. It is used in locating an agent’s transport address for gossiping and making remote calls, and in calculating the proper validation authorities to send a DHT operation to or receive a piece of DHT data from.

Agent ID

The public key of an agent. It serves as their unique ID in a DHT.

Agent ID entry

The entry associated with the third of the four genesis records at the beginning of an agent’s source chain, which contains their agent ID. The address of this entry is also the agent’s address on the DHT.

Anchor

A Holochain application design pattern in which an easily discoverable base is designated as a location to store a large number of links. The base’s address is typically calculated from a short string, whose value is either hard-coded into the application’s code, discovered via link traversal, or entered via the UI. Entries and agent IDs can also serve as anchor bases.

Append-only

Any data structure that can only be written to. Once written, that data becomes ‘immutable’ (it can’t be modified or deleted). An agent’s source chain and the DHT are both append-only.

App entry

An entity that holds application data. On the DHT, an app entry is created for every new entry action, and validation authorities who hold the entry also hold the actions of all agents who have published that exact same entry as metadata, along with other metadata such as links. App entries are deduplicated but individual agents’ writes of those entries are distinguished by their respective actions attached to the entry.

Application (app)

When we’re talking about Holochain, ‘app’ is synonymous with hApp, a collection of back end and optionally front end components that comprise something a Holochain user can interact with.

Assigned capability grant

A capability grant that only allows specified agents to call a zome function in the grantor’s cell.

Atomic commit

The guarantee that all source chain commits performed in one zome function call will succeed or fail together, similar to a database transaction. Failure can be caused by validation failure for an individual record or a hardware I/O failure. It can also be caused by a prior atomic commit finishing and advancing the source chain state while the current function call is running, that is, between the time that the conductor created the current function’s workspace and the time that it attempted to persist its own changes to the source chain.

Author

  1. The agent who has written and signed a record to their source chain.
  2. The agent who has produced and signed a DHT operation as a consequence of definition 1.
  3. The agent who has produced and signed a validation receipt as a consequence of validation a DHT operation.
  4. The agent who has produced and signed a warrant as an attestation of disallowed activity.

Author grant

A capability grant that allows anyone possessing the source chain author’s private key to call any zome function in a cell. The only callers that should possess this key are the agent’s own clients and other bridged cells associated with the same agent ID in the same conductor.

Back end

When we’re talking about Holochain, synonymous with one or more DNAs for a hApp—that is, code that contains the base-level persistence and validation logic.

Base

The DHT address to which an operation applies. Validation authorities who claim responsibility for this address receive, validate, and apply operations that produce data and metadata attached to this base, which is then made available to agents who request it. This base consequently serves as a locator that allows an agent to know which authorities to request the data from, as each base maps to a DHT address, which is handled by a number of authorities who publish their coverage of the base via their storage arc, and whose agent addresses can be mapped to their transport addresses via a peer table lookup.

Blockchain

A distributed, partially decentralized system that promises Byzantine fault tolerance by using a global consensus protocol to get all nodes to agree on a single, shared history of events. This history is stored as a hash chain of ‘blocks’, or bundles of state transitions. A blockchain can be public (anyone can join) or permissioned/private (membership is controlled). Public blockchains are usually trustless, ensuring tamper-resistance by making cheating more costly than honesty.

Bootstrapping

The act of joining an application’s DHT. Bootstrapping typically involves:

  1. Finding an initial group of peers to gossip with via discovery,
  2. Establishing connections with those peers,
  3. Having one’s membrane proof accepted by those peers,
  4. Having one’s transprt address accepted into those peers’ peer tables, and
  5. Gradually having one’s transport address gossiped to other peers.

Bootstrap service

A service which keeps track of lists of transport addresses for peers, segregated by DNA hash. When an agent wants to bootstrap into an application’s DHT, they ask the bootstrapping service for a list of existing peers and make individual connections to them over the appropriate transport implementation.

Bridge call

A zome function call made between cells in one agent’s conductor, which allows the agent’s cells to access each other’s public APIs.

Bundling

The act of packaging:

  1. one or more zomes into a DNA bundle,
  2. one or more DNA bundles into a hApp bundle, or
  3. a hApp bundle and a UI into a web hApp.

Byzantine fault tolerance (BFT)

The ability of a distributed system to reach consistency despite ‘Byzantine failures’, which are data corruptions caused by accidental or intentional faults in nodes or the networking transport medium between them.

Callback

A zome function with a reserved name, only callable by the conductor during a lifecycle event. The callbacks are as follows:

Capability

A privilege granted by a capability grant to call certain zome functions. The grantor can revoke this capability by deleting the original grant from their source chain.

Capability-based security

A security model that allows the owner of a resource to grant others access while maintaining ultimate control. Instead of allowing direct access to the resource, it mediates access and manages privileges by issuing capability claims, or tokens representing access to the resource. In Holochain, an agent’s conductor protects their running cells and authorizes callers’ access to them by issuing and checking the secrets and credentials they supply against existing grants.

Capability claim

A private system entry that a subject writes to their source chain to record the secret they received for a transferrable or assigned capability grant. This allows them to later call the zome functions to which access has been granted.

Capability grant

A private system entry that an agent writes to their source chain to record the granting of a capability and its conditions for access, including the secret (if the grant is transferrable or assigned) and the assignees (if the grant is assigned). If the access being granted is unrestricted, no secret or assignees are specified.

Capability grantor

The agent who creates a capability grant.

Capability secret

A secret series of bytes for a capability grant, created by the grantor, which proves that its bearer has been granted a capability and is allowed to exercise it.

Capability subject

The entity that is given permission to access a resource via capability-based security. In Holochain, this can be a client or bridged cell on the user’s machine, or it can be another agent making a remote call.

Cell

A particular Holochain DNA when it’s bound to an agent ID and running in the conductor. DNA + agent ID = cell.

Centralization

The degree to which computing power, agency, decision-making power, or responsibility in a distributed system is concentrated in certain nodes. Client/server systems, while technically distributed, are highly centralized, both in computer power and agency, while cloud systems have decentralized computing power and centralized agency and peer-to-peer systems have both decentralized computing power and agency. The complement of centralization is, of course, decentralization.

Client

In Holochain terms, any piece of external software that accesses a DNA’s zome functions. The client makes function calls over the conductor’s RPC interface, and can be a GUI, shell script, service, or scheduled task. This client needs to be granted a capability to make these calls, because the RPC interface represents the user’s agency in the application, and access to it should be restricted. For this reason, a client also usually lives on the same machine as the conductor.

Client/server

A highly centralized distributed system architecture in which certain privileged nodes are responsible for most of the processing, storage, and decision-making. Client/server systems typically give low agency to end-users, due to the fact that the privileged nodes mediate most user interactions.

Cloning

The act of creating a copy of an existing cell by duplicating it and changing one or more DNA modifiers in order to obtain a distinct DNA hash and optionally its behavior via DNA properties, thus creating an isolated network and DHT for the resulting clone cell. This allows all agents who have created clone cells with the same modifications to enjoy a private shared space using existing rules without creating a DNA from scratch. An example is a message application with channels, where a clone cell represents a channel.

Cloud

A specific client/server configuration in which computing power is decentralized among many servers, but agency is still centralized in those servers.

Commit

The act of adding a record to a source chain.

Commons

Any resource that is used and managed by a group of agents, but is owned by none. In order to be healthy, a commons must have rules governing its use. A Holochain DHT is a type of digital commons whose rules are enforced by its DNA and Holochain’s subconscious rules.

Conductor

The service that lives on an agent’s device and hosts all of their cells, stores their data, makes their zome functions available to local clients via an RPC interface, and handles network communication between their cells and other agents’ cells.

Conductor admin API

The RPC interface that a conductor exposes, which allows clients to:

This API is typically only accessed by application management software such as the Launcher.

Conductor app API

The RPC interface that a conductor exposes, which allows clients to:

Conflict-free replicated data type (CRDT)

A function that allows two nodes in a distributed system to separately make changes to the same piece of data without creating conflicts. A CRDT is logically monotonic, which means it satisfies the CALM theorem and doesn’t need a coordination protocol to arrive at consistency. Holochain makes sparing use of CRDTs when retrieving entries and links, and we also recommend considering using CRDTs in app design to handle the merging of different agents’ data.

Consensus

  1. Synonymous with consistency in a distributed system.
  2. Synonymous with global consensus in a blockchain or other DLT.

Consistency

The point at which all nodes in a distributed system agree on the state of the data they hold. Blockchains enforce a form of consistency called global consensus, whereas Holochain uses ‘strong’ eventual consistency.

Consistency/availability/partition-tolerance (CAP) theorem

A principle that states that all distributed systems are prone to partition, and that in the presence of a partition, a design can only guarantee availability (data can always be accessed and written) or consistency (data is always correct), but not both.

Consistency as logical monotonicity (CALM) theorem

A principle that states that as long as a function is logically monotonic, it can be run on multiple nodes in a distributed system and reach strong eventual consistency without needing coordination protocols. Holochain’s DHT is CALM, in that every DHT operation is simply accumulated without attempts to reconcile it with other operations. State is then determined by processing the final state of the accumulated operations when data of a certain type is requested.

Content-addressable storage (CAS)

Any storage system that gives a unique ID to each piece of data and allows it to be retrieved by its ID rather than its physical location. A DHT is a type of CAS using hashes as IDs.

Coordination protocol

An algorithm that governs the synchronization of data in a distributed system and aims to prevent or resolve data conflicts that happen when two nodes are out of sync with each other. Any state transition that isn’t logically monotonic needs a coordination protocol. In Holochain, countersigning is a simple coordination protocol between two or more agents who want to reach agreement with each other.

Coordinator zome

A zome that defines zome functions. Arbitrary public zome functions give a DNA DNA its API which mediates interactions between clients and a cell instantiated from the DNA, while arbitrary private zome functions can be scheduled, and special private zome functions with reserved names are called by the conductor as a consequence of lifecycle events such as cell initialization and source chain commits. Zome functions in a coordinator zome have access to most of the host API, including the ability to:

As they are not considered DNA modifiers, a DNA’s coordinator zomes can be added and removed without affecting the DNA hash.

Counterparty

An agent involved in a countersigning session.

Countersigning

A simple coordination protocol between two or more agents in a Holochain DHT in which they agree to lock their respective source chain states, reach consistency on the contents of each other’s source chain, and sign one single shared entry which they then commit to their source chains. An enzyme and optional M-of-N signers can also be involved in the transaction for further corroboration, enabling lightweight consensus among multiple parties.

Create-entry action

A new-entry action that causes an entry to be made available to other DHT members (unless the entry is private, in which case only a record of its creation is published).

An action that causes a link from one piece of record data to another to be available to other DHT members.

Create, read, update, delete (CRUD)

The four main actions an application needs to do with data. Even though all data structures in Holochain are append-only, modification and deletion of data can still be simulated by publishing a new action that marks the old data as modified in a CALM way. New-entry actions create and/or update entries, while delete-entry actions remove them. Links can also be created and deleted in a similar way.

CRUD action

A record that expresses a CRUD operation on a piece of data or metadata. Create-entry, update-entry, delete-entry, create-link, and delete-link actions are all CRUD actions.

Dead data

As no data in a Holochain DHT or agent’s source chain are ever deleted, existing data must be marked as no longer active. Dead data takes four forms:

  1. A new-entry action action that has been marked as deleted by a delete-entry action.
  2. A create-link action action that has been marked as deleted by a delete-link action.
  3. An entry whose new-entry action actions have all been marked as deleted.
  4. A link whose create-link action actions have all been marked as deleted.

Decentralization

The act of removing central points of control. Many distributed systems are decentralized to various degrees. The inverse of decentralization is centralization.

Deduplication

The removal of identical entries in a CAS. Most CASes, including Holochain’s DHT, deduplicate content automatically. Holochain’s DHT does, however, disambiguate between individual writes of an entry by storing the authors’ actions alongside it as metadata.

DeepKey

(Future) Holochain’s default implementation of a DPKI.

Delete-entry action

An action that causes a new-entry action to be marked as dead. If all such actions that caused an entry to be published are marked as dead, the entry itself will also be marked as dead.

An action that causes a create-link action to be marked as dead. Links with identical base, target, type, and tag are not deduplicated, so deleting a create-link action also deletes the link. However, other create-link actions may contain the same data, so they will still remain.

DevHub

A hApp that acts as a package manager for other hApps. It is installed by default in the Launcher and is also integrated into the Launcher’s app store.

DHT address

The unique ID of a piece of record data (entry, action, or agent) on the DHT. Every piece of data has an address that is generated directly from its content, usually by a hash function. This makes the DHT a content-addressable storage system.

DHT data

A piece of data that lives in the DHT. DHT data is assigned to a neighborhood of validation authorities based on the base address of the DHT operation that expresses its creation, and is deduplicated. All DHT data is either record data with an address of its own, or metadata attached to a piece of record data. DHT data is created when agents author source chain actions, which then produce operations that are sent to the respective validation authorities for the operations’ bases. Those authorities then apply the operations to their own DHT shard after validating them.

DHT operation

A unit of gossip that communicates a request to a validation authority to transform the data they hold in some way. Each DHT operation has a base address and gets sent to the authorities that claim responsibility for that address by advertising that their storage arcs include the address. For each type of record/action, an author produces one or more DHT operations. For example, a create-entry action for a public entry produces three DHT operations:

Distributed hash table (DHT)

A collection of data stored collectively by many nodes in a peer-to-peer network. In a DHT, a node retrieves data by address, usually its cryptographic hash, by searching for a peer who holds the data. Holochain uses a validating DHT to store DHT data and chooses agents to hold data based on the nearness of their agent address to the data’s address. Agents can claim authority over an arbitrary range of the DHT’s address space by publishing their storage arc. Each DNA has its own separate DHT.

Distributed ledger technology (DLT)

Any technology that involves many nodes in a distributed system sharing an append-only history of state transitions. Blockchain DLTs use a global ledger, whereas others use some form of sharded or separate, interoperating ledgers. Holochain is a type of DLT in which each agent is responsible for their own ledger, called a source chain.

Distributed public key infrastructure (DPKI)

A public key infrastructure that doesn’t rely on a central authority. DeepKey is Holochain’s default DPKI implementation.

Distributed system

Any system that involves multiple nodes talking to one another over a network, whether decentralized or centralized. Because communication isn’t instantaneous, different nodes can create conflicting data, particularly in the persence of a partition. Many distributed systems use a coordination protocol to reach consistency, while others rely on the CALM theorem to avoid conflicts altogether.

DNA

A package of executable code that defines the shared ‘rules of the game’ for a group of agents. A DNA is made up of zomes, which define validation rules for data, as well as zome functions that allow agents to write to their source chain, retrieve data from the DHT, send signals to a listening client, or make remote calls to another cell. Each DNA has its own isolated network and DHT shared by all cells using the DNA.

DNA bundle

The file that holds a complete DNA, both executable zomes and metadata (see DNA manifest for details on this metadata).

DNA hash

The cryptographic hash of all of the properties of a DNA considered to be DNA modifiers. The DNA hash serves as the unique ID for a DNA’s network.

DNA instance

See cell.

DNA manifest

A file that specifies the components of a DNA, including locations of compiled zomes and metadata such as a name, description, network seed, properties, origin time, and quantum time. This manifest can be used by the hc tool to build a DNA bundle.

DNA modifiers

All properties of a DNA which affect its hash — that is, its integrity zomes, properties, network seed, origin time, and quantum time.

DNA properties

Arbitrary data that affects the operation of the DNA. A user can specify properties at DNA installation time, which causes the DNA to be cloned if the user-specified properties are different from the default properties. The executable code can then access those properties to change its behavior, similar to configuration files or environment variables. This is a simple way of allowing separate networks of users to enjoy isolated and slightly modified experiences using a set of base rules. The DNA properties are considered DNA modifiers.

End-to-end encryption (E2EE)

A channel between two nodes in a public network that allows them to transfer secret messages that cannot be decrypted by eavesdroppers. Holochain’s node-to-node network communications, including gossip, publishing, and remote calls, use E2EE (currently QUIC with TLS encryption).

Entry

A basic unit of application data in a Holochain app. Each entry has its own defined type. When an agent commits an entry, it is included in an action into a record that expresses a new-entry action. This data is written to their source chain as a record of the action having taken place. An entry can be public or private; if it’s public, it’s also published to the DHT. There are app entries whose purpose and structure are defined by the DNA developer, and there are special public or private system entries such as an agent ID entry and capability grants and claims.

Entry type

A specification for any sort of entry that a DNA should recognize and understand, similar to an OOP class or database table schema. An entry type definition can specify whether entries of its type should be public or private, and how many required validations should exist. DNA developers create their own entry types for the data their app needs to store, and can write validation functions for operations that create, update, or delete entries of those types.

Entry types callback

A private zome function in an integrity zome that yields all the entry types defined in the zome’s schema. This callback is called by the conductor at DNA installation time, so the conductor can know which entry-producing operations should be routed to which integrity zome.

Enzyme

An agent involved in a countersigning session who has been nominated to witness the session – that is, to collect, sign, and redistribute full sets of signatures from all counterparties, including themselves. An enzyme can also be one of a set of optional M-of-N signers in the session.

Ephemeral schedule

A schedule on which a scheduler function is directed to run. A scheduler function called on an ephemeral schedule only runs once after a defined delay, and unlike a recurring schedule does not survive through stops and starts of a cell.

Eventual consistency

A promise made by distributed systems that optimize for availability over consistency (see CAP theorem), meaning that given enough time, every node ought to eventually reach consistency with each other. Strong eventual consistency means that nodes will eventually reach consistency without conflicts, which is possible for any system whose state transition functions adhere to the CALM theorem.

Fork (DNA)

To change a DNA in a way that doesn’t necessarily alter its behavior, resulting in a new hash for the DNA that gives it a separate network and DHT from the one associated with the original DNA. Forking is most easily done by passing a network seed at DNA installation time.

Fork (source chain)

To create alternate versions of one’s history in an app by basing two source chain records on one parent record. Forking one’s source chain is always an invalid action, detected at the subconscious level by agent activity authorities.

Front end

In Holochain terms, synonymous with graphical user interface or, more generally, client.

Genesis records

The four records at the beginning of an agent’s source chain, consisting of:

  1. The DNA hash, which shows that the agent has seen the network’s rules and agrees to abide by them,
  2. The membrane proof, which the agent presents as a claim that they should be allowed to join the DHT,
  3. The agent ID, which advertises the agent’s public key,
  4. The init complete action, which tells the conductor that all the DNA’s init callbacks have completed successfully and the source chain is ready to have app entries written to it.

Global consensus

Agreement among all nodes in a blockchain on the state of a single, shared global ledger. Holochain prefers ‘local’ consensus, both between interacting parties using countersigning and among a small set of third-party validation authorities.

Global ledger

A ledger whose contents are identical across all nodes in a blockchain. The state of a global ledger is arrived at through a global consensus procedure.

Gossip

A protocol used by many peer-to-peer networks to rapidly propagate data. Each node knows a few other nodes, who know a few more, and so forth. Whenever any node receives a message, they broadcast it to some or all of their peers. Data propagates slowly at first, then spreads at an exponential rate. Nodes in a Holochain network share DHT operations, neighborhood health information, and peer transport addresses via gossip.

Graphical user interface (GUI)

In Holochain terms, a client that presents a visual way for a user to interact with a hApp running in their conductor. As with any client of a Holochain application, the GUI must possess a capability allowing them to call the hApp’s public zome functions.

hApp bundle

One or more DNAs, which together form the back end for a complete hApp. These components are specified in a hApp manifest file, and can be packaged together in a zip archive along with the manifest or downloaded separately from the internet. A hApp can also be bundled with a web-based GUI to become a web hApp.

hApp manifest

A file that specifies the DNAs comprising a hApp bundle.

Hash

A unique ‘fingerprint’ for a piece of data, calculated by running the data through a cryptographic hashing function. A hash can serve as a unique identifier for that data (such as with addresses of DHT data) and makes it easy to verify the integrity of the data after it’s been retrieved. In a Holochain DHT, the hash of an entry also serves as its base, allowing an agent to calculate which authorities to request the entry from.

Hash chain

An append-only data structure that can be used as a tamper-evident, sequential log of events, such as a source chain or blockchain.

hc

A command-line tool for scaffolding, bundling, testing, and running hApps.

History

The sequence of actions taken by an agent, stored as records in their source chain.

Holo

The company funding the development of Holochain and facilitating hosting services for Holochain apps.

Holochain Development Kit (HDK)

Holochain’s standard Rust-based software development kit (SDK) for DNA developers. It provides developer-friendly access to the Holochain host API, as well as macros for defining entry and link types, validation functions, init callbacks, and other zome functions.

Holochain application (hApp)

A collection of DNAs in a hApp bundle and optionally a client or clients that allow users to interact with those DNAs.

Holochain Core

The basic components of Holochain — the conductor, the ribosome, and the storage and networking layers.

Holochain host API

The set of core functions that the Holochain conductor makes available via the ribosome to a running cell. These functions allow the cell to access and manipulate an agent’s source chain, run cryptographic functions, retrieve and publish DHT data, send signals to clients, bridge to the agent’s other cells, and make remote calls to their peers.

Holo Host

A platform and marketplace where Holochain users offer their spare computing capacity to host cells for web users, functioning as a bridge between Holochain and the traditional web. Read more at Holo’s website.

Host API

See Holochain host API.

Immune system

A property of Holochain’s validating DHT, whereby healthy nodes detect invalid data, share proof of corruption among their peers via warrants, and take defensive action against the corrupt nodes that authored the data by blocking network communication with them. While each agent is individually free to interact with a warranted peer, most agents will refuse to interact or gossip with them. The cumulative effect is a collective exclusion of the corrupt nodes (see mutual sovereignty).

Init callback

A function in a DNA that the conductor executes when an agent calls a cell for the first time, and after they have joined the DNA’s network. This can be used to set up initial source chain #state, etc.

Init complete action

An action that Holochain automatically writes to an agent’s source chain to indicate that the init callbacks in all of a DNA’s zomes have successfully run.

Integrity zome

A zome that defines a data schema. It does this through three specially named zome functions:

All integrity zomes are considered DNA modifiers, as they define the DNA’s core set of shared agreements about the nature of data that can be validly produced by any agent in the network. Although an integrity zome cannot produce data, coordinator zomes within the same DNA can produce data whose entry type is defined in one of the DNA’s integrity zomes.

Intrinsic data integrity

Holochain’s foundational strategy for guaranteeing data integrity. Data is considered valid or invalid based on the DNA’s validation rules, as well as Holochain’s subconscious validation rules.

Journal

Synonymous with ledger.

Launcher

A desktop application that allows a person to search for, install, and run hApps. The Launcher can be downloaded from its GitHub repository.

Ledger

A history of events or state transitions. In distributed ledger technology, ledgers are usually stored as hash chains, such as a Holochain agent’s source chain.

Lightweight consensus

An informal term for a Holochain application pattern in which the ownership of scarce resources are tracked and protected from conflicting ownership claims by establishing a set of trusted nodes as M-of-N signers, a majority of whom must witness every countersigned transaction involving the resources in order for ownership to be considered valid.

A piece of metadata connecting one address to another. Each link has a type, can have a tag for storing arbitrary content, and is stored in the DHT at its base’s address. Neither the base nor the target are required to have any record data stored at them.

The address that a link links from. The base usually points to the address of a piece of record data on the same DHT, but can also point to an external hash-based address on another DHT or non-Holochain-based data store, in which case it’s informally called a ‘baseless’ link (although technically there is a base; it simply contains no record data). The anchor pattern is a common use for baseless links.

An arbitrary piece of data, stored with a link, that contains arbitrary application-defined information. Among other uses, a link tag can be used in a query filter or store information about the link target to avoid a second DHT query to retrieve the target’s content.

The address that a link points to. As with the base, a target can point to the address of a piece of record data on the same DHT, but can also point to something external or left unspecified. The target addresses of links within the same DHT do not automatically have any metadata pointing back to the base, and therefore by default have no knowledge that they’re being pointed to.

A specification for a link defined in an integrity zome that a DNA should recognise and understand, similar to a foreign reference in a database table schema. DNA developers create their own link types for the data their app needs to store, and can write validation functions for operations that create, update, or delete links of those types.

A private zome function in an integrity zome that yields all the link types defined in the zome’s schema. This callback is called by the conductor at DNA installation time.

Live data

DHT data or source chain data that meets two criteria:

Lobby

A Holochain application design pattern, in which one DHT is established as a common space which agents can join and either request access to a privileged DHT or ask privileged agents to mediate access to that DHT using remote calls.

Logical monotonicity

The property of a set of facts whereby the truth of prior facts are never negated by the addition of later facts. CALM relies on functions that exhibit this property. For example, Holochain’s source chain and DHT only add new data without removing old data, simulating deletions and modifications (CRUD) by recording actions which override the status of, but don’t remove, the data they refer to.

Membrane

One of two types of permeable boundaries that allow or disallow access:

  1. The layer of protection around an agent’s cell, secured by capability-based security, that prevents unauthorized access to the cell’s zome functions, source chain data, or view of the DHT.

  2. A special validation function in a DNA that checks an agent’s membrane proof and determines their right to become part of the DNA’s network. If a membrane proof is invalid, existing peers in the network will refuse to talk to the agent attempting to join.

Membrane proof

A record written to an agent’s source chain that proves they have permission to join a DHT, for example, an invite code or signed authorization from an existing member. The DNA for the DHT has a validation function that checks the validity of the membrane proof; if agents validating the membrane proof determine that it’s invalid, they can refuse to communicate with the new agent. This is the immune system’s first line of defense against malicious actors.

Metadata

Supplementary data attached to a base in a DHT. Metadata can be one of:

Unlike with record data, a base can have many pieces of each kind of metadata attached to it.

Microservice

An application architecture pattern that encourages small, single-purpose back end services. Holochain DNAs can be seen as microservices that combine to form a fully featured hApp.

M-of-N signing

An extension to countersigning, in which a number of optional witnesses are also involved as counterparties signing the session, a majority of which must sign in order for the session to complete. One optional witness must also be nominated as the session’s enzyme.

Mutual sovereignty

The relationship between the autonomy of the individual and the collective intentions of the group. A successful commons finds a healthy tension between these opposites. Holochain’s design is based on this principle, empowering participants to control their own identity and responses to their peers by equipping each of them with a full copy of the application’s code. This code constitutes a formal, executable definition of the group’s rules and norms, as DNA modules, so by running the application a participant consents to become a member of the group and be bound by those rules and norms.

Nearness

The mathematical distance between two addresses to each other in the DHT’s address space.

Neighbor

See neighborhood.

Neighborhood

A range of DHT addresses about which a node attempts to know everything they ought to know. Neighbors collectively support the resilience of all DHT data whose address is within their respective storage arcs by storing and validating it and gossiping it to all neighbors with whom their storage arcs overlap.

Network

In Holochain terms, a collection of nodes gossiping with each other to form a validating DHT, aiding in data storage and retrieval, validation, and peer discovery. Each DNA has a separate network.

Network seed

An optional string, specified in a DNA bundle file or passed at cell cloning time, that modifies the DNA’s hash without modifying any of its behavior. This can be used to create a unique network shared by all agents who use the same network seed. Hence, a network seed is considered a DNA modifier.

New-entry action

Any action that produces a new entry, either a create-entry or update-entry action. If the entry’s type is public, the entry will be published to the DHT along with its action. If the entry’s type is private, only the action is published.

Node

An individual agent in a Holochain network who has an agent address and can be talked to via gossip.

Open/close chain actions

System actions that track the continuity of an agent’s participation across multiple source chains. A close chain action marks a source chain as closed and points to a new source chain (either in the same or another DHT) that continues the agent’s activity, while an open chain action marks a source chain as a continuation of a prior source chain.

Origin time

A timestamp deemed to be the ‘birthdate’ of a DNA. It defines the earliest valid timestamp for any data on any source chain of any cell in the DNA’s network, and helps make gossip more efficient. Origin time is considered a DNA modifier.

Participant

Synonymous with ‘user’. We often prefer the term ‘participant’ because a Holochain DHT is a commons of mutually sovereign peers who all actively work to maintain its integrity, rather than people who merely ‘use’ an application.

Partition

A situation in which some nodes in a distributed system are temporarily or permanently unable to communicate with each other.

Path

A specific application of the anchor pattern in which anchors, in addition to serving as the bases for large numbers of links, also point to other anchors in a hierarchical structure.

Peer

Synonymous with node or agent in a peer-to-peer network; the plural term ‘peers’ describes agents who belong to the same network.

Peer discovery

The act of finding the transport addresses of peers to communicate with. Initial discovery is done as a part of bootstrapping, and ongoing peer discovery is handled by DHT lookups and gossip. The currently supported peer discovery methods are:

Peer table

A mapping of agent addresses to transport addresses which an agent maintains in order to participate in a Holochain network. This peer table is populated via various peer discovery methods. It will typically contain a high concentration of entries contained in the agent’s own storage arc, as well as a small number of entries for peers in other parts of the network’s address space. Each DNA which an agent is running will be part of its own network, which means that it will also have its own peer table.

Peer-to-peer

Describes any highly decentralized distributed system in which nodes talk directly to one another without the intermediation of a server or other type of central node.

Playground

A community-contributed UI that visualizes the state of the cells in a hApp’s network that are running in a local conductor. It can be used to help a developer understand the working of Holochain’s subconscious and foundational data structures, as well as troubleshoot a hApp. The Playground is included by default in every hApp scaffolded by Holochain’s official scaffolding tool. See Playground’s GitHub organization.

Post-commit callback

A private callback defined in a coordinator zome that receives every record committed by that zome after another zome function has successfully committed them. A post-commit callback is a normal zome function in every respect, except that it can’t make commits of its own.

Private entry

An entry which is stored on an agent’s source chain, but not published to the DHT.

Proxy relay

A special software service that helps two Holochain nodes behind restrictive firewalls or NATs communicate with each other by mediating network traffic between them.

Public entry

An entry whose type is marked ‘public’ and is published to the DHT.

Public-key cryptography

A cryptographic system that consists of two keys, a public component and a private component. These keys are mathematically related to each other in a way that’s easy for the key pair’s owner to prove, but nearly impossible for a third-party to reverse-engineer. In Holochain, an agent’s public key lives in the DHT and serves as their ID while the private key stays on the agent’s device. Peers can verify an agent’s claim of authorship on published DHT data by checking their signature, and can use an agent’s public key to encrypt a private message that only the holder of the corresponding private key can decrypt.

Public-key infrastructure (PKI)

A way for agents to share their public keys, prove their authenticity, and revoke old keys if they’ve been compromised. Most PKIs, such as the global TLS certificate authority system, are centralized. Holochain will provide a distributed PKI system.

Public-key signature

The hash of a piece of data, encrypted with a private key. It can be decrypted by anyone who has a copy of the public key, which allows them to verify authorship of the signed data. In Holochain, the author of any record data that gets published to the DHT attaches their signature to each of the DHT operations they produce, to prove authorship and allow third-party tampering to be detected.

Public/private key pair

See public-key cryptography.

Publish

To convert a record into one or more DHT operations and send them to the respective validation authorities for validation, transformation into record data, and storage. This happens after it has passed the author’s own copy of the validation rules. The validation authorities who are responsible for that entry’s address receive it, validate it, and if it’s valid, store a copy of it and pass a validation receipt back to the author.

Quantized gossip

In Holochain’s DHT, the practice of synchronizing data held by two validation authorities by first agreeing on a two-dimensional window to compare lists of respectively held DHT operations. This window is fitted to one or more cells in a grid, in which the horizontal axis is the DHT’s address space and the vertical axis is the time since the DNA’s origin time, quantized by the quantum time. As every DHT operation has both an address and a timestamp, it can be located on the grid. This technique is used to increase speed and reduce payload size of gossip rounds.

Quantum time

A value specified in the DNA manifest that defines the smallest time window for which two peers will compare a subset of the data they’re each holding during a round of DHT synchronization. The quantum time is a DNA modifier, and with the origin time affects the way in which peers gossip. All peers in a network must agree on the quantized gossip parameters they use in order to gossip DHT data successfully with one another.

Record

The data structure that holds an action in an agent’s source chain. Some records are a combination of action and entry, such as new-entry actions, while others contain all their data inside the action.

Record data

Any piece of addressable data that can (though doesn’t need to) be published to the DHT. Record data consists of anything contained in a record — that is, an action or an entry, which are stored by separate validation authorities on the DHT. Each base in a DHT may only have one piece of record data associated with it. This is in contrast to metadata, of which there can be many attached to a base.

Recurring schedule

A schedule on which a scheduler function is directed to run. A recurring schedule specifies a time interval, similar to a UNIX cronjob or Windows scheduled task. Unlike an ephemeral schedule, functions running on a recurring schedule survive through cell stops and starts.

Remote call

A remote procedure call that one agent’s cell makes to the zome functions of another agent’s cell within a network. The callee controls remote access to their zome functions via capability-based security.

Remote procedure call (RPC)

  1. A call that a client makes to a zome function or conductor admin API function. The caller and callee are typically under the control of one agent and typically reside on one device.
  2. A remote call between agents in a network.

RPC interface

A network port that the conductor exposes, allowing clients to call the conductor admin API or conductor app API via WebSocket. By default, this interface only listens for local connections, so it can’t be accessed over the internet.

Required validations

The number of validation receipts that an instance of a given entry type must have in order to be considered accepted by the validation authorities and be ‘live’ on the DHT. On initial publish, the author of a record collects these receipts; thereafter, validation authorities gossip these receipts to each other. If the author can’t collect the required number of receipts, it will try to republish to more authorities later.

Resilience

The measure of a network’s capacity to hold itself in integrity as nodes leave, join, or attempt to attack it. In a Holochain DHT, neighbors attempt to collaboratively adjust their storage arcs to ensure that every piece of data is covered by enough validation authorities to make it always available.

Ribosome

The ‘sandbox’ or ‘virtual machine’ inside which a cell runs. In Holochain’s current design, the ribosome is a WebAssembly runtime that exposes Holochain’s host API to the cell and allows the conductor to call the cell’s exposed zome functions.

Rust

The programming language currently used to build Holochain Core and DNAs/zomes. See Rust website.

Saturation

The state at which there are enough peers holding a piece of DHT data to make sure it’s reliably available to anyone who asks for it (see resilience).

Scaffolding

The act of generating application code from generic templates and app-specific specifications using a tool built for the purpose. Holochain’s scaffolding tool can generate zome, test, and UI code.

Scenario test

An automated test that simulates real-life conditions involving multiple cells in a network, used to test a DNA’s functionality and tolerance of various failure modes. Tryorama is used to write scenario tests in JavaScript.

Scheduler function

A private zome function (that is, a function which is not exposed as part of a cell’s public API) which another zome function can direct to be called on an ephemeral or recurring schedule. A scheduler function only receives a schedule and can only return a schedule (either a new one or the same one); any state information must be retrieved from the source chain of the agent on which the cell is running, or from the DHT which the cell is a part of.

Scheduling

The act of directing a scheduler function to be called later, either ephemerally or on a recurring schedule.

Sharding

A process of reducing the processing and storage load of individual nodes in a distributed system by distributing data and/or work among them. While some sharded systems such as Ethereum 2 separate nodes into discrete shards, Holochain’s DHT separates them into neighborhoods of overlapping storage arcs. Each node in a DHT takes responsibility to store a shard of the total public data in the DHT, according to the chosen size of their own storage arc.

Signal

  1. A message emitted by a cell, meant for a client to receive and act upon.
  2. A message sent by one cell to another in the same network.

Source chain

A hash chain of records committed by an agent. Every agent has a separate source chain for each of the cells they’re running, which stores all of the actions or state transitions the cell has made.

State transition

A modification of application state. In Holochain, all state transitions are initially created as records in an agent’s source chain that represent the actions of creating, updating, and deleting data and metadata, as well as of system-level actions such as capability grants. A state transition further yields one or more operations that are then published to the DHT, that is, they are sent to the appropriate validation authorities, who then apply those operations to their own DHT shard, which causes a state transition for the base to which the operation applies.

Subconscious

The ‘base’ validation rules defined by Holochain that check validity of DHT operations and the integrity of each agent’s source chain.

Storage arc

A range of DHT addresses for which an agent claims authority — that is, responsibility to validate, store, gossip, and serve all DHT data whose addresses fall within the arc.

System action

Any action meant for Holochain’s internal use. A system action can be one of:

System entry

Any type of entry meant for Holochain’s internal use. System entries can be created, updated, and deleted just like app entries. The system entry types currently defined are:

Transferrable capability grant

A capability grant that allows any caller who can produce the right secret to call a zome function in the grantor’s cell.

Transport address

The underlying network address of an agent in a network, such as its IP address. This is different from its agent address, which is a DHT address, although every agent address maps to a transport address, published by the agent themselves and held by the agent ID entry’s validation authorities.

Transport implementation

A networking layer that allows peers in the same network to gossip with each other and make remote calls. Currently Holochain only supports two transport implementations:

Trustless

Describes a peer-to-peer distributed system that is Byzantine fault tolerant even when nodes are anonymous and membership is unrestricted. Trust is placed in the algorithm, rather than the reputation of the actors.

Tryorama

A scenario testing library for Holochain. See Tryorama GitHub repo.

Unrestricted capability grant

A capability grant that allows any peer or client to call a zome function in the grantor’s cell.

Update-entry action

A new-entry action that replaces another new-entry action, essentially allowing the simulated modification of already-written data in a way that allows for multiple branching revision chains. This can be used to modify public or private, system or app entries.

Validating DHT

Holochain’s DHT design which creates an immune system for the network. An agent chooses validation authorities at random to publish or retrieve DHT data, based on peers’ nearness to the address of the data being validated and the storage arcs they claim authority for. If an entry fails validation, the validation authority publishes a warrant against the entry’s author.

Validation authority

An agent on an application’s validating DHT, chosen at random to validate a DHT operation, based on their agent address’ nearness to the base address of the operation and their published storage arc. After validating, they also store the entry and help maintain its resilience by gossiping it with their neighbors and cooperating to adjust their storage arcs to ensure reliable availability.

Validation receipt

A signed piece of data sent by a validation authority to the author of an operation indicating whether it was deemed valid or not.

Validation rule

Any executable code that checks data for validity. Validation rules can either be subconscious or written in a zome as a validation function.

Validation function

A function in an application’s DNA that contains the validation rules for a DHT operation. This function allows every agent to check the correctness of data they see. If a validation authority is performing validation on an operation and finds that it’s invalid, they can generate and share a warrant proving that the record’s author has broken the ‘rules of the game’.

A validation function has only limited access to the host API, restricted to deterministic retrieval of DHT data and selected cryptographic functions.

Validation receipt

A signed piece of data created by the validation-authority for a DHT operation, attesting to its validity according to the validation rules in the app.

Validator

See validation authority.

Warrant

(Future) A signed piece of data that attests that either:

  1. a DHT operation is invalid and its author has transgressed a validation rule,
  2. a warrant is invalid, or
  3. an agent should not be communicated with for reasons not easily expressable as a validation function, such as termination of employment or copyright .

A warrant can be used by any peer as legitimate grounds for blocking communication with the agent being warranted, as well as for deleting one’s locally stored copy of any invalid data covered by the warrant, even if one would normally be a validation authority for that data.

WebAssembly (WASM)

A low-level program byte code format that can be run on almost any platform, including the web browser. Holochain expects zomes to be compiled to WebAssembly so the ribosome can execute them. See WebAssembly website.

Web hApp

A hApp bundled with a web-based UI.

Weight

A value, available as a field in most action types, that serves as an estimation of the cost of validating the operations and storing/serving the data associated with an action. This value, along with the timestamp of the action and actions preceding it, can be used in a validation function to throttle excessive source chain writes which could cause overloading of the network supporting a DHT.

Workspace

A snapshot of an agent’s current cell state, that is, their source chain, taken at the start of a zome function call. All commits are staged to this workspace and not written to the source chain until the function completes and validation succeeds for all commits (see atomic commit).

Zome

A basic unit of modularity inside a DNA. A zome defines a package of zome functions and can be either an integrity or coordinator zome.

Zome function

A function, created by the developer of a zome, that allows external code to access the zome’s functionality. A zome function can be:

An cell can control access to its public zome functions via capability grants.

It looks like you are using Internet Explorer. While the basic content is available, this is no longer a supported browser by the manufacturer, and no attention is being given to having IE work well here.