config

[daviddias]

To learn more about config, you can

• try out the ipfs config command with a go-ipfs daemon
• check the config http-api-spec Added Group config ipfs-inactive/http-api-spec#29

Implementation Roadmap

• jsipfs config - Gets or sets the value of a given key of the config file.
  • core
  • http-api (Add /api/v0/config endpoint #72)
  • cli
• jsipfs config show - Outputs the content of the config file.
  • core
  • http-api (Add /api/v0/config/show endpoint #74)
  • cli
• jsipfs config edit - Opens the config file for editing in $EDITOR.
  • cli (Add ipfs config edit to cli #77)
• jsipfs config replace - Replaces the config with .
  • core
  • http-api (Add /api/v0/config/replace endpoint #75)
  • cli

[daviddias]

config http-api spec - ipfs-inactive/http-api-spec#29

[RichardLitt]

Let me know if the spec needs updating.

[daviddias]

updated this issue

[fbaiodias]

@diasdavid I was looking into jsipfs config edit but couldn't find any way of accessing the repo's config file path.
Should we expose it on js-ipfs-repo or did I miss something?

[daviddias]

@xicombd note that the jsipfs cli might be working through the network, so essentially the way to do it is to fetch the config, open it on a editor and when on save, write it back.

[fbaiodias]

Ahhh, makes sense. Thanks for the clarification!

[fbaiodias]

I'm implementing the /config/replace api endpoint, but although it works fine with the spec's curl example, and the hapi tests, I'm not being able to use it with js-ipfs-api.

I'm calling it like this (see the test):

const file = 'tests/otherconfig'
ctl.config.replace(file, (err, res) => {
  console.log(err, res)
})

And hapi is replying with:

 { statusCode: 400, error: 'Bad Request', message: 'Invalid multipart payload format' }

@diasdavid @dignifiedquire do you have any idea how to make this support js-ipfs-api? Or should we change js-ipfs-api instead, and send the files in another way?

Thanks!

[daviddias]

"multipart strikes again™"

@xicombd good catch, we certainly need to document that, the reality is that go-ipfs uses a custom made Multipart message format which hapijs is rejecting since it expects something with the format of the spec. This might require some hackery in order to get the same Multipart parser that we have in Go.

A way to get this done is

• 1. capture a multipart message for file and one for a dir created by go-ipfs cli or js-ipfs-api
• 2. built the same custom js parser for that custom multipart message, as we have in go-ipfs (https://github.com/ipfs/go-ipfs/tree/master/commands)
• 3. integrate it with hapijs

[daviddias]

https://public.etherpad-mozilla.org/p/multipart-madness

js-ipfs hacking

const multipart = require('ipfs-multipart')

server.route({
     method: ‘POST’
     path: '/files/add'
handler: (req, res) => {
     req.pipe(multipart.parser)
          .on(‘file’, (filename, filestream) => {
          // filename is the entire filepath
                }) 
                .on(‘err’, (err) => {

                 })
 }
})

TODO

• fork hapi and add option to skip the payload read/parse for a route for a given route
• make PEZ understand our multipart messages

NOTES

Hapi passes the request.raw.req here https://github.com/hapijs/subtext/blob/master/lib/index.js#L296 to subtext, that pipes it to pez here: https://github.com/hapijs/subtext/blob/master/lib/index.js#L429

[fbaiodias]

Started implementing a multipart parser for ipfs here: https://github.com/xicombd/ipfs-multipart