DIN SDK

DIN SDK

📋 Status: Planned — the DIN SDK 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.

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, targeted for the second half of 2026. 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