Inputs
- User stories
- Functional requirements
Output:
- Architectural high-level DHTs components with dependencies and functions
Concepts
Holochain’s crucial aspect regarding DHT architecture is the fact that every happ creates its own network or DHT. Those networks can be public, private, permissioned, or impose certain conditions for an agent to be able to enter.
This makes architecturing your network topology a big first step when designing a happ.
Any holochain application system can be described as a set of high-level DHT components. For purposes of this workshop, you can think about DHTs as a shared space, in which all agents can see every piece of data published in it.
Questions to ask
- Which agents and roles exist in your happ?
- What information will each of these agents publish into the system?
- Which other agents should be able to access that information?
Rules of thumb
- Define a new DHT shared space every time you have a group of agents that should be able to read some specific information, but not everyone should be able to see it.
- Define a new DHT every time you need to propagate information from one agent to another, but they are not on any shared space.
- Define a new DHT if you need special nodes to store a subset of the information (e.g. indexing nodes, file storage, etc.).
These rules don’t cover all the cases, but can guide you towards the appropriate solution.
Example
TBD
Input
- DHT components of your system
- User stories
- Processes by which an agent enters each shared space
Output
- Breakdown of each high-level component into modular and re-usable zomes
Concepts
Holochain applications are composed of different modules or zomes. Each zome is an aggregation of:
- Entry types definitions
- Link types definitions between those entries
- Validation rules for those entries and links
- Function calls exposed to the exterior
- Validation rules for any agent trying to access the network
- Lifecycle callbacks like
init,receive_direct_message...
Zomes don’t actually specify which entries they are going to be storing, but defining which type of entries are supported. In a traditional database system, this would be akin to a database schema specification.
Different technical aspects apply to the relationship between multiple zomes: