Added Group config

[RichardLitt]

Some issues:

• I was unable to get the second argument working, so it is currently not documented how to patch a config entry. I also was unable to meaningfully get bool and json flags working. Wireshark says that encoding=json is added to each command normally run by the CLI, as well as stream-channels=true, but neither of these are mentioned in the CLI mans, which is odd. I'm not sure what they are doing.
• 'ipfs config edit' opens up a second terminal window - over the running daemon - when requested using curl on the commandline, so I'm not actually sure what that should be doing in the API. I had it originally set as content-type buffer in the request, too, but I'm not sure where I got that; probably Postman. It wasn't shown in Wireshark.
• Some of the commands returned no body in the CLI when curled, but returned malformed JSON in Wireshark. Not sure what to make of that.

[RichardLitt]

I got the arguments working by putting the HTML request into double quotes. D'oh!

[RichardLitt]

Ok, now I am simply unable to get bool working. Strangely enough, this works:

curl -i "http://localhost:5001/api/v0/config?arg=Datastore.Path&arg=\"false\"&json"

Also weirdly, so does this:

curl -i "http://localhost:5001/api/v0/config/Datastore.Path"

I've added that second one to it's own section.

[daviddias]

'ipfs config edit' opens up a second terminal window - over the running daemon - when requested using curl on the commandline, so I'm not actually sure what that should be doing in the API

Yeah, that is kind if a cli thing around the ipfs config show and replace (or at least I would expect for it to be that way :) )

Some of the commands returned no body in the CLI when curled, but returned malformed JSON in Wireshark. Not sure what to make of that.

This is probably an API error and the CLI is smart enough to compensate. Consider opening it as a bug in go-ipfs.

[daviddias]

Add a note here saying that it can be any key of the config entry and that Datastore.Path is just an example of one

[RichardLitt]

No. That's apiary format for an example; it is clear by the syntax that this is not the only possible option.

[RichardLitt]

@diasdavid Updated to fix all of the POST and GET stuff. Also some small syntax fixes.

[RichardLitt]

Needs to be checked before #20 can be closed.

[dignifiedquire]

default value?

[RichardLitt]

ipfs/kubo#2412

[daviddias]

Wireshark says that encoding=json is added to each command normally run by the CLI, as well as stream-channels=true, but neither of these are mentioned in the CLI mans, which is odd. I'm not sure what they are doing.

I think these are just default. //cc @whyrusleeping

@RichardLitt Other than the last comment above, it seems this PR was reviewed twice, could you post a item list with things you would still like feedback?

[fbaiodias]

Isn't this optional? See https://github.com/ipfs/http-api-spec/blob/feature/config/apiary.apib#L1038

[RichardLitt]

Yes. Good catch.

[RichardLitt]

I need review or to do:

• Merge Added defaults to config opts descriptions ipfs/kubo#2412, add defaults.
• Make it clear whether replace needs to be a path or the file itself. I think the latter, but I am not sure. @whyrusleeping?
• Should ipfs config edit be included at all? Or should we remove it? What happens if I call in my browser?
• Open issue about API-wide issues: Method variability, encoding-json and stream-channels=true, malformed JSON responses

[RichardLitt]

File and path are synonymous,

[RichardLitt]

@diasdavid Should ipfs config edit be included at all? Or should we remove it? What happens if I call in my browser?

[daviddias]

that encoding=json is added to each command normally run by the CLI, as well as stream-channels=true, but neither of these are mentioned in the CLI mans, which is odd. I'm not sure what they are doing.

They are just default for every command, probably at some point in time there was other options, now it is always the same.

'ipfs config edit' opens up a second terminal window - over the running daemon - when requested using curl on the commandline, so I'm not actually sure what that should be doing in the API. I had it originally set as content-type buffer in the request, too, but I'm not sure where I got that; probably Postman. It wasn't shown in Wireshark.

ipfs config edit is almost a convenience on top of show+replace, it is a cli only thing. The only reason why I see it that way is because the way the http-api is done in go-ipfs, it globs any command that is available on core/commands, even if it is not supposed to be an http-api thing.

Should ipfs config edit be included at all? Or should we remove it? What happens if I call in my browser?

I vote to remove it

Some of the commands returned no body in the CLI when curled, but returned malformed JSON in Wireshark. Not sure what to make of that.

Better go one by one and see each case.

[RichardLitt]

I removed edit. Ignoring the global flags, for now. Same for the Wireshark responses; I think that's probably me misreading wireshark.