-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve onboarding on Firefox for Android #690
Comments
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? I fully agree, we should display different instructions when running on a phone. For now:
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). |
Something along the lines: "This extension connects to the locally running IPFS daemon/node and exposes its interface via the window.ipfs JS variable." |
window.ipfs is just an experiment, so I simplified it to:
Let's keep this issue open until:
|
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?). |
@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 :) |
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.
The text was updated successfully, but these errors were encountered: