Fallback to js-ipfs-api

[koalalorenzo]

Type: Feature Request / Enhancement

Severity: Medium

Description:

Hello!
I am publishing this feature request hoping that somebody will consider it. At the moment js-ipfs works only with Chrome (and modern browser) and it is a problem: to make this usable from any developer on any platform js-ipfs should not just rely on web sockets/libp2p but probably also on other ways to communicate to the network. This should work without problems so that devs can just focus on building apps.

My suggestion is to fallback on js-ipfs-api to provide a connection to a node... then it is up to the developer to check which node, how to use it, etc etc etc.

It should just be simple AF. 😃

Steps to reproduce the error:

Just use Safari with any js-ipfs nodes

[dryajov]

We don't really support safari, however and depending on demand this is something that can be added, tho I'll let others weight in before committing to anything.

Here is another issue asking for safari support - #995

As for js-ipfs-api fallback, isn't it something that can be accomplished now with a few lines of code?

I think something like:

// pseudocode
if (agent.isSafari()) {
   // use js-ipfs-api
} else {
  // spawn in browser IPFS node
}

Unless IPFS is breaking horribly in safari, this should accomplish what you want?

[koalalorenzo]

My idea is not related to Safari, but to anything that is not supported as well for features that are not available! I am not talking about Safari, but anything 👍

[dryajov]

Just use Safari with any js-ipfs nodes

Ah, I got confused by that last statement 👍

Re-reading your proposal I can see that there are actually two suggestions - correct me if I'm wrong.

to make this usable from any developer on any platform js-ipfs should not just rely on web sockets/libp2p but probably also on other ways to communicate to the network.

We currently support WebRTC and WebSockets in web browsers, with WebSockets having the widest adoption across browsers and WebRTC having less adoption so far. Having the WebSockets transport ensures that at least from libp2p point of view, communication should not be a problem and running a full IPFS node in other browsers should be a matter of finding missing/broken api's and shimming/fixing those as required.

I personally think this is something that we really want, however given how much work there is still left to do and the various quirks that each browser would undoubtedly have, the IPFS team has chosen to concentrate on supporting the two most feature complete browsers available right now - Chrome and Firefox. That said, there should be no impediments to anyone interested to do the legwork in getting a particular browser supported, and I'll be more than happy to help and provide guidance as needed 💯

Take a look at #725 - Awesome WebWorkers Support for a similar effort to get IPFS running in WebWorkers/ServiceWorkers.

My suggestion is to fallback on js-ipfs-api to provide a connection to a node... then it is up to the developer to check which node, how to use it, etc etc etc.

Regarding the above suggestions, IMHO I think having IPFS making the decision of falling back to js-ipfs-api buys us absolutely nothing, moreover it encourages tight coupling and prevents the two modules (IPFS and js-ipfs-api) from evolving separately. I still think that what you're suggesting can be accomplished with a simple if statement similar to what I showed above.

I might still be missing the point of your proposal, if so don't hesitate to clarify. 🔦