🚀 0.23 Release 🌟

[daviddias]

We are getting ready to launch the 0.23 release of js-ipfs, which will be one of my all time favorites! This release comes timely after go-ipfs 0.4.7 as it marks the start of full interop, that is right, no more stream-muxing issues

Highlights

✨ A new way API is born, welcome to .dag

The new DAG API (available through ipfs.dag) offers a new way to create and operate over any MerkleGraph, today it has support for the IPFS MerkleDAG (referenced as dag-cbor), the new dag-cbor (which lets you drop json into IPFS seamlessly) and a preview of Ethereum.

You can learn how to use it through:

• docs
• examples
• video running through the demos

If you are new to the Merkle Forest, make sure to watch @jbenet's talk "Enter the Merkle Forest"

🙌🏽 Interoperability with go-ipfs is here!

This took us more time than what we had initially expected, however, now it is a thing of the past, you can dial to a go-ipfs node and exchange files without going through complicated set ups, it just works™

If you would like to know more about the issue we faced, you can find more info here: "Stream Muxing issues between go-ipfs and js-ipfs are a thing of the past"

Note: Interop is only fully available with go-ipfs 0.4.7 and onwards, if you haven't updated yet, please do so by visiting http://dist.ipfs.io/.

🌍 js-ipfs will now also bootstrap with bootstrap nodes as well

Same way that go-ipfs does, now your jsipfs daemon will bootstrap itself with the bootstraper nodes. This was easy once we had the Stream Muxing figured out.

> jsipfs swarm peers
/ip4/104.131.131.82/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
/ip4/104.236.176.52/tcp/4001/ipfs/QmSoLnSGccFuZQJzRadHn95W2CrSFmZuTdDWP8HXaHca9z
/ip4/104.236.179.241/tcp/4001/ipfs/QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM
/ip4/162.243.248.213/tcp/4001/ipfs/QmSoLueR4xBeUbY9WZ9xGUUxunbKWcrNFTDAadQJmocnWm
/ip4/128.199.219.111/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu
/ip4/104.236.76.40/tcp/4001/ipfs/QmSoLV4Bbm51jM9C4gDYZQ9Cy3U6aXMJDAbzgu2fzaDs64
/ip4/178.62.158.247/tcp/4001/ipfs/QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd
/ip4/178.62.61.185/tcp/4001/ipfs/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3
/ip4/104.236.151.122/tcp/4001/ipfs/QmSoLju6m7xTh3DuokvT3886QRYqxAzb1kShaanJgW36yx

⚡️ Starting an IPFS instance is easier than ever

We've heard you, starting an ipfs instance was cumbersome 3 step process, but not anymore!

Now, all you need to do to start an instance is:

const IPFS = require('ipfs')
const node = new IPFS()

node.on('start', () => {
  // Your node is now ready to use \o/
})

That's it! See more Usage examples in the README

💾 Datastore is here!

We've migrated away from pull-blob-store/blob-store to datastore, the storage interface that is used in go-ipfs. This was a requirement towards implementing the DHT on js-ipfs.

👩🏽‍🏫 New tutorial! Transfer files between browser and desktop nodes

We've build a new Tutorial in how to use js-ipfs that explain how to interact with other nodes, from connecting, discovering and exchanging files. The tutorial is the most bare bones possible (i.e no frameworks) so that it focus on IPFS.

Find this tutorial at our examples folder

👏🏽 jsipfs add --wrap-with-directory is now a feature!

Thanks to @harshjv, now you can add files wrapped in a directory just like go-ipfs. Example:

> jsipfs add <filename> --wrap-with-directory
> jsipfs add <filename -w # alias

Remaining tasks before release

• Merge new datastore all the way up
• Enable bootstrap nodes by default
• Update npm-go-ipfs, npm-go-ipfs-dep and js-ipfsd-ctl to use 0.4.7
• Ensure (again) that js-ipfs-api is 100% working with go-ipfs 0.4.7
• update aegir in all the modules (aegir pit of doom)
  • multiformats
  • ipld
  • ipfs
  • libp2p

Standard release checklist

• Robustness and quality
  • Ensure that all tests are passing, this includes:
    • unit
    • interop
    • sharness
  • Run tests of the following projects with the new release: dropped per @haadcode suggestion
    • orbitdb
    • orbit-core
    • ipfs-log
• Documentation
  • Ensure that README.md is up to date
  • Ensure that all the examples run
• Communication
  • Create the release issue
  • Announcements (both pre-release and post-release)
    • Twitter

Exciting future (soon™)

Here is a quick list of things that we will be heads down after this release

