Decentralized Storage & Indexing

InfraMind separates model execution from model storage. While the runtime operates in a decentralized mesh of compute nodes, the model binaries, manifests, and metadata must be stored and retrieved in a trustless, persistent, and content-addressable format. To accomplish this, InfraMind leverages decentralized storage systems like IPFS and Arweave, along with optional hybrid CDN fallbacks for performance-sensitive deployments.

This architectural split ensures that execution environments remain stateless and interchangeable, while model data remains reproducible, publicly verifiable, and tamper-resistant. It also ensures that no centralized file server can be used to manipulate, censor, or selectively gate model containers.

The preferred storage backend is IPFS (InterPlanetary File System), which enables content-addressed retrieval across a peer-to-peer network. Every model uploaded to InfraMind is hashed into a CID (Content Identifier), which becomes the canonical reference in the model registry.

Example CID:

QmU1WxjeYGqsxTg1Zq5MbENRgt1w3AiV6gYCNzSpYud6EM

This CID maps to a bundled directory containing the container image (.tar.gz or OCI layer), model.yaml, and any auxiliary files:

/QmU1Wxje.../
├── model.yaml
├── container.tar.gz
├── README.md
└── hooks/
    └── init.sh

InfraMind does not rely on mutable DNS or storage pointers. Instead, model references in job payloads use the CID directly, removing the need for trusted servers or external APIs:

{
  "model_ref": "ipfs://QmU1WxjeYGqsxTg1Zq5MbENRgt1w3AiV6gYCNzSpYud6EM",
  "entrypoint": "serve.py"
}

When a node receives a job assignment, it checks its local content cache. If the container is not cached, the node attempts to retrieve the package from the IPFS network using a pinned gateway or local peer connection. Nodes can run IPFS daemons or use public gateways with rate limiting:

ipfs get QmU1WxjeYGqsxTg1Zq5MbENRgt1w3AiV6gYCNzSpYud6EM -o /tmp/model_bundle/

To ensure availability and eliminate reliance on upstream peers, InfraMind operates a coordinated pinning strategy. Upon successful registration of a model, the container is:

  1. Pinned to InfraMind indexer nodes (with bandwidth constraints)

  2. Optionally copied to regional edge pinning nodes

  3. Backed by fallback CDNs (for initial pull acceleration)

CDNs are used strictly as redundancy and are always validated by hash. Nodes that retrieve models via HTTPS or S3 gateways must verify the container hash matches the registry reference.

sha256sum container.tar.gz
# Check against model_ref hash prefix

This hybrid model ensures that even if IPFS peering is slow or interrupted, the container can be retrieved and validated from multiple independent sources.

Arweave is used optionally for permanent archival of critical model versions. Since Arweave is optimized for long-term immutable storage and not fast retrieval, it is typically paired with IPFS-based layers in a cascading structure. The Arweave transaction ID is stored in the model registry as a backup reference.

{
  "model_ref": "ipfs://QmU1Wxje...",
  "arweave_txid": "MXxykM7zRNGnE2a3iRC3jH8vREzZ56CAG9KXLWGrU",
  "cdn_url": "https://infra-cdn.net/QmU1Wxje..."
}

During retrieval, nodes attempt in the following order:

  1. Local disk cache (~/.inframind/cache/)

  2. IPFS local daemon

  3. InfraMind public gateway

  4. Arweave (if enabled)

  5. CDN fallback

The container is unzipped, validated, and mounted as an isolated job environment.

Pinning is coordinated via an internal CLI or automatic staking incentive:

infra pin --model ipfs://QmU1Wxje... --stake 10

Nodes that voluntarily pin popular models receive micro-rewards from registry fees. Pinning is a decentralized CDN model: the more widely pinned a model is, the faster it propagates, and the less load any single node bears.

Model metadata is indexed in a distributed registry, with the option of dual publication (on-chain or off-chain with Merkle root anchoring). Each model includes:

  • CID

  • Name and version

  • Hash of model.yaml

  • Deployer signature

  • Timestamp

  • Supported schema

  • Container digest

Sample registry entry:

{
  "model_id": "summarizer-v1",
  "cid": "QmU1Wxje...",
  "digest": "0x921af3...",
  "owner": "0xB16b00b5...",
  "version": "1.0.4",
  "size_bytes": 28311492,
  "registered_at": 1719809200
}

Nodes query the model index using:

infra pull --model summarizer-v1

The system supports immutable versioning. Updates must be published as new model IDs or semver-incremented containers. No mutable overwrite is allowed unless the model is marked as mutable: true in its registry flags.

InfraMind guarantees that the execution runtime is directly derived from the container referenced by its content hash. All jobs are tied to a specific model CID. All containers are verified on pull. All results can be traced back to the exact model version that produced them.

Decentralized storage and content-addressable indexing are not features of the protocol—they are foundations. InfraMind does not serve models from the cloud. It routes containers from peers. It doesn’t resolve by URL. It resolves by hash. It doesn’t check for availability on a vendor’s server. It checks for integrity across a distributed storage mesh.

This design eliminates trusted hosts, reduces risk of model tampering, and ensures that every execution on the mesh is reproducible, audit-capable, and verifiably untethered from the infrastructure it runs on.

PreviousJob LifecycleNextHardware Requirements

Last updated