JS API: ipfs.dag vs ipfs.object

This question probably stems from tons of confusion, so thanks for your understanding.

As far as I understand, ipfs.dag (aka IPLD?) is newer, more flexible and preferred to ipfs.object. But on the other hand, ipfs.object enables one to create a directory structure, similar to MFS, but for arbitrary data (vs files), eg one can add/delete links to an existing object, and a new cid is generated.

That behaviour is quite useful to track a bunch of nodes under one directory, for example app state, user data, …etc.

My question is, how can one accomplish that MFS-like behaviour on top the newer ipfs.dag API? Or shall I just stick to ipfs.object in that case?

Additionally, I wonder why there’s no IPFS DAG API in the Go interface, and whether it has a different name iface - GoDoc

Thanks!

  • ipfs.dag -> works on IPLD layer. Reads, writes nodes of arbitrary IPLD types (usually using cbor serialization, which converts directly from json). A DAG in this layer is just a bunch of nodes (whathever their types), with links. It does not interpret anything else.
  • ipfs.object -> works with IPLD nodes of type merkledag-pb, which are serialized with protobuf and have Links and Data fields, specifically. Allows to perform manipulations on this type of node like adding links.
  • ipfs.files -> works with IPLD nodes of type merkledag-pb which carry unixfs data payload. Such payload can tell whether the node is a directory or a file etc.

You need to choose the API that fits the level on which you want to work. Is it possible to work with unixfs nodes from ipld.dag ? Yes, potentially. But also probably more tedious than using ipfs.object or ipfs.files.

2 Likes

An issue to consider is most pinning services don’t support DAGs, so it can be difficult to distribute and persist them.

Also, they are not sharded when created, so any over ~1MiB will have difficulty being distributed through the backend.

1 Like