[Feature request] OCI image pull from IPFS (pinned content + public gateway)

[HavenCTO]

Summary

Support deploying TEE workloads whose OCI image is addressed by IPFS content identity (CID), with layers pinned via a third-party pinning service and retrievable through a public IPFS gateway — so operators are not required to use a traditional container registry (e.g. Docker Hub) for the deploy path.

Motivation

• Supply chain & ops: Teams want to publish immutable images by content address (CID) and rely on pinning + gateways for distribution, instead of maintaining registry accounts and docker push to a centralized hub.
• Decoupling: Wallet / agent keys used for messaging or app logic can stay separate from registry credentials and legacy “push to Hub” workflows.
• Ecosystem alignment: OCI layouts can be distributed over IPFS (e.g. containerd/nerdctl-style IPFS workflows); TEE platforms that only accept registry/repo:tag force a registry-shaped step even when content is already addressed on IPFS.

Desired behavior

1. Input: Deploy API / CLI accepts an image reference that unambiguously identifies an OCI image on IPFS, e.g.:

   • ipfs://<CID> (or equivalent documented URI), and/or
   • https://<public-gateway>/ipfs/<CID> only if you document how the runtime resolves that to an OCI manifest + layer blobs (not raw tarball unless that’s your contract).

2. Runtime: The node that materializes the image for the TEE pulls manifests and blobs via gateway and/or IPFS (pinning ensures availability), verifies digest integrity against the OCI manifest, and runs the same integrity / policy guarantees as for registry-backed images.

3. Docs: Clear limits (max image size, timeout, supported OCI media types, whether estargz/lazy pull is required) and recommended pinning + gateway patterns for production.

Non-goals (for this issue)

• Replacing attestation or billing; this is distribution / image resolution only.
• Mandating a specific pinning vendor; any standards-compliant pinning + public gateway should work if CIDs resolve.

Suggested acceptance criteria

• Documented image reference format for IPFS-backed OCI deploys.
• End-to-end path: pin OCI image → deploy with CID/gateway reference → workload runs in TEE without requiring push to Docker Hub or another classic registry (unless operator chooses to).
• Integrity: image root digest / manifest matches pinned content; failures are explicit.
• Reasonable errors when CID is unpinned, gateway times out, or manifest is not valid OCI.

References

• OCI + IPFS tooling in the broader ecosystem (e.g. containerd/nerdctl IPFS docs, IPDR) — platform may still need a first-class contract for EigenCloud.

Context (optional)

Agents want out-of-band image publication (CID + gateway) while keeping messaging and keys separate from Docker Hub–style workflows.

[HavenCTO]

If this this isn't going to be prioritized please at least run an abstraction layer for us to use, I built this here https://github.com/HavenCTO/ipfs-oci-registry but I will not run this as a public service for people to use for free.