what is helia?

helia is the backend that gives si a shared memory and a secure control plane.

if si is the execution layer, helia is the place where execution context can be stored, synced, delegated, and audited across machines.

without helia, teams can still run locally, but every machine becomes an island:

profile and auth artifacts stay scattered
machine handoff is manual and fragile
delegation requires sharing secrets in unsafe ways
remote operation is hard to reason about

helia solves that by making state and access explicit.

the short version

helia is an account-scoped API service with four core jobs:

sync versioned objects safely across machines
issue and revoke scoped tokens for delegated access
enforce account boundaries and role-aware permissions
record mutation events for auditability

that sounds small, and it is by design. the point is to keep the model simple while making distributed operation dependable.

why we built it

as soon as si started being used across more than one machine, friction showed up fast.

operators wanted to:

sign in once and continue from another machine
let one machine run commands on another with bounded permissions
keep backups and profile state portable
avoid copying raw credentials around

the missing piece was not another agent framework. it was a clean backend that treats operational state as first-class and applies straightforward auth rules.

that backend is helia.

how helia works

helia stores typed objects in an account namespace. each object has:

a kind (for example profile auth cache, settings, or vault backup artifact)
a name (the concrete object key)
revision history
optimistic concurrency (expected_revision) for safe writes

this gives you deterministic sync behavior:

read latest revision
write with expected revision
on conflict, fetch and reconcile

no hidden merge magic. no silent overwrite.

security model in plain terms

helia uses scoped bearer tokens and keeps them account-bound.

scope examples include:

objects:read and objects:write
tokens:read and tokens:write
team:read and team:write
audit:read

delegation follows a simple rule: you cannot mint a token with scopes you do not already hold.

for sensitive payloads such as vault backup artifacts, the intended pattern is client-side encryption before upload so the server stores opaque ciphertext instead of plaintext secrets.

where this fits in the si model

think of it as layers:

si: command/runtime surface for execution
helia: shared state + auth + audit substrate for distributed operation

this boundary is important. helia is not a replacement for si commands. it is the infrastructure that lets those commands work consistently across devices, users, and automation agents.

what this unlocks next

with helia in place, si workflows can move from single-machine scripting to coordinated operations:

profile sync without ad hoc file transfer
machine-to-machine delegation with explicit token scope
remote control patterns (list, run, and orchestration style commands) with auditable actions
stronger team workflows around assignment, locking, and ownership for autonomous agents

in other words: less hidden state, fewer trust leaks, and clearer operational control.

final thought

helia is intentionally boring in the best way.

it does not try to be everything. it gives si a dependable backend for sync, delegation, and control so execution can scale beyond a single laptop without becoming opaque or unsafe.

if you use si across machines, helia is the missing layer that makes that model complete.