SEIF Protocol

seif-daemon is the per-pod sync and coordination fabric. Each background component is a named capability you enable, disable, and supervise independently.

seif daemon configures and runs seif-daemon — the unified, per-pod sync and coordination fabric. Instead of a sprawl of separate always-on background scripts, every working component (workspace sync, the AI↔AI bus, relay watchers, …) is re-homed as a named capability that you enable, disable, and supervise on its own. A hygiene operation can pause one leg without killing the host.

Mental model

Three ideas carry the whole design:

Capabilities, not services. A capability is a toggle plus an optional leg — the actual command the daemon supervises for it. Toggling a capability never touches the others.
Paused by default. Every capability ships PAUSED. Enabling is always the operator's explicit call; nothing turns itself on.
Host-runtime config. State lives in ~/.seif/daemon.json, which is host-runtime (Layer 5) — it never travels with seif push. Your daemon layout is local to the machine, by design.

seif daemon status          # every capability: enabled | role | leg | live state
seif daemon enable hub      # turn one capability on
seif daemon disable hub --reason "pausing the bus during a sync sweep"

A leg only runs when its capability is enabled

Declaring a command (set-command) on a disabled capability is inert — the toggle stays the operator's decision. Enabling a capability with no declared leg is a pure marker until you attach one.

No permanent agent

The daemon deliberately installs no system service — no launchd plist, no systemd unit, no always-on agent. This follows the protocol's access decays principle: capability should never outlive its need.

seif daemon up lazily spawns the daemon as a detached process.
It self-shuts down on an idle TTL (15 minutes by default) once no legs are running and no subscribers are connected.
seif daemon down asks a running daemon to exit, or reaps a stale socket.
The control socket is a local-only Unix socket (mode 0600) under ~/.seif/runtime/ — there is no network listener.

The practical consequence: you don't "install" the daemon. You enable the capabilities you want, and it comes up when something needs it and steps away when nothing does. If you want it pinned to boot, wrap seif daemon up in your own service manager — the protocol won't do it for you.

Capabilities

The canonical capability set. Some are role-scoped — meaningful only on a write node (writer) or a read replica (observer) of a pod.

Capability	What it does	Role
`context-sync`	Workspace `.seif/` sync	any
`personal-sync`	Sovereign / personal store sync	any
`hub`	Realtime AI↔AI bus relay	any
`circuit`	Circuit heartbeat / liveness	any
`responder`	On-host responder	any
`peer-drainer`	Peer bus drainer	any
`compose-push`	Pod compose push (writer-host → observer-host)	writer
`compose-pull`	Pod compose pull (observer-host ← writer-host)	observer
`inbox-push`	Realtime inbox fanout (pod fabric)	writer
`pod-state-notify`	Inter-terminal pod-state notify	any
`claim-relay`	Claim acquire/release fan-out → human view	any
`vigilant`	Pin-drift watch → repin proposal + auto-reindex (propose-only)	any
`relay-watch`	Relay brief/handback/inbox/handoff filesystem watch → bus topic (metadata-only)	any
`relay-sentinel`	Relay accountability sentinel: board scan, TTL requeue, digest	any

Run seif daemon status for the live view on your host — it shows each capability's enabled state, its role applicability, the declared leg, and whether it is currently running.

Long-running vs periodic legs

A leg is either long-running (kept alive with supervised crash-restart and exponential backoff) or periodic (run on startup, then on a fixed interval). vigilant and relay-sentinel, for example, run as periodic ticks; relay-watch runs long. You choose when you attach the leg:

seif daemon set-command relay-watch --kind long-running -- seif daemon relay-watch
seif daemon set-command vigilant --kind periodic --interval 300 -- seif daemon vigilant tick
seif daemon clear-command vigilant    # revert to a pure toggle

Real-time bus

When the relevant capability is enabled, the daemon carries a small real-time event bus. You can publish and subscribe to topics as JSONL streams:

seif daemon subscribe relay --count 10
seif daemon publish pod-state --message "writer going offline for maintenance"

Topics are capability-gated: pod-state requires pod-state-notify, inbox requires inbox-push, relay requires relay-watch. Publishing to a topic whose capability is disabled is a no-op.

Adopting legacy background jobs

seif daemon adopt-legacy is a one-time migration helper, not part of the day-to-day loop. If a machine still runs older, separately-installed SEIF background jobs (as launchd agents on macOS), this command discovers them and re-homes their exact commands as capability legs — without enabling anything.

seif daemon adopt-legacy            # dry-run: shows what it would wire
seif daemon adopt-legacy --apply    # persist the legs (still PAUSED)

It maps each recognized legacy job to its modern capability, wires the existing command verbatim, and leaves the capability paused so nothing changes behavior until you explicitly enable it. Jobs it doesn't recognize are reported and skipped — never adopted blindly. Once a host has no legacy jobs left to adopt, the command has nothing to do; treat it as a migration and diagnostic aid rather than an everyday verb.

Where to go next

The daemon is the substrate under multi-machine pods and AI↔AI orchestration. See the CLI reference for the full, always-current seif daemon command tree.