getting the merkle proof with resolver.resolve

[wanderer]

It would be nice to be able to get the full merkle proof of a path using resolver.resolve (would be exposed in ipld resolver i suppose). ipld-graph-builder could use the proofs to build its state object.

[daviddias]

By Merkle Proof, you mean the hash of the path? I'm happy to add that, we just need to consider the two scenarios: a) when the path leads to an object; b) path leads to a value of the object.

The answer for a) is just returning the hash of that object, however, what should we do for b)? Return the hash of the whole object? Hash that value? Open to suggestions.

[wanderer]

Return the hash of the whole object?

yes, i think.
I'm going to walk through an example so i can get i straight in my brain :P
Lets say we have something like

{
  '/': {
    one : {
      {
        '/' : {
          'two' : {
            '/': {
               three: {
                 val: 'value i want',
                 somethingelse : {
                    '/' : <cid>
                  }
             }
          }
          'dontwant': {
             '/': <cid>
          }
        }
      }
    }
  }
}

and we want the proof for a given root for the path 'one/two/three/val'. The most compact form of the proof would be the json above. ipld-graph-builder generates these proofs by looking up the objects individual and replacing the '/' link with the object they resolve to. But it might make sense to do it at a low low level at of the stack so a node can send a single query and retrieve the entire proof.

But I don't see anywhere in the current stack that would allow you to retrieve such a proof. So a stepping stone would be for resolver.resolve to return an array of merkle nodes it traversed through to follow a given path. So in the above example it might return something like

[
  {'one' : {'/': <cid>}},
  {'two' : {'/': <cid>}, {'dontwant': {'cid': '/'}}}.
  {'three':  {val: 'value i want'}, {somethingelse : { '/' : <cid>}},
  {val: 'value i want'},
  'value i want'
]

[daviddias]

//cc @alanshaw & @olizilla who are exploring this with ipfs-inactive/interface-js-ipfs-core#125