DAG API

[daviddias]

Ref: ipfs-inactive/interface-js-ipfs-core#123

» ipfs dag put --help
#...
  -f,        --format string - Format that the object will be added as. Default: cbor.
  --input-enc         string - Format that the input object will be. Default: json.
#...

As discussed previously:

• format should take in the names of the formats (dag-cbor, dag-pb, eth-block, etc)
• There should be an option for hashAlg
• The endpoint needs to reply with a header that specifies the encoding of the output. A sane default would be cbor all the way and/or have an option for --output-enc too.

Related question:

• Can we get listed on the --input-enc, the actual supported encoding options available?

For context: https://github.com/ipfs/interface-ipfs-core/issues/81#issuecomment-277271941

[daviddias]

Getting an error when sending a protobuf (serialized in protobuf and sent with --input-enc=protobuf)

  1) .dag callback API .put dag-pb with default hash func (sha2-256):
     Error: protobuf handling in 'dag' command not yet implemented

[whyrusleeping]

re: your comment, that one seems pretty obvious. We havent implemented protobuf support in the dag put
api yet

[daviddias]

@whyrusleeping understood. The message that I was trying to convey is that I was expecting it to be there and that I'm interested for it to be there :)

Supporting protobuf and cbor as --input-enc will enable js-ipfs-api to send the dagNodes correctly without loosing information in the 'Stringification' of JSON. Needed for ipfs-inactive/js-ipfs-http-client#534

[daviddias]

@whyrusleeping I'm blocked on this one, do you have a time estimate for when you will be able to look into this?

[whyrusleeping]

@diasdavid Outline exactly the features you need, and the acceptance cases for it being 'correct'.

I've been really pressed for time lately so if you can do some of that footwork for me, it will help me out a lot

[daviddias]

Ok :)

So I need:

• The format flag needs to expect the multicodec name for the format (dag-cbor, dag-pb, and so on)
• There should be a flag for --hash-alg, so that we can specify the hash function to be used
• --input-enc needs to also have as options: 'protobuf' and 'cbor' (for now)
• The answer through the http-api should provide information (as we talked, better be through an http header) of what is the encoded format in which the data is coming, same as application/json, but for protobuf or cbor`
• Add an option to --output-enc, so that we can select the serialization format before hand.

This is it :)

[joelburget]

I'm looking at doing this (at least the output format option mentioned in the Haskell discussion), but realized I have a few questions that @diasdavid or @whyrusleeping might be able to answer.

What should my flag be called? --fmt for consistency with ipfs object cat --fmt? Is that the right naming convention? Would that be the same as --output-enc mentioned above? I was picturing passing this flag to ipfs dag get, since AFAIK all these objects will be stored as cbor unless otherwise specified, but your wording makes me thing you intended --output-enc to be passed to dag put, which I don't understand.

Where would you place the decoding? The first place I look is obviously DagGetCmd.Run, where I could perhaps MarshalJSON the node, but I must be missing how to convert to something like yaml.

[magik6k]

reopening as it's not yet fully done

[magik6k]

I have some work regarding this already done (using cbor instead of json to communicate with API), but I'll probably wait with this until ipfs/go-ipld-format#23 happens.

[kevina]

@diasdavid Why --hash-alg and not hash-fun the term is generally "hash function" not "hash algorithm"

[daviddias]

@kevina no really strong reason tbh