Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

feat: import/export a DAG from/to a CAR file #2745

Closed
mikeal opened this issue Feb 5, 2020 · 9 comments · Fixed by #3728
Closed

feat: import/export a DAG from/to a CAR file #2745

mikeal opened this issue Feb 5, 2020 · 9 comments · Fixed by #3728
Assignees
Labels
P1 High: Likely tackled by core team if no one steps up

Comments

@mikeal
Copy link
Contributor

mikeal commented Feb 5, 2020

Across IPLD and Filecoin we’re starting to really zero in on CAR files being the preferred import/export format for DAGs.

It would be great if IPFS had an easy way to export the full graph for any CID to a CAR file and to load a CAR file’s blocks into its local blockstore.

It’s not very hard. I was able to write a proof of concept in less than an hour for the exporter https://github.com/mikeal/export-ipld-graph

@achingbrain
Copy link
Member

achingbrain commented Feb 5, 2020

This might be better as a separate command? Given its size it'd be better not to add more things to IPFS.

$ cat ./path-to-input.car | read-car | ipfs add
$ ipfs get $CID | write-car > ./path-to-output.car

In the API a carSource module similar to globSource or urlSource could be created?

for await (const entry of ipfs.add(carSource(stream))) {
  console.log(entry)
}

Then for outputting, use something like:

await pipe(
  ipfs.get(carCid),
  carWriter(),
  fileWriter('/path/to/output.car')
)

@mikeal
Copy link
Contributor Author

mikeal commented Feb 5, 2020

The car file contains all the blocks for the entire graph, so you have to traverse through all of the links and it’s not quite as simple as this. It could possibly still be a separate command but you’d need to output in a multi-part structure that distinguishes the blocks, which is basically a car file.

The car file library shouldn’t be too large, the POC for export may look large because the default codecs and hash functions used in the new Block API, but js-ipfs wouldn’t need to use that and already includes relevant codecs and hashing functions.

@rvagg
Copy link
Member

rvagg commented Mar 26, 2020

proposal / WIP @ #2953 to match what go-ipfs is getting

@ribasushi
Copy link

Just a poke on this issue: what we are shipping in go-ipfs 0.5 is the final version. It is missing only:

The test fixture and the tests themselves are complete.

/cc @achingbrain @mikeal

@mikeal
Copy link
Contributor Author

mikeal commented Jun 29, 2020

Kicking this again because it’s actually very important.

This needs to ship in js-ipfs because it covers a pretty important compatibility story between IPFS and Filecoin. We’ve made more improvements to the JS library for the CAR format and we can put some more time into this PR if we can get some indication that it might be accepted.

@lidel
Copy link
Member

lidel commented May 4, 2021

I'm adding this to stewards maintenance backlog.
We need to add support for ipfs.dag.export|import to match go-ipfs implementation, but even bigger need is for js-ipfs-http-client, to work with /api/v0/dag/export|import to enable thin client setups and unblock reliable DAG backups for collabs like Pinata (cc @obo20).

@obo20
Copy link
Contributor

obo20 commented May 4, 2021

Just to be clear, this isn't an immediate blocker for us. We found some workarounds that are enabling us to directly hit the CLI from nodeJS and make things work that way.

From an ease of use standpoint, having ipfs.dag.export available as a GET request on the gateway endpoint would probably be more useful immediately.

@rvagg
Copy link
Member

rvagg commented May 5, 2021

#2953 uses an outdated stack, which will need to be updated to remove @ipld/block and swap datastore-car for @ipld/car. The work that's landing now, along with @achingbrain's https://github.com/ipld/js-blockcodec-to-ipld-format, makes it easier to bridge the two worlds so it should be a bit more straightforward to implement. IIRC there was a challenge around test cases, mirroring the go-ipfs impl and locking in correctness is difficult without being able to use sharness.

For the http-api, they're basically streaming operations, agnostic of the data (i.e. it's just Uint8Arrays, even if they contain CAR data), so it's roughly just a matter of copying something like the /add pattern (but simpler) for writes and /cat for reads, isn't it?

@rvagg
Copy link
Member

rvagg commented Jun 18, 2021

Since this is on the JS maintenance board and I'm on the roster next week, this could be something in my wheelhouse to chew in to, since #2953 is most of the way there. But it seems like the priority of this in js-ipfs itself is questionable compared to other work so I'll defer to stewards. We have CAR export from the gateway now, which takes the load off I imagine.

@lidel lidel added the P1 High: Likely tackled by core team if no one steps up label Jun 18, 2021
achingbrain added a commit that referenced this issue Jul 27, 2021
Adds `ipfs.dag.import` and `ipfs.dag.export` commands to import/export CAR files,
e.g. single-file archives that contain blocks and root CIDs.

Supersedes #2953
Fixes #2745

Co-authored-by: achingbrain <[email protected]>
SgtPooki referenced this issue in ipfs/js-kubo-rpc-client Aug 18, 2022
Adds `ipfs.dag.import` and `ipfs.dag.export` commands to import/export CAR files,
e.g. single-file archives that contain blocks and root CIDs.

Supersedes #2953
Fixes #2745

Co-authored-by: achingbrain <[email protected]>
@tinytb tinytb moved this to Done in IP JS (PL EngRes) v2 Oct 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
Archived in project
6 participants