DIN SDK

DIN SDK

🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and dincli on the develop branch; the currently running DevNet may still use older contracts and commands. Pre-launch discussion: #102.

⚡ Status: In progress, not on develop yet. The extraction has started in PR #31 (feat/din-sdk), which begins dincli/sdk/operations/; role operations, CLI adoption and a frozen interface are still to come. This page describes the design intent per the project roadmap (phase P4); details may change as the architecture spec is finalized.

What it will be

The DIN SDK is the planned extraction of dincli's reusable core into a library layer (dincli/sdk/) that any Python program can import — not just the CLI. Today, the logic for talking to the DIN network lives inside the DIN CLI's command implementations; the SDK pulls it out into a clean, importable interface.

Modules slated for extraction:

• IPFS client — the upload/retrieve abstraction and provider selection (IPFS Layer)
• Contract interfaces — typed access to the Platform Contracts and Task Contracts
• Wallet & account helpers — keystore handling, account resolution, transaction building
• Manifest loading — fetching, caching, and resolving a model's manifest.json and its service CIDs

Why it exists

The driver is dind, the DIN Daemon — the planned always-on agentic execution layer that automates network participation (clients, validators, evaluators, model owners) instead of requiring hand-run commands for every GI phase. dind needs everything the CLI can do; without an SDK it would have to reimplement all of it. Extracting a shared layer means:

• the CLI and the daemon import the same battle-tested code, with no circular dependencies;
• existing dincli commands keep working unchanged during the transition (backward compatibility is an explicit requirement, verified by the existing test suite);
• third-party tooling — dashboards, bots, custom operator automation — gets a supported way to integrate with DIN from Python.

How it fits

                     dincli/sdk/   (planned)
                    IPFS · contracts · wallet · manifest
                          ▲                ▲
              imports     │                │     imports
                 ┌────────┴───┐      ┌─────┴──────┐
                 │   dincli   │      │    dind    │  (planned daemon)
                 │  (the CLI) │      │ automation │
                 └────────────┘      └────────────┘

The daemon work also converges with the DIN Node: today din-node idles and operators exec commands into it; once dind lands, the daemon becomes the container's main process, using the SDK to watch on-chain events and execute jobs automatically.

Status & sequencing

Per the roadmap, an architecture document (system-level dind design plus the SDK extraction scope and public interface) precedes implementation; the extraction itself is an early P4 work package (P4 runs Sep–Nov 2026). In practice the extraction PR has started ahead of the architecture document. This page will be updated as the interface stabilizes.

Further reading

• Roadmap — P4 phase: daemon and SDK work packages
• DIN CLI — the current home of everything the SDK will extract
• DIN Node — where the dind daemon will run