Update `files.add` return format to match js-ipfs-api

[hackergrrl]

The current result format in js-ipfs core is

{
  path: 'the original path',
  size: (# of bytes of the data),
  dataSize: (moar!)
  multihash: (a Buffer of the data multihash)
}

as dictated by unixfs-engine. This is different from what the HTTP API returns, which is a lot less information:

{
  Name: 'some name',
  Hash: 'QmRNjDeKStKGTQXnJ2NFqeQ9oW23WcpbmvCVrpDHgDg3T6'
}

To make interface-ipfs-core consistent, I propose we either

1. Modify unixfs-engine to return objects of the latter format, or
2. Modify js-ipfs to massage its results from unixfs-engine into the latter format

I prefer (2) personally, since it means other modules can still use unixfs-engine to get a fuller set of data from whatever is imported.

---

ping @diasdavid @nginnever

[dignifiedquire]

moaar data, agree limiting can happen at the end but unixfs-engine should provide the data

[nginnever]

I prefer 2 as well.

The HTTP-API resource and the files/add.js cli can handle formatting as they are

[daviddias]

I propose option number 3

• 3 Do object.get requests on js-ipfs-api so that js-ipfs-api provides the same information as js-ipfs.

Note1: We already do this in some methods os js-ipfs-api.
Note2: We should not be limited by the constraints of the http-api

[hackergrrl]

@diasdavid To what end? Are there existing use cases where we want/need the extra information? I'm strongly for a core that makes as few promises to the outside world as possible -- it'll already surely grow with time, so we should consider exposing only what we need. I think until we have some concrete need for (3), (2) is the way to go, since it grants us the baseline exposed properies (name, hash).

[daviddias]

This is all good with the refined files API https://github.com/ipfs/interface-ipfs-core/tree/master/API/files \o/