`dag get --localResolve` vs `dag resolve`

[daviddias]

@whyrusleeping learned today that you implemented the 'resolve within a single node' on a dag resolve call. I've implemented it under the dag get through an option --local-resolve, which is what I understood that we agreed after our chat at Ada's.

» ipfs dag --help
#...
  ipfs dag resolve <path>    - Resolve a path through an ipld node.
#... 

Do you want to have a separate command for that? What would be the primary reason for it?

[daviddias]

See for context, the notes I wrote at the time - https://github.com/ipfs/interface-ipfs-core/issues/81#issuecomment-277271941

[magik6k]

To update - go-ipfs now has ipfs dag resolve:

USAGE
  ipfs dag resolve <ref> - Resolve ipld block

SYNOPSIS
  ipfs dag resolve [--] <ref>

ARGUMENTS

  <ref> - The path to resolve

DESCRIPTION

  'ipfs dag resolve' fetches a dag node from ipfs, prints it's address and remaining path.

[daviddias]

@vmx ^^

[olizilla]

Without a ipfs dag resolve command, it's awkward to figure out the CID of the node that a given path resolves to. In the new webui redesign, we let the user navigate through links from a root CID. As they explore the graph, we want to show the user the current CID of the node they have drilled down to, or they might simply paste in a path that crosses multiple links. Right now we have to add a chunk of application logic to walk the path, and recursively find and traverse the the links to figure out the current CID for nested CBOR nodes, but in dag-pb land we get the multihash property as part of the response.

I'm not sure if it's an important use-case, for apps that aren't trying to be generic IPLD explorers, but I figured I'd mention as a dag resolve command that would traverse links is exactly what we needed there.

[vmx]

@olizilla The functionality of dag resolve should be there. But it shouldn't be it's own command, but rather dag get with a parameter --localResolve