JS API: ipfs.dag vs ipfs.object

Help
,
1

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!

2
  • 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
3

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