Auto-mounting CID for Local Content

[wesfloyd]

ETA: 2023Q2

Feature request: when we dropped the local flag, we hashed the local content, saw if the content was available on IPFS and if it was, auto mounted the CID. If it wasn't, we uploaded it.

Per this conversation in the LabDAO integration grant planning doc:

It'd be amazing if when we dropped the local flag, we hashed the local content, saw if the content was available on IPFS and if it was, auto mounted the CID. If it wasn't, we uploaded it.
Can you add this as a bug and tag Phil/Luke/Enrico?

[wesfloyd]

@philwinder @lukemarsden @enricorotundo for FYI

(@aronchick apologies for opening this bug a bit late!)

[aronchick]

No objection here to the functionality, but I think the auto mounting should be its own verb

[enricorotundo]

Taking one step back here 🤔. Is the final goal saving user's time by sparing them the ipfs add step (e.g. cid=$(ipfs add --quiet ./testdata/grep_file.txt))?
If that's the case, why restrict this to local mode only?

We could extend --input-volumes CID:path to support <local-path>:path and auto-upload the local content automatically. This'll probably cause problems because classifying /ipfs/<CID>/path as CID and /foo/bar/ as local path is problematic (ipfs/go-path#54).

Another option is adding a new verb (e.g. --input-path <local-path>:path).

[aronchick]

Man i like this one a lot :) @enricorotundo

[simonwo]

The plan for the inline storage feature was definitely to enable exactly this -- allow users to specify a local directory and have it included in the job. See #1628

[simonwo]

In progress at #1765.

[aronchick]

@simonwo did this get finished?

[simonwo]

We never did #1765, which is still the MVP answer to this issue.

[wdbaruni]

seems finished to me