• Circuit Relay - We are building Circuit Relay in order to let browser nodes to connect to any node in the network (e.g when two nodes do not have a common transport). Track the development and spec here -- https://github.com/libp2p/specs/tree/master/relay, [WIP] feat: implement relay circuit libp2p/js-libp2p-circuit#1.
• DHT - The DHT is the second last piece that needs to be built(the first being relay) in order to give browser nodes the ability to discover the location of content by themselves. Track dev at the repo https://github.com/libp2p/js-libp2p-dht
• Parity to IPFS - We want IPFS to access the Ethereum blockchain on demand (i.e: Without having to constantly transferring the blocks over), for that, the EthereumJS team had a brilliant idea of building a storage backend for js-ipfs that uses Parity, so that we can 'read' blocks from the blockchain. Track at: 🌟 Parity to IPFS #763
• Torrent support - We started working in getting Torrent files supported in js-ipfs (same way we do for Ethereum). This will give the ability to fetch data from the BitTorrent network through js-ipfs as well. Track progress here: 🌟 adding Torrent support to IPFS #779

[daviddias]

@haadcode I already know that orbitdb, orbit-core and ipfs-log tests will fail because the "Improving Init endeavor" has happened, see the updated one here: https://github.com/ipfs/js-ipfs#ipfs-core-use-ipfs-as-a-module. Could you timely update orbit to check everything is working fine? Thank you :)

[daviddias]

@lgierth, once you have deployed bootstrapers with 0.4.7, could you list their multiaddrs here. Thank you.

[dignifiedquire]

BLOCKER: #797 (comment) we need to fix the new init process before we can release it

[haadcode]

tldr: I won't be able to update Orbit and its modules to use the new init quickly.

I don't think I can change Orbit just yet to use the new init. As Orbit uses both, js-ipfs and js-ipfs-api, it expects to have the same API regardless of the module. I might be able to hack it so that ipfs-daemon uses two different APIs under the hood, but I'd rather avoid that. Furthermore, since the constructor options object is slightly different in ipfs-daemon (which is what Orbit uses) than how it is for js-ipfs, I will have to update all modules to use the different keys. I'll take a look what I can do in ipfs-daemon and perhaps there's a quick way to conform to the new init, but I won't be able to do that until mid/end of the week.

@diasdavid if you need to move fast with this, go ahead and leave Orbit tests out of the release. We know they're broken (as you said) and I'll make sure on Orbit side that once it uses js-ipfs@0.23.0, it all works.

[daviddias]

As Orbit uses both, js-ipfs and js-ipfs-api, it expects to have the same API regardless of the module

In terms of API, it remains exactly the same, the only thing that is different is the 'init->load->goOnline' step, which was exclusive to js-ipfs.

UPDATE: I've checked your code and what you have to change is only this function https://github.com/haadcode/ipfs-daemon/blob/master/src/ipfs-node-daemon.js#L38-L95 to:

const node = new IPFS({
  repo: <repopath>,
  start: false
  config: { // overload the default config
    Addresses: {
      Swarm: [
        '/libp2p-webrtc-star/dns4/star-signal.cloud.ipfs.team/wss'
      ]
    }
  }
})

node.on('init', () => {
  // node has init'ed
})

And then on your https://github.com/haadcode/ipfs-daemon/blob/master/src/ipfs-node-daemon.js#L97-L119

node.start(callback)

[daviddias]

answer to @dignifiedquire's 'blocker' - https://github.com/ipfs/js-ipfs/compare/fix/race?expand=1

[haadcode]

In terms of API, it remains exactly the same, the only thing that is different is the 'init->load->goOnline' step, which was exclusive to js-ipfs.

Understood. What I meant was that ipfs-daemon has been a way for Orbit to have one (same) API for both ipfs modules and I'll need to re-write the node.js/browser part to use the new init API. My original plan was that once both modules (js-ipfs and js-ipfs-api/js-ipfsd-ctl) support the same user facing API, I'd be able to just switch the modules with (no or) minimal work and eventually make ipfs-daemon obsolete and disappear completely.

Any thoughts on putting this into ipfsd-ctl as well? How do you see the transition happen? I'm assuming here that we agree they both should have the same API :)

I wonder, do we know how many other isomorphic apps are out there that use both modules?

[daviddias]

Any thoughts on putting this into ipfsd-ctl as well? How do you see the transition happen? I'm assuming here that we agree they both should have the same API :)

See:

• Improving init (aka, how do I get a js-ipfs node instance!) #556 (comment)
• Future of ipfd-ctl (for consideration) js-ipfsd-ctl#149

tl;dr; Yeah, I want that too :)

[daviddias]

Interop tests are passing ae4bb9d

And so are unit and sharding

[daviddias]

Bootstrapers are on by default now too \o/

[daviddias]

@haadcode I wanted to PR an update to ipfs-daemon, but I got lost. What is the branch you use today? Master seems out of date for a while and it is not the version that is published on npm.

As per your suggestion, going to drop orbit tests for this release.

[daviddias]

Updated the first post to include all the highlights and a Future section :)

[daviddias]

All right, all remaining tasks are done 🎉

Fellow InterPlanetary Citizens, prepare for the launch, we will make this release in 24~48 Hours, unless there is a major issue found. Now is the time to test it and provide as much feedback as possible. Thank you, godspeed!