Fragmentation

[daviddias]

TIL that there is a @haad/ipfsd-ctl. I don't understand why there is a need to create such a module, but it seems it has been going for a while, making it more than an experiment, but an actual fork/module available in NPM.

I very much disagree with this approach because it is clearly fragmenting the ecosystem set by creating yet another module that is not being tracked as a PR and doesn't show any future where that will happen, making us maintain 2 modules instead of one.

When the challenge on ipfs/js-ipfs#556 was launched, the proposal was exactly to reduce fragmentation and to make the launch of IPFS nodes more easily, but what I see that got created was another module, ipfs-daemon, which has its set of issues, which uses a module that is a fork of this one, namely @haad/ipfsd-ctl.

@haadcode can we converge all of these, it really doesn't help. Others are invited to provide their feedback, I might also be missing the value and apologize in advance if I'm doing so.

[daviddias]

We can see on how one is getting behind

And the link in the npm package is pointing to the 'wrong' repo

[daviddias]

Found this one too https://github.com/haadcode/ipfs-test-apis

[daviddias]

@haadcode we need to converge https://github.com/haadcode/js-ipfsd-ctl into this. What are the steps for that? What is stopping you from using the main one and maintaining a fork?

[haadcode]

Short: 0.4.5.

Long:
The fork was originally done to have 0.4.5 go-ipfs bin in the chain of deps for Orbit (which needed pubsub).

So, to unravel all that, we need to merge ipfs-inactive/npm-go-ipfs-dep#18 and ipfs-inactive/npm-go-ipfs-dep#19 and release [email protected].

The other part is to merge #145 and release new version of ipfsd-ctl (this PR will make ipfs-daemon compatible with js-ipfsd-ctl). And after releasing 0.4.5 we should release ipfsd-ctl with the new go-ipfs-dep version.

That's all! :) Finally there 🎉 🎆

[daviddias]

• go-ipfs 0.4.5 ipfs-inactive/npm-go-ipfs-dep#18
• Fix exit codes and success output ipfs-inactive/npm-go-ipfs-dep#19
• [email protected]
• Add gateway address to the returned IPFS api #145

I see a breaking change proposed on #145 and no PRs to js-ipfs and js-ipfs-api that cope with that change, meaning that the poor soul that merges and releases would have to run and put up fires. Can we avoid this by preemptively having PRs that cope with the fixes so that no one is caught off guard?

[daviddias]

All done \o/