The Web4 onramp
There are really only four pieces to learn. One is the substrate you build on: the core standard. The other three are the ways you actually run it, at three scales of the same posture: the hub for a community, hestia for a person or agent, and hardbound for an enterprise.
They aren't four separate products that happen to look alike. They are one shape at three scales, all speaking the same vocabulary. This page is the map: what depends on what, what to pick up first, and where the pieces actually plug into each other in code.
One substrate, three scales
Dependency direction (build order)
The order things get built is simple: first the core standard, then { hub, hestia, hardbound }. All three products are downstream consumers of the same canonical libraries, and none of them reimplement the primitives.
The hub, hestia, and hardbound each take these as dependencies. That is why they stay consistent with each other: they are all speaking the same canonical primitives rather than three private copies that drift.
Adoption order (what to pick up first)
Read the core standard
Learn the primitives (LCT, T3/V3*MRH, ATP/ADP, and R6/R7). This is the vocabulary everything else speaks, so it is worth a pass before you pick a scale. See the standard and the glossary.
Pick your scale
Personal / per-agent: hestia
The lowest-friction, hands-on entry. One binary, hestia init, and your agents get witnessed identity plus a vault. It is the Web4 posture at personal scale: the same shape a hub has at society scale.
Community: the hub
hub init bootstraps a sovereign society with signed law and a witnessed ledger. Members connect to it using hestia (hestia connect-hub).
Enterprise: hardbound
The oversight tier. It swaps hestia's soft identity for hardware-bound identity and adds RBAC plus regulatory evidence.
Where the pieces actually connect
These are the real, in-code seams, not aspirational ones. The pieces fit because they were built to share an interface.
hestia to the hub
hestia connects to the hub over an end-to-end sealed member-to-hub channel (hestia connect-hub). The hub also supports remote vault signing from hestia via hub init --sovereign-hestia.
hestia to hardbound
hestia is the reference implementation of the Web4 presence protocol, and hardbound is the hardware-bound enterprise variant of the same interface. The plugin surface does not change: a soft LCT becomes a TPM-bound LCT, and an Argon2id-protected passphrase becomes a TPM-sealed key.
hardbound also maps cleanly back onto the standard: its policy service maps to the standard's Law Oracle role, and its trust model maps to canonical T3/V3. Nothing is special-cased; the enterprise tier is the same ontology with harder guarantees.
Where this is on the maturity ladder
Be honest with yourself before you build on it: the whole stack is R&D, not production. Here is where each piece stands.
- The hub is Reference MVP / pilot-ready.
- hestia has its core (vault, policy engine, witness chain, delegation, plugin SDK) and app built and working, with hub integration end to end.
- hardbound is a usable, actively-hardened enterprise tier whose hardware binding is not yet validated on-device.
Start with the vocabulary, then pick your scale. Every piece links back to the same substrate.