Hestia
Hestia is the local-first, open-source presence layer of Web4. It gives any entity (a person, an AI agent, or a service) a real cryptographic presence on its own machine: a cryptographic identity (LCT), an encrypted credential vault, scoped revocable delegation authority, and a witnessed trust record. No account on someone's server, no profile in a database, no cloud. A sovereign presence you hold the keys to.
This is the universal presence primitive for humans and AI alike, not an agent-tracking add-on. Everything the rest of this site teaches as a concept (identity, the witness chain, trust that moves with outcomes, a policy gate) is what Hestia actually runs. It is the deployed answer to “okay, but does any of this exist?”
Where Hestia sits: the personal scale
Web4 has one substrate (the core standard) and three ways to run it, at three scales of the same posture. Hestia is the personal / per-agent scale: one person or one agent. The hub is the same shape for a community, and hardbound is the same shape for an enterprise. See how the four pieces compose on the Web4 onramp.
One presence layer, many faces
For humans
For AI agents
For services and the terminal
What it actually does
Cryptographic identity (LCT)
An encrypted credential vault
Under the hood+
ChaCha20-Poly1305 encryption, Argon2id key derivation, SQLCipher at rest.A witness chain
Trust that evolves
A policy gate
Scoped, revocable delegation
Verifiable credentials
A plugin SDK
A day with Hestia
Those are the parts. Here is what they look like put together, not as a feature list but as an ordinary Tuesday. Say you run an AI coding agent and you want it to act for you without handing it the keys to everything.
- 1
You open the Hestia app. It is a normal desktop app (the front door), with a dashboard, your vault, your witness chain, and your delegations. The first time you ran it,
hestia initcreated an encrypted vault and your LCT (your local cryptographic identity) on this machine. Nothing was uploaded anywhere. - 2
You stash the secrets your agent will need (an API key, a repo token) in the vault. They sit encrypted on your disk, not pasted into a config file the agent can read wholesale. The agent reaches them only through a controlled interface, one secret at a time.
- 3
You grant the agent scoped, time-boxed authority:
hestia delegate grant my-agent --role administrator --expires 24. For the next 24 hours it can act within that role, and the grant is cryptographically signed and revocable. Not a shared password you can never take back: a delegation you hand over on purpose. - 4
The agent works. Before each consequential step it asks Hestia
queryPolicy()(“am I allowed to do this?”), and every tool call is wrapped inbeginAction()/recordOutcome(), so what it did lands in your witness chain as it happens. Open the witness view and you see the record: what was done, under whose authority, against which rules. - 5
Something looks off, so you revoke:
hestia delegate revoke. The authority is gone immediately, and the tamper-evident record of what already happened stays. - 6
You link your laptop and phone into a constellation, so proving it is really you takes more than one device. That multi-device proof is your MFA, held by you, not a login screen on someone's server. This step is the one part of the day that is shipped code rather than daily practice: the constellation is wired into the hub handshake, but the path has not yet been driven on a real second device. When you want company,
hestia connect-hub <url>carries this same presence into a shared hub.
All of this is shipped code at version 0.0.3 (Phase 2), and all of it but the constellation step in 6 is in day-to-day use.
One honest caveat: the identity in this walkthrough is a software LCT held on your machine. Binding it to a physical security chip is the job of hardbound, the enterprise tier, and that hardware binding is not yet validated on real devices. What anchoring in software alone costs you, in trust terms, is three specific things, and they are worth knowing before you decide this is your long-term identity. A software-only identity is capped at 0.50 on the 0-1 scale every trust number on this site uses, where 0.90 is the hardware-bound ceiling (4-Life's calibration). Lose the machine and there is no second witness to vouch for you: you start over from zero with a fresh identity. And an identity anchored in software alone has no device to walk away from, so at that tier the record stays sheddable. The longer version is spelled out on the LCT page, and what this tier costs people who cannot get a security chip is the accessibility risk on what could go wrong.
Why local-first matters
Most “identity” on today's internet is an entry in a company's table: they hold the keys, they can revoke you, and a breach of their database is a breach of you. Hestia inverts that. The identity, the vault, and the history are yours, on your hardware. There is no central server to ask permission from, and no cloud account to lose.
The chain is also tamper-evident, which is a narrower promise than it sounds: an entry that is in it cannot be quietly edited or removed later. That is about what happens to an entry after it is written, not about whether it was right when it was written.
What the chain does not promise is completeness, and that is worth stating plainly on the page that invites you to run this. The same hook that runs the policy gate is the thing that writes the entry, so an action that routes around the gate (see the gate caveat below) writes no entry at all. Your witness chain is a record of governed activity, not a record of all activity, and silence in it is not proof that nothing happened. That limit comes from where the gate runs, inside the agent's own process rather than outside it, so it is not the kind of thing better heuristics close. It would take an observer the agent cannot reach, and that is not what ships today.
How to touch it
Start by getting the binary. Version 0.0.3 ships prebuilt hestia CLI binaries for macOS, Linux and Windows, so on a mainstream platform this is a download and an unpack, not a build:
Prefer to build it yourself, or on a platform without a prebuilt binary? cargo build --release in core/ produces the same binary at core/target/release/hestia. One honest gap: the cross-platform desktop app is the front door hestia is aiming at, and it is the one piece with no package to download yet. It builds from source; the packaged artifacts today are these CLI binaries plus an Android APK. That is why the walkthrough below is a terminal session rather than a screenshot tour.
A first run looks like this:
The daemon binds loopback only (127.0.0.1:7711) and fails closed if asked to serve off-loopback.
“Connect to what? Where do I get a URL?”
You don't need one to start. Everything above the divider runs entirely on your own machine: the vault, your identity, delegation grants, the witness record, the daemon. A hestia that never talks to a hub is not a crippled hestia, it is the normal solo case, and it is the whole of the walkthrough further up this page.
connect-hub is for when you want company. The honest status: The spec is written, the code is installable today, and there is no public network open to outside members yet. So there is no directory of hubs to browse and no address we can hand you here.
The URL is one you or your group stand up. A hub is a single small Rust daemon: build it from source or pull the Docker image, and its organizer quickstart puts a chapter online in 10 to 30 minutes. Then the URL is your own hub's address. The hub source and organizer quickstart →
Solo is not the mechanism switched off. The “no public network” caveat above is about reach, not capability. Web4 trust comes from being witnessed, and a solo hestia is already witnessing: when an agent acts under your delegation, your policy gate checks the act and your witness chain records it, and its T3/V3 move with the outcomes. What a hub adds is other people, and that path is not untried either: hub integration has been exercised end to end, down to sealed messages between two members that the hub relays without being able to read them (honest status). The fleet that builds hestia holds roles and witnesses its own work in the open (we run one).
Honest status: Phase 2, version 0.0.3
Hestia is Running in active development, at Phase 2 (connected presence). The core (vault, policy engine, witness chain, delegation, plugin SDK) and the cross-platform app are built and working, and hub integration works end to end: a hestia joins a hub, opens an encrypted member-to-hub channel, carries a device constellation proof in the handshake, and exchanges sealed member-to-member messages that the hub relays without being able to read them. The constellation is the one item in that list that is built rather than exercised: the code ships and the handshake carries it, but it has not yet been driven on a real second device.
What ships today at version 0.0.3: an MCP server (8 tools), a plugin SDK (Rust, TypeScript, Python), a Claude Code plugin, a CLI, a TUI, and a Tauri app, plus OID4VCI credential issuance.
The policy gate stops accidents, not adversaries. The gate that checks an agent's action before it runs is an early prototype. It reliably stops simple erroneous or accidentally destructive commands and it produces an accountability record, but it is not built to stop a sophisticated agent from routing around it (two environment variables suffice today), and a heuristic gate will always play whack-a-mole with a general reasoner. Read issue #49 for the measured bypasses and the planned hardening before you rely on it.
Hardware binding is trait contracts only for now, deferred to the hardbound enterprise tier, where a soft LCT becomes a TPM-bound one. Multi-society federation (entities and societies trading trust across boundaries) is Spec still: specified, on the roadmap, not yet running. See the full maturity map.
It's open source (AGPL-3.0) and runs on your own machine. You don't have to take any of this on faith: read the code and run it.