Configuration
TOML config covers node identity, storage paths, admin binding, peers, optional facades, security mode, and energy thresholds.
Operations
Built for practical deployment, even early.
One process, one store, one exclusive lock — which is the fact that shapes everything below. Maintenance that changes state lives at the CLI because the daemon holds the store; the console is read-only by design, and the audit and collection surveys are the two panels that run on a button rather than on refresh.
Runtime State
Local data includes the storage backend, generated identities, head metadata, pinned peer keys, and the repository key when encryption is on.
Admin Visibility
The embedded admin layer is the local control plane for status, storage, oplog inspection, peer sync state, verification reports, and the current energy budget — including which rule is throttling replication and why.
Maintenance Commands
verify audits every signature and reads every file back,
gc surveys unreachable storage and only deletes with
--apply, migrate upgrades the on-disk format,
and peer enrols keys before first contact.
Two Trust Lists
/api/peers lists sync targets and how they are
doing; /api/peers/enrolled lists trusted keys. The
mismatch between them is what to look at when replication is silently
doing nothing.
Suggested workflow
- Use the example config for local development.
- Run focused crate tests during implementation.
- Validate the workspace before pushing milestone changes.
- Keep public docs and deep specs aligned as behavior changes.
Not covered yet
- Backup and restore beyond copying the data directory with the daemon stopped.
- Compaction of the underlying database, and collection of orphaned inode records.
- Reading the energy budget without the admin feature compiled in.