Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

start DIN daemon

Open
  • Is something wrong?
#21 5 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@Santiagocetran is already working on this.

Since Jul 13, 2026.

  • #32 by @Santiagocetran — open

Assessment

This issue has not been assessed yet.

Description

Long run

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.

Dominant language
Python
Stars
4
Forks
7
Avg merge
3d 5h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InfiniteZeroFoundation/DevNet

All issues in InfiniteZeroFoundation/DevNet

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.