Improve onboarding via OS-level protocol handler

[lidel]

Right now, IPFS Desktop installs system-wide protocol handlers (dweb, ipfs, ipns) which converts ipfs://<cid> URI to gateway URL and opens that in default browser.

It is fine, but may be confusing on the first use.

We could improve this behavior and show a dialog window, where user can choose how to open IPFS resource via radio-button-like selector:

• open from public gateway in the default web browser (default)
• open from a local gateway (show only if daemon in running)
• open in webui/Files (show only if daemon in running)
• open in webui/Explore (show only if daemon in running)
• (checkbox) remember the choice for the future
  • should be accompanied by a toggle in menubar menu: "Ask how to handle IPFS URIs" so user can change their mind later

(thx @aschmahmann for noticing that onboarding is especially confusing if user's default browser is not the one with ipfs-companion)

[jessicaschilling]

This is also a good opportunity to emphasize on first use that Desktop is acting as the intermediary - otherwise, the flow is like this:

• user types ipfs://QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU into their browser bar
• they get a "do you want to open this in IPFS Desktop?" dialog, and click "OK"
• but then they just stay in their browser and see their requested resource in a new tab

This is super-confusing if you've never encountered it before.

[jessicaschilling]

Quick mockup of menu item mentioned above:

[jessicaschilling]

Quick mockup of choice modal (note this could appear over whatever screen the user currently has open in Desktop):

[lidel]

Thank you, yes, this would do the trick.

nit: this modal is specific to Desktop app, so I think it should not be part of WebUI, but a separate window that loads the modal page.

[jessicaschilling]

a separate window that loads the modal page

Confirmed this just means modal appears in its own window without Web UI furniture behind it: i.e., ignore grayed-out Web UI interface behind the modal in the mockup above. Can amend mockup if this is absolutely necessary, but this should be ready to work. Text (for copy-paste convenience) is as follows:

How would you like IFPS Desktop to open this ipfs://URI?

• In my default browser using a public gateway
• In my default browser using my local gateway
• In the Files screen
• In the Explore Screen

(checkbox) Remember this choice for all ipfs:// URIs

(buttons) Close / Continue

Note that the image in the modal is the standard stroke_link icon from ipfs-css.

[lidel]

This is a significant UX improvement, bumped a priority a bit.

ps. I suspect protocol handler does not work everywhere (eg. https://github.com/ipfs-shipyard/ipfs-desktop/issues/1549).

[unmellow]

Not sure if this is the best place to mention this but I think it would be a good idea for you to a url in the style of lokinet E.G. http://awsomeipfs.io.ipns vs the current system

the idea is lokinet recognizes all domains as their own origins so copying their structure should help

Not actually knowledgeable of the low level of how this works but untill the web 2.0 APIs are complete you should in theory be able to imatate whatever it is that they've done

[hacdias]

I'm now working on this on #1966. I also want to add that the Explore page does NOT support IPNS links. Options I see:

1. Ask this prompt for each different scheme: ipfs://, ipns://, dweb:/ipfs, dweb:/ipns
2. Default to opening on files or browser for IPNS.

2 is easier to implement than 1.

What do you think?

[lidel]

The proliferation of ipns:// and ipfs:// addresses for website hosting changed the feasibility here.

URIs are now natively supported by Brave and ipfs-chromium, and IPFS Desktop trying to capture them and opening them in IPLD Explorer or Files explorer becomes effectively harmful, as miss-click will break websites for less technical users, especially if the checkbox to remember choice is checked.

Due to this, I'm closing this, as it is no longer something desired in user-friendly tool.