Improve onboarding on Firefox for Android

[comntr]

I've installed it on my Firefox Android, hoping that it'll use some native APIs not available to web apps to connect to the IPFS network, but it didn't. Instead it's shown me a screen with instructions to run an IPFS daemon (on a phone?). It's fine if the extension is merely a relay to the local daemon, but this needs to be clearly called out in the description in the first paragraph.

[lidel]

Thank you for raising these issues to our attention.

Which specific description you have in mind? Text on Firefox Add-On store or the one in README#features? Do you have any specific wording in mind that would be appropriate?

I fully agree, we should display different instructions when running on a phone.

For now:

• On Android, you should be able to use one of community-contributed distributions as "external node":
  • https://play.google.com/store/apps/details?id=org.ligi.ipfsdroid&hl=en (does not seem to be updated for some time)
  • https://play.google.com/store/apps/details?id=fr.rhaz.ipfs.sweet (probably the best choice atm)
• Or switch IPFS Companion to experimental "embedded node" – see /docs/node-types.md

Our goal is to enable "embedded node" by default, but we are not there yet (need to ensure proper connection management is in place, as we don't want to drain your battery).

[comntr]

Something along the lines: "This extension connects to the locally running IPFS daemon/node and exposes its interface via the window.ipfs JS variable."

[lidel]

window.ipfs is just an experiment, so I simplified it to:

This extension connects to the locally running IPFS node and exposes its interface and selected features to the user.

• [x] Updated description in both extension stores to include it at the beginning of description copy.

Let's keep this issue open until:

• [ ] landing page on Firefox for Android gets updated, or embedded node is selected by default.

[Mikaela]

Is the extension only for connecting to local gateway? I think I have seen discussions where the goal is said to be the first taste of IPFS (for a new user even if they don't run their own node) or a "gateway drug" for making them to install a full IPFS node and contribute to the network (which is probbaly enabling the embedded node?).

[lidel]

@Mikaela You will have the best experience if you run ipfs-companion with local/remote go-ipfs or ipfs-desktop, but we are working on making embedded js-ipfs more and more useful, and there is even an issue about WASM build of go-ipfs. Ideally, the node embedded in extension itself would work out of the box and be "good enough" for casual users, but we are not there yet:

With currently existing WebExtension APIs ipfs-companion is unable to inject/spoof HTTP responses, or register a streaming protocol handler. We can only redirect. That is why we need local or public gateway (as an endpoint to redirect to).

There are experimental APIs in customized Firefox Nightly (streaming protocol handler from libdweb) and Chromium (exposing embedded HTTP gateway via chrome.sockets) that remove this limitation, but in mainstream browsers (Firefox/Google Chrome) we are stuck with existing APIs and the need for local gateway.

As a sidenote, an alternative approach may come from recent Progressive P2P Web Apps experiments. That work might enable ipfs-companion to act as a provider for Service Worker-based access point, and return IPFS payloads that way. But for now, its just my speculation :)