Currently, we're playing it fast-and-loose with DagPB path resolution. For context, the structure of DagPB IPLD objects is currently defined to be:

{
  "Data": "binary data",
  "Links": [
      {
        "Name": "thing", // may not be unique, may be omitted
        "Tsize": 1234, // may be omitted
        "Hash": "QmId"
      }
  ]
}

Given this structure, the correct path to QmId would be /Links/0/Hash. However, this isn't very usable.

• js-ipfs actually supports this pathing scheme. However, it also supports pathing by name (/Links/thing/Hash). While nice and usable, this is technically transforming the object.

• go-ipfs uses the pathing scheme /thing. That is, it treats the object as if it were a single map of names to CIDs (for the purposes of pathing). This is obviously problematic from an IPLD standpoint as many of the fields aren't addressable.

So, we need a scheme that's both consistent between implementations and consistent with other IPLD formats.

Given that we're basically the only real consumer of this format, I believe we have a bit of flexibility.

By the way, @diasdavid, your code organization is 💯. ^{(despite the fact that you're using JavaScript)}