Support for js-ipfs

[daviddias]

When to expect js-ipfs support?

[hacdias]

Right now, Desktop uses some endpoints that are not available on js-ipfs yet, such as: repo.stats and stats.bw. And we need MFS working too since the 'Files' pane is going to start using it.

[daviddias]

Will it come on #662 ?

[hacdias]

@daviddias nope, not yet. We decided not to have that feature on the first version and keep it as simple as possible. That will be added afterwards. 😄

[phoniks]

@daviddias @hacdias What would it entail to enable js-ipfs support exactly? I'd like to contribute if it's something I can tackle.

[daviddias]

Awesome, thank you for showing up @phoniks :)

js-ipfs exposes exactly the same API that the client lib (js-ipfs-api) for go-ipfs exposes, so it is just a question of spawning the right daemon.

IPFS Desktop uses https://github.com/ipfs/js-ipfsd-ctl/ which gives a way to spawn an js-ipfs node too

I believe the missing piece is the UI parts, which we need a switch to go from go to JS and then back.

@hacdias wanna share some more pointers in the code?

[hacdias]

@daviddias @phoniks hey! It is really straightforward to let IPFS Desktop use JS-IPFS. You only have to do three things:

• npm install ipfs
• Remove these 3 lines where we explicitly block anything that isn't go.
• On your config, change type to 'js'.

Why aren't we adding js-ipfs right now? We just want to keep this simple to release v1.0. As you can see by our Release 1.0 issue (#669), we postponed the 'Way to connect to multiple backends' feature. That will allow you to switch between different daemons.

We could add js-ipfs right now, but there wouldn't be anything on the interface to allow you to edit your config. That's something to think about: is it worth it to include js-ipfs for now and only those who know how to activate it will benefit from it? Or wait a bit longer until we support multiple backends and have an interface to pick which one to use.

/cc @ipfs-shipyard/gui

[daviddias]

That's something to think about: is it worth it to include js-ipfs for now and only those who know how to activate it will benefit from it?

Yes, because dogfooding :)

[olizilla]

Hey, this is great! @hacdias is right, we're focusing on make the new user experience as clear as possible. Desktop is going to be opinionated on what that looks like. But, we can add an option to our brand new settings page that lets you toggle between go-ipfs and js-ipfs, so folks can try out both. It'll need some good copy to explain it.

I'll write up a more specific issue for it and link back to this one. @phoniks I'll tag you on it. If you'd like to work on a PR for it we'll gladly give you pointers.

[phoniks]

This absolutely sounds like something I can tackle and I'd be really happy to be able to contribute. @olizilla I'll be on the lookout for that issue. In the meantime, I'm going to follow @hacdias's instructions for enabling js-ipfs just to make sure I can get it running on my machine.

[hacdias]

This issue seems quite stale. However, I think that supporting js-ipfs out of the box, or at least with some configuration, is essential. I'm adding this as a feature planned for 0.10.0.

Certainly, this needs to be planned. Right now, we support the most simple setup: one repository with go-ipfs. @alanshaw can you confirm if both js-ipfs and go-ipfs's repositories are compatible with each other?

I see multiple solutions here:

1. Just add js-ipfs as an alternative to go-ipfs and use the same repository, but with a different implementation.
2. Have one repository for go-ipfs and another for js-ipfs.
3. Have multiple repositories, each with a different configuration.

I prefer 1, which is the simplest. Two is quite simple too. I would like to avoid 3 for now: I don't actually see why regular users would want to have multiple repositories on their systems.

[daviddias]

@hacdias 1) is the way to go. This work will hopefully pave the path for future implementations to be added as well and create the template in which apps can switch between multiple implementations with low friction.

[alanshaw]

They should be compatible. We have interop tests to assert that. However, if go-ipfs is using badger datastore js-ipfs cannot use it.

[lidel]

Note a discussion about switching go-ipfs to badger as the default at some point: ipfs/kubo#4279
For now, on the UX side, ipfs-desktop could detect type=badgerds in repo config and disable option to switch to js-ipfs.

[alanshaw]

Can't wait for this to land!

[hacdias]

An update on this: after our weekly call, we are thinking about releasing this as an "hidden" feature for now: we bundle js-ipfs and by tweaking the configuration file, we are able to toggle between both implementations. For now, it will be helpful to test IPFS Desktop against both implementations and will be useful for the testing part.

[pcowgill]

@hacdias In the meantime, is the best alternative to use the web UI for js-ipfs?

[hacdias]

@hacdias In the meantime, is the best alternative to use the web UI for js-ipfs?

Yes, for sure. You can always use the Web UI with js-ipfs without IPFS Desktop.

[pcowgill]

Yes, for sure. You can always use the Web UI with js-ipfs without IPFS Desktop.

@hacdias Unfortunately that didn't work for me ipfs/js-ipfs#2796

[lidel]

Since this issue was filled js-ipfs and go-ipfs removed the guarantee of flatfs repo interop,
and js-ipfs is slowly switching focus to web browser contexts.

This means js-ipfs has different strengths and is no longer a drop-in replacement for go-ipfs.
I am closing this, as there is no benefit to the user to use js-ipfs instead of go-ipfs here, and we have no bandwidth for maintaining such thing, even as an experiment.