The Web4 onramp
One word first: the onramp is the shortest path from zero to running Web4 yourself, and it runs through the four pieces below.
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: hestia for a person or agent, the hub for a community, and hardbound for an enterprise.
That is the order this page uses throughout: the same four pieces every time, smallest scale first.
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 { hestia, hub, hardbound }. All three products are downstream consumers of the same canonical libraries, and none of them reimplement the primitives.
hestia, the hub, 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
If you are one person, or one agent on your own machine, this is your scale. Start here. It is 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
You have a group that wants to govern itself, and this is your scale. hub init bootstraps a sovereign society with signed law and a witnessed ledger. Members connect to it using hestia (hestia connect-hub). Know what you are signing up for: you would be standing up one of the first live instances, not joining an existing network.
Enterprise: hardbound
Your organization has to answer to auditors, and this is your scale. The oversight tier. It swaps hestia's soft identity for hardware-bound identity and adds RBAC plus regulatory evidence. It is usable and under active hardening, not production; the ladder below says what that means for its hardware binding.
Where the pieces actually connect: the in-code seams
These are the real, in-code seams, not aspirational ones. The pieces fit because they were built to share an interface. Where an edge you would expect is missing, that is named here too.
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.
the hub and hardbound: the edge that is not there
Three scales and two seams, so a third edge looks like it has to exist by symmetry. There is none: no mention of hardbound anywhere in the hub's source. That absence carries two verdicts rather than one, and the next paragraph takes them in turn: for membership nothing is missing, and for verification something is. The seams above are real because they are code, and this one is absent for the same reason. hardbound's public contract ships as a Rust crate inside hestia, a set of traits any hardware-bound implementation has to satisfy, which is what makes the hestia edge an interface. The hub has no counterpart to it.
So can a community society include enterprise-tier members? Nothing in the hub excludes one. Joining means presenting an LCT and a signature, and the hub pins that key when it admits you; it never asks what is holding the key. What the hub cannot do is check. As it stands today, a device counts as hardware because its owner committed it as hardware beforehand, which is stronger than taking the presenter's word for it and is still not a measurement. The layer that would verify a TPM or a Secure Enclave is named in the hub's code and not built. That is an accepted limit right now rather than a scheduled repair.
And can an enterprise and a community federate? That is a different question with a different owner. Two societies meeting is the standard's business, not a hub-to-hardbound feature, so the answer does not turn on which side runs which software. It is also the answer the rest of the site already gives: federation across societies remains Spec only, specified but not yet built (see the full maturity map).
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.
- hestia has its core (vault, policy engine, witness chain, delegation, plugin SDK) and app built and working. Its policy gate stops accidents, not adversaries: the gate is an early prototype that a capable agent can route around today.
- The hub is Reference MVP / pilot-ready, with hestia integration working end to end. It is runnable reference code a community can stand up, not yet a live network of real users.
- 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.