Support for /dag endpoints

[aphelionz]

References:

• https://github.com/ipfs/js-ipfs/tree/master/packages/interface-ipfs-core/src/dag
• https://docs-beta.ipfs.io/reference/http/api
• https://github.com/ipfs/interop (no occurrences)

/dag/get

Get a dag node from ipfs.
http://localhost:5001/api/v0/dag/get?arg=<ref>

• Requires dag.put
• Red Flag: ipfs.add required here, will likely need to refactor tests
• can get a dag-pb and dag-cbor node
  • with paths and local values
• Arguments
  • arg [string]: The object to get Required: yes.
• On success, the call to this endpoint will return with 200 and a plain/text body

/dag/put

Add a dag node to ipfs.
curl -F file=@myfile "http://localhost:5001/api/v0/dag/put?format=cbor&input-enc=json&pin=<value>&hash=<value>"

• 2 hash functions: sha2-256 and sha3-512
• can be called without options, no failure
• This test is curious, it seems like there may be more going on but perhaps not...
• Arguments
  • arg [file]: The object to put Required: yes.
  • format [string]: Format that the object will be added as. Default: "cbor". Required: no.
  • input-enc [string]: Format that the input object will be. Default: "json". Required: no.
  • pin [bool]: Pin this object when adding. Required: no.
  • hash [string]: Hash function to use. Default: . Required: no.
• Request Body Argument "object data" is of file type. This endpoint expects a file in the body of the request as 'multipart/form-data'.
• On success, the call to this endpoint will return with 200 and the following body:

{
  "Cid": {
    "/": "<cid-string>"
  }
}
```

[aphelionz]

@hugomrdias @vmx What is the story with dag.tree and /dag/resolve? I'm getting mixed messages from the interface tests and from the HTTP API docs

[vmx]

@aphelionz tree and resolve is likely incompatible between the JS and Go implementation. I suggest to do whatever the interop tests are doing.

[aphelionz]

@vmx Should we create an HTTP endpoint /dag/tree?

[vmx]

Should we create an HTTP endpoint /dag/tree?

@aphelionz yes please, as there are tests for it in https://github.com/ipfs/js-ipfs/tree/master/packages/interface-ipfs-core.

[hugomrdias]

@aphelionz sorry for not getting to this sooner.
For now you should NOT implement tree, in the future follow http-client and not specifically interface-core. I mean look into this file as a reference and guide to what is currently being tested https://github.com/ipfs/js-ipfs/blob/38283bdafe16a947ec095d7a41a350e033a97102/packages/ipfs-http-client/test/interface.spec.js#L96

Please ping me aggressively if i don't reply fast enough.

[aphelionz]

Thanks @hugomrdias, roger all that

[vmx]

@aphelionz for future discussions. If @hugomrdias and I say opposing things, the last one is the one that counts (we will make sure that we are in sync and update again if needed).

[aphelionz]

Will do, thanks @vmx

[aphelionz]

Same question as #92 (comment) for ipfs.add in these tests as well

[aphelionz]

dag.put was satisfied by #137 with one exception:

18. should override hash algorithm default and resolve with it

[koivunej]

Minor test fix: ipfs/js-ipfs#2987

This will get us passing all but the dag.get should get only a CID, due to resolving locally only. I don't see why that localResolve: true is not passed over http, but gets handled with native js-ipfs. This would be an easy PR as well.. Let's try.

EDIT: Nope, it has been already implemented. I'll start trying to wrap up a custom version of js-ipfs under ipfs-rust org for so that we can have a nice checkout of ipfs-rust/ipfs-rust-conformance repo which will just pass all of the tests..