feat: improved UX when opening IPFS URIs

[hacdias]

This fixes #1646 by adding a dialog when opening an IPFS or IPNS with IPFS Desktop:

The UI matches the other dialogs we use on IPFS Desktop, which try to resemble a native dialog the most it can.

The option to ask when opening is also added under the preferences in the menubar tool:

Note: the Explore section does not support IPNS. Thus, I decided to open on the Files page if the user opens an IPNS URL and selects the Explore section by default.

The other option is to ask separately for IPNS and IPFS. That is possible but will duplicate the options in the settings.

[hacdias]

@lidel

add IPFS cube logo to the Ask window

Then, should we do the same for the "Download CID" window? We're using the same template after all.

.. or just hide "Explore" option for now, so we don't need to wait for https://github.com/ipfs/ipfs-webui/issues/1884

I'll do that.

[hacdias]

🧊 needs IPFS cube as a visual hint to indicate where the question comes from

Done.

could we show the UR that triggered the dialog as part of the question

This is easy to do, but we have to make sure it doesn't overflow or wrap to the next line, otherwise some window text will be hidden. The maximum size would also vary with translations so I'm not sure what's the best way to proceed here.

---

I will defer the remaining updates once we have @autonome's and @SgtPooki's feedback regarding the gateway options.

[SgtPooki]

I agree 100% with all the callouts from lidel. A few additional comments:

If user selected "public" but their browser has redirect to local (Brave, Companion) that looks like a bug, because they wanted public link, and ended up on local If user selected "local" but the node is down, then links either fail or we need to use public gateway anyway

I would reduce the number of options to only either: open in browser, open in ipfs desktop, and then let ipfs-companion/browser handle the rest, since they will override whichever decision is made in ipfs-desktop anyway. What do you think @lidel? And if we did do this, should the browser option always use local?

If a user is running ipfs-desktop, then they should have a local node running at the time ipfs-desktop opens the link in the browser, right?

[lidel]

I would reduce the number of options to only either: open in browser, open in ipfs desktop, and then let ipfs-companion/browser handle the rest, since they will override whichever decision is made in ipfs-desktop anyway. What do you think @lidel?

Yep, this sounds like the best way to do this.

And if we did do this, should the browser option always use local? If a user is running ipfs-desktop, then they should have a local node running at the time ipfs-desktop opens the link in the browser, right?

Hm.. yes. If we have a generic "Open in browser" then yes, this makes sense and provides better experience for users with browser that does not understand IPFS, because links will open instantly from local node, instead of YMMV provided by a public gateway.

ipfs-desktop could make a quick test to confirm local gateway is still online, and use its address instead of public one.

ipfs-webui is already doing that type of check (it checks if local gateway port is functional, it also confirms if OS supports subdomains on localhost, and sets gateway links to the best option available, falling back to public gateway URL as the last resort)

To be specific, if we want to open from local node by default, we need to:

• test if {cid}.ipfs.localhost:{port} works with some CID that does not require hitting dht (e.g. bafkqablimvwgy3y → hello)
  • if subdomains are not available, fallback to IP: 127.0.0.1:{port}/ipfs/{cid} and check if it works
    • if that fails, use https://dweb.link/ipfs/{cid} (or other public gateway configured in webui)

[hacdias]

I will work on those changes then.

[hacdias]

Just updated the PR to match the conversation above.

Disclaimer: I tested this on macOS. It seems that the localhost domain works when using Chrome but fails when using fetch (also seems to not work on Safari). Thus, even though Chrome may be the default browser, it won't use the localhost version.

[hacdias]

Ping @lidel

[SgtPooki]

I tested this on macOS. It seems that the localhost domain works when using Chrome but fails when using fetch (also seems to not work on Safari). Thus, even though Chrome may be the default browser, it won't use the localhost version.

@hacdias can you explain a little bit more about this? Are you saying chrome loads a URL with a localhost domain, but cannot make successful fetch calls on the page that is loaded?

Also, I will try to download the generated ipfs build on windows right now and update this comment.

[hacdias]

@SgtPooki I think I addressed all of your comments!

[hacdias]

@SgtPooki solved the conflicts. It seems that the CI is taking way too long downloading Web UI for the tests. We may have to restart them later.

[lidel]

This ended up no longer feasible, see https://github.com/ipfs/ipfs-desktop/issues/1646#issuecomment-1796859438