Skip to content
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

Open
comntr opened this issue Mar 2, 2019 · 5 comments
Open

Improve onboarding on Firefox for Android #690

comntr opened this issue Mar 2, 2019 · 5 comments
Labels
area/android Issues related to Android area/firefox Issues related to Mozilla Firefox effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked topic/design-content Content design, writing, information architecture

Comments

@comntr
Copy link

comntr commented Mar 2, 2019

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
Copy link
Member

lidel commented Mar 3, 2019

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:

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).

@lidel lidel added the status/ready Ready to be worked label Mar 3, 2019
@comntr
Copy link
Author

comntr commented Mar 4, 2019

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
Copy link
Member

lidel commented Mar 4, 2019

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.

  • 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.

@lidel lidel added the UX label Mar 4, 2019
@lidel lidel changed the title What does this add-on really do? Improve onboarding on Firefox for Android Mar 4, 2019
@Mikaela
Copy link
Contributor

Mikaela commented Mar 23, 2019

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
Copy link
Member

lidel commented Mar 23, 2019

@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 :)

@lidel lidel added the area/firefox Issues related to Mozilla Firefox label Apr 22, 2019
@jessicaschilling jessicaschilling added topic/design-content Content design, writing, information architecture and removed UX labels Mar 30, 2020
@jessicaschilling jessicaschilling added exp/novice Someone with a little familiarity can pick up effort/hours Estimated to take one or several hours good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up labels Apr 7, 2020
@lidel lidel added the area/android Issues related to Android label Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/android Issues related to Android area/firefox Issues related to Mozilla Firefox effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked topic/design-content Content design, writing, information architecture
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

4 participants