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

[HavenCTO]

Summary

Support deploying confidential / TEE workloads whose OCI container image is identified by IPFS (content-addressed, pinned via a third-party pinning service, fetched via a public IPFS gateway), so operators are not required to use a traditional container registry (e.g. Docker Hub) as the only way to supply the image.

Motivation

• Distribution: Prefer CID + pinning + gateway over docker push to a centralized registry for immutable, content-addressed images.
• Separation of concerns: Application keys (wallets, XMTP, etc.) stay out of registry vendor flows; infra can publish images via IPFS-only pipelines.
• Alignment: Broader ecosystem work exists for OCI-on-IPFS; Phala/dstack would benefit from a documented, supported deploy path instead of assuming registry/repo:tag only.

Desired behavior

1. Deploy surface (CLI, API, or app-compose / equivalent) accepts an image reference that resolves to an OCI image on IPFS, e.g.:

   • ipfs://<CID> or a single documented URI scheme, and/or
   • Explicit support for gateway URLs that resolve to OCI manifest + blobs (with clear rules: not ambiguous “any HTTPS URL”).

2. Runtime: Workers that load images for TDX/dstack materialize the image from IPFS (direct or via gateway), verify digest/manifest consistency, then run with the same security posture as registry-backed images.

3. Documentation: Pinning best practices, gateway timeouts, size limits, and failure modes (unpinned CID, invalid manifest).

Non-goals

• This issue is not about replacing RA-TLS, attestation, or @phala/dstack-sdk key APIs — only how the container image bytes are sourced.

Suggested acceptance criteria

• Documented image reference format for IPFS-backed OCI.
• E2E: pin OCI image → deploy with CID/gateway → workload runs in TEE without mandatory Docker Hub (or any classic registry) in the path.
• Cryptographic consistency between expected digest and resolved layers.
• Clear errors for gateway/CID failures.

References

• Ecosystem: OCI distribution over IPFS (e.g. nerdctl IPFS documentation, IPDR) — Phala can define the supported subset for production.

Context (optional)

Consumers want IPFS pinning + public gateway as the distribution layer; Phala-side support is required for ipfs:// (or equivalent) to be more than a manual “import to registry first” step.