Hestia

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

What it actually does

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. 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 init created an encrypted vault and your LCT (your local cryptographic identity) on this machine. Nothing was uploaded anywhere.

2. 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. 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. 4

   The agent works. Before each consequential step it asks Hestia queryPolicy() (“am I allowed to do this?”), and every tool call is wrapped in beginAction() / 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. 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. 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. When you want company, hestia connect-hub <url> carries this same presence into a shared hub.

All of this runs today at version 0.0.3 (Phase 2). 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.

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.

That's also what makes the trust honest: because the witness chain is tamper-evident and the policy gate runs before each act, what your record claims and what actually happened can't silently diverge.

How to touch it

Hestia is a source-built binary (it lands at ~/.local/bin/hestia). 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. Connecting to a hub over hestia connect-hub is how a member carries embers to a shared hub.