How to get resolved IPLD structure

[Tails]

I've read through all dag examples and tests but could not find the case I'm looking for, but probably I'm overlooking something, so just read this as request for clarification! :)

I have a relatively large JSON structure (± 15-50MB) with a lot of internal redundancy (sheet music data). I deduplicate the structure by creating an IPLD where objects are referred to using CID links (Link(Cid)).

Is there a command like IpldDag::resolve that resolves a Cid to the nested structure where Cid links are replaced with the referenced List and Map structures?

    // deduplicated linked ipld structure that is persisted
    deduplicated = Ipld::List(vec!( Ipld::Link(cid1), .. ))
    ...
    // redundant-full resolved structure that is read
    resolved = Ipld::List(vec!( Ipld::Map(..), .. ))

Much appreciated!

[koivunej]

This sounds like an interesting usecase! Looking at v0/dag/resolve I was first thinking we would have a part of this implemented, however the implementation might not be at the level of the clients. As the clients used to do the projection in ipfs dag get <path> by invoking dag/resolve http endpoint followed by a block/get, client deserialization and path following. We haven't updated the interface/conformance tests in a while, so not sure what is the today's case for the APIs.

However looking at ipfs.dag().resolve(...) and especially the returned ResolvedNode::Projection, I would expect you to be able to get the projected document or the json fragment in the dom-alike representation we currently support. I think in your case, you might also end up with resolving to directly a block, in which case it wasn't deserialized if no more resolving was needed.

To explain the "lazy deserialization" a bit more; I recall that the HTTP API didn't require any projected document to be returned for dag/resolve endpoint, so it's more than likely that deserialization would had been skipped if possible at the lower ipfs levels as we were developing this targeting mostly the HTTP API tests.

Would like to remind you that the usual caveats in our README still apply; we haven't been able to work on this for a while so it's in a less than ideal level. However I hope the implementation at least will be understandable!