start DIN daemon

[umeradl]

Branch: feat/din-daemon (branch off feat/din-sdk until the SDK merges into develop, then rebase onto develop)
Assignee: @Santiagocetran
Roadmap ref: P4-1.1 (dind Daemon Framework) and the P4 daemon work-package series · P3-DOC7 (architecture spec)

Long-running issue (expected to stay open 1–2 months). A detailed task file under Developer/tasks/ will follow — this issue tracks the overall effort, not a weekly task.

Goal

Build dind, the DIN daemon: an always-on host process that automates network participation (task discovery, job execution, coordination) across client/auditor/aggregator roles, per the P4 phase of Developer/ROADMAP.md.

Relationship to the DIN-SDK

dind does not reimplement CLI logic. All protocol logic lives in dincli/sdk/ (see the "start DIN-SDK" issue). SDK functions return JSON outputs; dind consumes that JSON to update its configuration and drive its job queue, while the CLI consumes the same JSON for terminal UI/UX. The SDK's JSON interface is therefore a prerequisite for daemon job execution — daemon scaffolding (event loop, state store, process lifecycle) can start in parallel, but role automation depends on the SDK.

Scope (initial framework — P4-1.1)

• Daemon process architecture: event loop, job scheduler/queue, persistent state store (SQLite or JSON-backed — document the tradeoff)
• Graceful SIGTERM handling from day one (carry forward the P3-T0.2a pattern)
• Structured JSON logging from day one (carry forward the P3-T0.2d pattern)
• Basic CLI: dind start, dind stop, dind status
• HTTP /health endpoint (carry forward the P3-T0.2c pattern; extend with a resource summary)
• systemd/launchd unit examples
• Configuration/job-queue updates driven by SDK JSON outputs

Later P4 work packages (preferences, capability detection, task discovery/recommendation, role automation, event listening — P4-2.x through P4-7.x) will be tracked as follow-up task files against this issue.

References

• Developer/ROADMAP.md — P4 phase overview and work packages P4-1.1 → P4-9.2
• Developer/issues/validator-operations.md — Phase 2 "Daemon Operations" (/health, structured stdout logging)
• Developer/issues/containerization.md — Phase 5 "Daemon Integration" (same container runner used from dind; host dincli/dind owns wallet, network, contracts, task selection, submissions)
• P3-DOC7 (dind Architecture Document, authored by Umer) precedes implementation of the automation layers

Branching note

Two branches, not one: feat/din-sdk is a refactor of existing code that should merge into develop early; feat/din-daemon is new code consuming the SDK. Keeping them separate keeps PRs reviewable and lets the SDK land without waiting on the daemon.

[Santiagocetran]

I'm sequencing this behind the SDK contract from #20 for role automation. Per the branching note, feat/din-daemon builds on the SDK's JSON-serializable interface, so I'm landing the SDK extraction into develop first rather than keeping two logic-heavy branches diverging.

One clarification before I start here: do you want feat/din-daemon to remain idle until the SDK contract stabilizes, or should I start scaffold-only work in parallel on the separate branch? The scaffold-only slice would be limited to process lifecycle, event loop skeleton, job queue/state-store choice, structured logging, SIGTERM handling, /health, and dind start|stop|status, with role automation deferred until #20 defines the SDK contract.

[umeradl]

Start the scaffold-only work in parallel — don't leave feat/din-daemon idle waiting on the SDK.

The slice you've scoped is exactly right: process lifecycle, event-loop skeleton, job-queue/state-store choice, structured JSON logging, SIGTERM handling, /health, and dind start|stop|status. That's precisely the P4-1.1 framework scope, and none of it depends on the SDK's JSON contract — it's SDK-independent by design (see the "daemon scaffolding can start in parallel, but role automation depends on the SDK" note in the issue). Defer only the role-automation layer until #20 has the SDK contract nailed down, as you proposed.

Same reasoning as on #20: the roadmap's sequential phasing was written for a single developer, and now that we're a team the point is to parallelize wherever the dependency graph allows. The SDK↔daemon boundary is one of those clean seams, so run both.

Keep the branching discipline you described — feat/din-daemon off feat/din-sdk until the SDK lands in develop, then rebase onto develop. And as with #20: if a weekly task unrelated to these issues gets assigned to you, that takes priority; otherwise keep both fronts moving.

[Santiagocetran]

Sounds good — starting the scaffold in parallel. Created feat/din-daemon off feat/din-sdk (will rebase onto develop once the SDK lands, per the branching note).

Scope I'm taking for the P4-1.1 framework, all SDK-independent: process lifecycle + dind start|stop|status, event-loop skeleton, job-queue/state-store (SQLite vs JSON — I'll document the tradeoff), structured JSON logging (carrying the P3-T0.2d pattern), SIGTERM handling (P3-T0.2a), and the /health endpoint + resource summary (P3-T0.2c), plus systemd/launchd unit examples. Role automation stays deferred until #20's SDK contract is frozen.

SDK side is moving in parallel: the interface proposal is up for your review on #20, and dincli/sdk/ is now seeded (cid module + error taxonomy + an import-boundary test that enforces the SDK pulls in no CLI/UI code).

[Santiagocetran]

Opened a draft PR for the P4-1.1 scaffold: #32 (fork → feat/din-sdk base, kept as draft). It lands the SDK-independent framework — dind start|stop|status, event loop + SQLite job queue, graceful SIGTERM, /health + resource summary, structured JSON logging, systemd/launchd examples, and the container entrypoint/healthcheck handoff. 137 tests green; start→health→stop verified end-to-end. Role automation stays deferred until #20's SDK contract is frozen.