Improving init (aka, how do I get a js-ipfs node instance!)

[daviddias]

There has been a lot of feedback when it comes to the API for creating an IPFS node instance, some feedback from myself included. It is true, the process is a bit cumbersome, instead of having something beautiful as

// # Option 1
const options = {
  init: true
  online: true
}
const node = new IPFS(options)

We have:

const repo = <IPFS Repo instance or repo path>
const ipfs = new IPFS(repo)
ipfs.init({ emptyRepo: true, bits: 512 }, (err) => {
   if (err) { throw err }
   ipfs.load((err) => {
     if (err) { throw err }
     ipfs.goOnline((err) => {
       if (err) { throw err }
       // finally something you can work with!
   })
})

Yes, it is not nice, but why is it this way right now? Why can't it be sync, well for some reasons:

• init needs to get the repo started if it doesn't exist, since IPFS Repo use pull-blob-store adapters and these are async (because a Repo can be a network storage), this call needs to be async
• load is when we take a repo and load all the config values. This also can't be sync because we only store the Private Key on the config and the generation of the PublicKey needs to be async (Thanks WebCrypto! see more at: Awesome Async Crypto + Less magic to 'run in the browser' #485))
• goOnline this is where we turn on bitswap, it means that we are ready to fetch and serve blocks from and to other nodes.

This can be way more nicer, however, starting from documentation of this methods, examples and explaining what the functions are doing inside the readme.

Another thing to consider is making the IPFS instance an event emitter with a 'ready' event, so that Option 1 can be achieved by loading everything as options and emitting a ready event.

Other things to consider

• It would be sweet if the options passed to init or to new IPFS(options) would also accept values to overload the config with. Right now we always create the repo and then use the config API, it works but this option would reduce the steps, making code easier to read.
• goOnline should be bitswap.on and bitswap.off, as we will need soon to be able to enable and disable things like the dht.

I would love to hear everyone's thoughts on this, I might be missing something that might get us to a even nicer start process, looking forward for feedback :) Thank you!

[dignifiedquire]

I have seen apis where it is done in this way:

const ipfs = new IPFS(options)

ipfs.on('ready', () => {
  // We are ready to do things
})

ipfs.on('error', (err) => {
  console.error('failed to start', err)
})

These event listeners could also be attached through options for convenience similar to nodes http server

const ipfs = new IPFS(options, () => {
  console.log('WE ARE READY')
})

[daviddias]

exactly @dignifiedquire, that goes along the lines of what I was thinking with Option 1 + ready event, it feels like something familiar (like a TCP listener or a HTTP server in Node.js).

[haadcode]

👍 for the events pattern. This would allow us to have more granular events to the state if needed, like connected etc. Another plus side is that if we do this, we can have the same API for js-ipfsd-ctl (which I wrapped in ipfs-daemon module) and allows to converge the native vs. browser "give me daemon" libs, and use the "browser" field in package.json to decide separate the two.

I really like this direction!

[daviddias]

Oh nice @haadcode! I was not even thinking that we could do that too. I'm getting even more excited :D

[RichardLitt]

This can be way more nicer, however, starting from documentation of this methods, examples and explaining what the functions are doing inside the readme.

For the README, the rule of don't use too many inline comments because it messes up how easy it is to work on the code doesn't apply. It might be a good idea to have some of the comments you have above inlined in the code example; that way, people can look at the internal functions and understand what each step is doing.