[WIP] feat(dag): add IPLD to dag.get

[alanshaw]

This PR is a proposal to resolve #738 and will also fix #747.

In the dag.get function we create an temporary in-memory IPLD resolver with a custom bitswap exchange hooked up to the block.get API call.

This is kinda awesome!

I've not implemented all the methods for the exchange, but you don't need to because it only uses get.

I created a utility module for extracting the CID and path from the cid arg...the spec for dag.get is flexible in that you can pass it a Qmhash, or a Qmhash/with/path or a CID instance but the IPLD module isn't as flexible and they need to be split into two args: CID(Qmhash) and /with/path.

I've also added explain-error because it's really good at adding context to error messages whilst also retaining the original error & stack. It also means that in tests we can assert on error messages that are generated within this module rather than (possibly) randomly changing messages from dependencies.

---

~~BLOCKED~~

This is currently a breaking change to the way dag-pb nodes are traversed via path.

In go-ipfs you can do this:

ipfs dag get /ipfs/QmWgCbdDVhsXA8UzpaQwFgw71iGaLrAfyyy51XWpHzNu8C/gif

but with this pull request, to get the same object, you'd need to:

jsipfs dag get /ipfs/QmWgCbdDVhsXA8UzpaQwFgw71iGaLrAfyyy51XWpHzNu8C/Links/gif

Note "Links".

[magik6k]

Note that go-ipfs intends to add /ipld namespace which will behave the same way as /ipfs does here. See https://github.com/ipfs/go-ipfs/pull/4672.

I'd also use ipfs dag relolve to resolve the path on the daemon side to limit api cals.

[alanshaw]

@magik6k thanks for looking at this!

I'd love to use dag.resolve but js-ipfs daemon doesn't have it. Is dag.resolve going away in go-ipfs or is it worth implementing it in js-ipfs and adding it to the spec?

[daviddias]

dag.resolve should not exist as it stands per all the conversations I, @whyrusleeping and @jbenet had in the past, both in person and async. It has been almost 2 years since the work on this API started, not worth going through all the data points, the tl;dr; is that there wasn't the opportunity to commit to an API for both implementations.

I took a lot of notes along the way here, find them at:

• https://github.com/ipfs/interface-ipfs-core/issues/81
• https://github.com/ipfs/interface-ipfs-core/issues/121
• https://github.com/ipfs/interface-ipfs-core/issues/125

My suggestion is for everyone to get a revisited dag API and implement it for both implementations that respects all the constraints (i.e. we can't just use JSON serialization for responses over HTTP as it messes up with types).

[alanshaw]

unblocked thanks to https://github.com/ipld/js-ipld-dag-pb/pull/78