DIN Daemon

DIN Daemon (dind)

📋 Status: Planned — dind does not exist yet. This page describes its design intent per the project roadmap (phase P4); details may change as the architecture spec is finalized.

Naming note: dind follows the Unix daemon convention (DIN + d, like sshd, dockerd). It is unrelated to Docker's "docker-in-docker" (DinD) — in fact, DIN's container architecture deliberately avoids docker-in-docker by spawning Worker Nodes as siblings on the host daemon.

What it will be

dind is the planned always-on agentic execution layer of DIN: a long-running daemon that automates network participation across every role — clients, auditors, aggregators, and model owners.

Today, participation is one-shot: every GI phase is a hand-run DIN CLI command, and a validator who is asleep when a registration window opens simply misses it. dind inverts that model — it keeps running, watches the chain, and acts:

• Event loop & job queue — on-chain events (a phase opening, a batch assignment) drive job execution automatically, with persistent state so restarts don't lose work.
• Worker orchestration — spawns sandboxed Worker Nodes as needed for training, scoring, and aggregation jobs, resource-aware and with retry and failure recovery.
• Monitoring & operability — dind start/stop/status CLI, HTTP /health endpoint for watchdog auto-restart, structured JSON logs, graceful SIGTERM handling, and systemd/launchd service units.
• Context-aware participation — a local preference system (domain, risk tolerance, reward expectations, privacy constraints) decides which tasks the node takes on, instead of blindly joining everything.

How it fits the other components

dind is a consumer, not a replacement, of the existing stack:

• Built on the DIN SDK — the daemon imports the same extracted core (IPFS client, contract interfaces, wallet helpers, manifest loading) as the CLI, rather than reimplementing it. The SDK extraction is an explicit prerequisite on the roadmap.
• Runs inside the DIN Node — today din-node idles (sleep infinity) and operators exec commands into it; when dind lands, it becomes the container's main process, and the container's logs carry real activity. The node's operational patterns (health endpoint, SIGTERM, structured logs) are being built in P3 precisely so dind inherits them.
• DIN CLI stays — the CLI remains the interactive and scripting interface; existing commands keep working unchanged. Daemon and CLI share preferences and state through the SDK layer.

                on-chain events (phases, assignments)
                              │
                              ▼
   ┌───────────────────── din-node ─────────────────────┐
   │   dind (main process, planned)                     │
   │     event loop · job queue · preferences · /health │
   │           │ imports              │ spawns          │
   │           ▼                      ▼                 │
   │      DIN SDK              din-worker containers ───┼── sandboxed jobs
   └─────────────────────────────────────────────────────┘

Sequencing

Per the P4 roadmap: architecture document first (daemon/CLI split, state ownership, event-driven execution), then the daemon framework and SDK extraction, followed by the preference system, per-role automation (client → validator → model owner), daemon-level security hardening, and finally devnet integration with multi-role simulation, culminating in a public dind v1.0.0 release.

Further reading

• Roadmap — P4 phase work packages
• DIN SDK — the shared library layer dind is built on
• DIN Node — the container dind will run in
• Worker Node — the sandboxed jobs dind orchestrates