IPFS (nerdctl run /ipfs/QmfTVLXMG9TH7X523NytcXj35XtEDx4wgNWYepVumqpJZV)

[AkihiroSuda]

Stargz Snapshotter is going to support IPFS soon (containerd/stargz-snapshotter#496).
We have to decide how CLI will look like for nerdctl + IPFS.

Pull & Run

$ nerdctl pull /ipfs/QmfTVLXMG9TH7X523NytcXj35XtEDx4wgNWYepVumqpJZV
$ nerdctl pull /ipns/example.com/foo

ref: https://docs.ipfs.io/concepts/dnslink/

I think we can just assume that the image ref string is an IPFS multihash when the ref string starts with Qm
(EDIT: Only CID v0 always starts with Qm. CID v1 does not start with Qm https://docs.ipfs.io/concepts/content-addressing/#identifier-formats)

We should propose the same image ref syntax to Kubernetes too.

Push

???

imgcrypt

???

@ktock

[ktock]

I think we can do nerdctl push --to-ipfs <image ref> which stores the image ref to IPFS and returns the CID.
Maybe we can have --name-publish option for IPNS?

One thing should be noted is that nerdctl push will change the digest of the image because it need to do the following:

• push a blob to IPFS and get CID
• modify OCI descriptor to contain CID annotation

The proposed ipfs library contains a converter which performs the above.

[AkihiroSuda]

Maybe we should have a new command like nerdctl ipfs push to avoid complicating the CLI

[ktock]

SGTM

[AkihiroSuda]

Bikeshedding: the ref string should be /ipfs/<cid> or ipfs://<cidv1> ?

containerd/stargz-snapshotter#496 (comment)

(We should propose the same ref string convention to Kubernetes, too)

[ktock]

I think we can consider image ref and OCI Descriptor seperately.

• urls in OCI Descriptor needs to be ipfs://<cid> which is an URL. We need to construct content-addressable DAG using this so we only support ipfs scheme without paths.
• image ref is used by users to interact with images and doesn't need to be an URL so both of ip[f|n]s://<cidv1>/<path> and /ip[f|n]s/<cid>/<path> are fine to me. Maybe /ip[f|n]s/<cid>/<path> is better because it's compatible to ipfs cat so it's easier to debug when a user use both of runtimes and ipfs CLI.

[ktock]

@AkihiroSuda WDYT about introducing an optional scheme(<scheme>://) to the image ref?

• docker://: points to an image fetched from Docker/OCI registry.
  • e.g. docker://docker.io/library/busybox:latest
• ipfs://: points to an image on IPFS
  • e.g. ipfs://bafkreie7754qk7fl56ebauawdgfuqqa3kdd7sotvuhsm6wbz3qin6ssw3a

For the compatibility to the current refspec, if the image ref doesn't have the scheme, docker:// is the default value.

[AkihiroSuda]

Supporting ipfs://<case-insensitive-cid-v1> scheme is ok, but I'm on the fence for docker:// scheme.
We can revisit docker:// scheme later, probably when we propose the IPFS scheme support to Kubernetes.

[ktock]

@AkihiroSuda

I'll make a draft PR for push/pull in days.

How can we support IPFS in nerdctl build? (i.e. pulling base images from IPFS)
Though we need to modify BulidKit's resolver logic eventually, a possible workaround might be to fix nerdctl to pre-pull base images from IPFS before the build and import them to BuildKit via local cache importer.
(But how can nerdctl know base images needed for a build?)

[AkihiroSuda]

@AkihiroSuda

I'll make a draft PR for push/pull in days.

thx 👍

How can we support IPFS in nerdctl build? (i.e. pulling base images from IPFS) Though we need to modify BulidKit's resolver logic eventually, a possible workaround might be to fix nerdctl to pre-pull base images from IPFS before the build and import them to BuildKit via local cache importer. (But how can nerdctl know base images needed for a build?)

Can we just have a local OCI registry that proxies OCI Dist Spec requests to IPFS?

[ktock]

Can we just have a local OCI registry that proxies OCI Dist Spec requests to IPFS?

Maybe we can use IPDR (https://github.com/ipdr/ipdr) here.

[AkihiroSuda]

Implemented in #505 #525
Kudos @ktock