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

[olizilla]

Just to check we're on the same page, right now, the go-ipfs ipfs dag resolve recursively resolves links in a path and returns the CID of the last node your path leads to:

$ ipfs --version
ipfs version 0.4.14

$ echo '{ "a": { "/": "QmYPNmahJAvkMTU6tDx5zvhEkoLzEFeTDz6azDCSNqzKkW"}}' | ipfs dag put 
zdpuAyzU5ahAKr5YV24J5TqrDX8PhzHLMkxx69oVzkBDWHnjq

$ echo '{ "b": { "/": "zdpuAyzU5ahAKr5YV24J5TqrDX8PhzHLMkxx69oVzkBDWHnjq"}}' | ipfs dag put
zdpuAqxFu5LVTF8kELqUMBCp3K4fc2yERX5fRM5KZJ95j21rV

$ ipfs dag resolve zdpuAqxFu5LVTF8kELqUMBCp3K4fc2yERX5fRM5KZJ95j21rV/b
zdpuAyzU5ahAKr5YV24J5TqrDX8PhzHLMkxx69oVzkBDWHnjq

$ ipfs dag resolve zdpuAqxFu5LVTF8kELqUMBCp3K4fc2yERX5fRM5KZJ95j21rV/b/a
QmYPNmahJAvkMTU6tDx5zvhEkoLzEFeTDz6azDCSNqzKkW

$ ipfs dag resolve zdpuAqxFu5LVTF8kELqUMBCp3K4fc2yERX5fRM5KZJ95j21rV/b/a/css
QmRNaib6Pz2PUVLpEbMkEdETu5cup77Dtkief58o4NRPaM

It sounds like localResolve isn't intended to do that. The behaviour of the current ipfs dag resolve command would be useful for the IPLD explorer.

[alanshaw]

It would also reduce the number of block.get calls js-ipfs-api would have to do when using dag.get with IPLD. If we could use dag.resolve get hold of the closest CID then IPLD would only have to walk the remainder client side.

Relevant: ipfs-inactive/js-ipfs-http-client#755 (comment)

[olizilla]

Talking to @alanshaw, it would be useful to add a canonicalAddress property to the object returned by dag get that provides the simplest address for the value that was found, with just the CID for the containing node and remainder path to that value within the node. As an example:

echo '{ "c": 9 }' | ipfs dag put 
z2

echo '{ "a": { "b": { "/": "z2" }}}' | ipfs dag put 
z1

ipfs dag get "z1/a/b/c"
{value: 9, remainderPath: "", canonicalAddress: "z2/c" }

With the canonical path we get the CID for the node that contains the value and can unpack the mulitcodec to figure out how we should (de)serialize the value. Optionally, the http apis could add headers that repeat the multicodec value for the containing node to save some work.

That would give us the value of a dag resolve without an extra command, and could help solve some of the serialisation ambiguity.

[vmx]

@olizilla The canoncialAddress sounds really useful. But I don't like the name. It might be a non-native speaker thing, but I don't find it intuitive. In my mind a canonical address is e.g.: /a/b/../c => '/a/c. Some ideas for a different name: directPath, shortestPath, closestPath, nodeLocalPath, localPath.