Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

start DIN daemon

Aberta
#21 5 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Santiagocetran já está trabalhando nisso.

Desde 13/7/2026.

  • #32 de @Santiagocetran — aberto

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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.

Linguagem predominante
Python
Estrelas
4
Forks
7
Merge médio
3d 5h
PRs com merge (30d)
34

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de InfiniteZeroFoundation/DevNet

Todas as issues de InfiniteZeroFoundation/DevNet

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.