feat: improved UX when opening IPFS URIs #1966

hacdias · 2022-01-28T16:40:30Z

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.

lidel

Thank you, this is long time due!

Small asks

replace "URI" with "address" (diffs inline)
add IPFS cube logo to the Ask window (centered, above "How would you like.." sentence)

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.

Hm.. we don't want to duplicate settings, and opening Files instead of Explore looks like a bug.
I think we should fix ipfs/ipfs-webui#1884 before merging this PR, so there are no surprises around the way IPFS addresses are handled.

.. or just hide "Explore" option for now, so we don't need to wait for ipfs/ipfs-webui#1884

lidel · 2022-02-04T01:41:41Z

src/protocol-handlers.js

+  }
+
+  const action = await getAction()
+  let base = 'https://dweb.link'


💭 hardcoding this may be confusing because ipfs-webui now allows user to customize the public gateway (added in ipfs/ipfs-webui#1834):

I think Electron should be able to reach out to the renderer and see if custom public gateway was set in window.localStorage under ipfsPublicGateway (+ JSON unwrapping due to local-storage.js weirdness).

That way we could respect user choice (and if not present, default to dweb.link

This is a great idea, but I will also need to work on a hook to make sure this value gets updated on IPFS Desktop every time it is updated on IPFS Web UI.

@hacdias I was thinking about simple, low-effort implementation that respects user choice made in ipfs-webui Settings:

every time you need to generate shareable link in ipfs-desktop, read the value from localStorage in ipfs-webui in renderer process.

not need for copy of the value does not be stored/updated in ipfs-desktop

@lidel that is reasonably simple if we wait for the Web UI window to be ready. We have to wait for it to be ready to have that working. So if you open an IPFS link, IPFS Desktop has to boot up and wait for the Web UI window to be ready until the link is actually open. That could feel quite slow. That's why I thought about keeping a copy on Desktop's settings such that we do not need to wait.

On 90b25e0 I made a best effort attempt. If the web ui window hasn't been created yet, we use the default public gateway. I can, however, rearrange Desktop's startup logic to ensure the window always exists. Note that this would also stop working if we decide to go on with #1929.

assets/locales/en.json

hacdias · 2022-02-09T15:51:01Z

@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 ipfs/ipfs-webui#1884

I'll do that.

lidel

Polishing the UX

I took it for a spin via npm start -- ipns://en.wikipedia-on-ipfs.org to trigger the one-time choice dialog, current options are:

My initial impressions:

🎨 small UX asks
- 🧊 needs IPFS cube as a visual hint to indicate where the question comes from
  - Then, should we do the same for the "Download CID" window? We're using the same template, after all.
    
    @hacdias yes, sounds sensible and it would look good there too
- 🆔 could we show the UR Ithat triggered the dialog as part of the question? I'm thinking How would you like to open IPFS addresses like ipns://en.wikipedia-on-ipfs.org?
  - makes it easier to connect the dots ("i clicked on this ipns:// thing and this happened")
💭 I started questioning myself: is there a value in having separate browser options for public and local gateway?
- 💢 Beginner/casual users would not even know what this choice means
  - 💡 this could be mitigated by adding "(safe default choice)" next to pre-selected "public gateway" option
- 💢 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've seen folks strugging with this in ipfs-companion – the bug reports go away only if we redirect to public gw when local is dead.
- 💡 My gut feeling is that we should only have the public gateway option (simple "In my web browser") – kicking the routing decision to the browser.
  - 💚 Browsers with IPFS support (Brave or IPFS Companion) would redirect public gateway link to local gateway anyway
  - 💚 regular browsers would load the original URL, there is no footgun when local node is offline

Thoughts?

cc'ing @autonome @SgtPooki (not urgent, but before we ship this, would appreciate more 👀 on this, both from the perspective of a native speaker, and general UX)

src/i18n.js

lidel · 2022-02-11T15:34:23Z

src/protocol-handlers.js

+  }
+
+  const action = await getAction()
+  let base = 'https://dweb.link'


@hacdias I was thinking about simple, low-effort implementation that respects user choice made in ipfs-webui Settings:

every time you need to generate shareable link in ipfs-desktop, read the value from localStorage in ipfs-webui in renderer process.

not need for copy of the value does not be stored/updated in ipfs-desktop

hacdias · 2022-02-17T12:20:46Z

🧊 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 · 2022-03-03T19:13:14Z

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 · 2022-03-04T13:52:12Z

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 · 2022-03-11T12:57:50Z

I will work on those changes then.

License: MIT Signed-off-by: Henrique Dias <hacdias@gmail.com>

Co-authored-by: Marcin Rataj <lidel@lidel.org>

License: MIT Signed-off-by: Henrique Dias <hacdias@gmail.com>

hacdias · 2022-03-17T14:11:20Z

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.

SgtPooki

Thanks for the updates @hacdias . Many comments are questions because I'm newer to this repo, but the ctx refactor has helped me to gain a bit of understanding of the current problems we face with the ipfs-desktop, so I hope the non-question comments are helpful =)

assets/locales/en.json

src/dialogs/prompt/index.js

src/dialogs/prompt/styles.js

src/dialogs/prompt/index.js

src/i18n.js

src/index.js

src/protocol-handlers.js

src/tray.js

SgtPooki · 2022-05-06T16:11:19Z

src/tray.js

+  NAMESYS_PUBSUB_KEY,
+  ASK_OPENING_IPFS_URIS


@lidel @achingbrain This is why we need to use trailing commas. How can I go about updating the styling across our repos so that we can allow/require trailing commas in our code? These diffs don't need to be this noisy. git blaming is also a PITA when we try to find out who originally added NAMESYS_PUBSUB_KEY, or whatever the non-trailing-comma-having previous line ends up being in PRs.

hacdias · 2022-05-10T12:35:55Z

@SgtPooki I think I addressed all of your comments!

src/dialogs/prompt/html.js

src/protocol-handlers/index.js

src/protocol-handlers/urls.js

SgtPooki · 2022-07-07T15:53:20Z

src/protocol-handlers/urls.js

+    const { status } = await fetch(
+    `${url}/ipfs/bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss`
+    )
+    return status === 200


do we need a status=200 or could we check for ok?

#1966 (comment)

SgtPooki · 2022-07-07T15:54:58Z

src/protocol-handlers/urls.js

+    url = new URL(url)
+    url.hostname = `bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss.ipfs.${url.hostname}`
+    const { status } = await fetch(url.toString())
+    return status === 200


would using ok be sufficient or do we require an explicit 200?

Code borrowed from Web UI: https://github.com/ipfs/ipfs-webui/blob/4bf78a47fcb38872edbe55a5046ae3c7d3fe1a10/src/bundles/config.js#L113-L138

Not sure if we need explicit 200 or any OK suffices. /cc @lidel

@lidel pingity ping ping

SgtPooki · 2022-07-07T15:56:38Z

src/protocol-handlers/urls.js

+const checkIfSubdomainGatewayUrlIsAccessible = async (url) => {
+  try {
+    url = new URL(url)
+    url.hostname = `bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss.ipfs.${url.hostname}`


What is the hardcoded CID in bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss.ipfs.${url.hostname}?

Should that be saved in consts.js?

Same as before: I did not write this code, but it seems that it is some safe CID (ipfs/ipfs-webui@ebda764) for "Welcome to IPFS :-)"

This is a CID which has Welcome to IPFS :-) string inlined inside identity Multihash.
Main reason for using this exotic multihash type is to avoid hitting DHT/datastore – gateway can respond immediatelly after decoding CID.

SgtPooki · 2022-07-07T15:59:45Z

src/protocol-handlers/urls.js

+ * @param {ParsedUrl} parsedUrl
+ * @returns
+ */
+async function getGatewayUrl (ctx, { protocol, hostname, path }) {


@lidel do we have an ipfs-utils or other library where we can put our higher level functions that are used across the stack? It could help prevent us from getting into a situation in the future where all of our libraries are using out of date low-level ipfs deps.

Afaik no.
There are things like https://github.com/ipfs/js-ipfs-utils (legacy, does not seem to be maintained) and https://github.com/ipfs/js-ipfs/tree/master/packages/ipfs-core-utils/src (part of js-ipfs), but they pull-in too many dependencies.

hacdias · 2022-07-20T09:24:41Z

@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

@SgtPooki @hacdias I just realized this PR comes with an awful UX footgun 😿

If user tries to open ipns://en.wikipedia-on-ipfs.org/wiki/ and decides to do that in IPFS WebUI, it will fail because ipfs-webui is not optimized for showing huge HAMT-sharded UnixFS directories, and /ipns/en.wikipedia-on-ipfs.org/wiki/ is one (has ~20M items).

Due to this, I feel we need to mark this as blocked until we add a smart HAMT handling.

Upstream issues:

assets/locales/en.json

Co-authored-by: Marcin Rataj <lidel@lidel.org>

lidel · 2023-11-06T22:19:13Z

This ended up no longer feasible, see #1646 (comment)

hacdias mentioned this pull request Jan 28, 2022

Improve onboarding via OS-level protocol handler #1646

Closed

hacdias force-pushed the feat/ux-protocol-handler branch from 061e79d to b319b8c Compare February 2, 2022 11:17

hacdias marked this pull request as ready for review February 2, 2022 11:27

hacdias requested a review from lidel February 2, 2022 12:00

lidel requested changes Feb 4, 2022

View reviewed changes

lidel requested changes Feb 11, 2022

View reviewed changes

lidel self-requested a review February 17, 2022 17:16

hacdias force-pushed the feat/ux-protocol-handler branch from 90b25e0 to 69e4619 Compare March 11, 2022 12:05

hacdias and others added 12 commits March 17, 2022 13:18

wip: ask when opening external protocol

534b1aa

License: MIT Signed-off-by: Henrique Dias <hacdias@gmail.com>

feat: ask when opening external protocol

715303d

Update assets/locales/en.json

46b20bd

Co-authored-by: Marcin Rataj <lidel@lidel.org>

Update assets/locales/en.json

98314a9

Co-authored-by: Marcin Rataj <lidel@lidel.org>

Update assets/locales/en.json

70018f2

Co-authored-by: Marcin Rataj <lidel@lidel.org>

Update assets/locales/en.json

a39f015

Co-authored-by: Marcin Rataj <lidel@lidel.org>

remove explore option for now and ensure app and i18n are ready

03db51d

License: MIT Signed-off-by: Henrique Dias <hacdias@gmail.com>

refactor: i18n export

d91f453

refactor: rename setup to ready

8b21910

add IPFS logo to dialog

abdeea2

fetch public gateway from webui window

3a5a2ab

fix styles

3b7806e

hacdias force-pushed the feat/ux-protocol-handler branch from 69e4619 to 3b7806e Compare March 17, 2022 12:19

only two options, detect localhost subdomains

7de9e9f

Merge branch 'main' into feat/ux-protocol-handler

2aca7be

SgtPooki requested changes May 6, 2022

View reviewed changes

SgtPooki reviewed May 6, 2022

View reviewed changes

SgtPooki mentioned this pull request May 6, 2022

Maintenance enhancement: Migrate config keys into src/common/configKeys #2129

Closed

hacdias added 5 commits May 10, 2022 13:25

rename makeButtons and makeInputs

92cdc43

refactor prompt html and jsdocs

32e6032

refactor: separate protocol handler url tools

24ecde4

revert changes to index and wait on protocol hanlers

c0290bb

revert index.js

9dcf458

hacdias requested a review from SgtPooki May 10, 2022 12:35

Merge branch 'main' into feat/ux-protocol-handler

e6d8dff

SgtPooki requested changes Jul 7, 2022

View reviewed changes

hacdias added 7 commits July 15, 2022 13:21

refactor: remove comments

91f255e

refactor: rename ask askWhenOpeningUri

e7cd90b

refactor: add comment and be more explicit

c4752d7

refactor: add comment, cleanupo

a861ffb

fix: add null to return types

4d54b5a

fix: wrap JSON.parse around try catch

18e8b14

Merge branch 'main' into feat/ux-protocol-handler

5af40c7

lidel requested changes Aug 1, 2022

View reviewed changes

assets/locales/en.json Outdated Show resolved Hide resolved

lidel added the status/blocked Unable to be worked further until needs are met label Aug 1, 2022

Update assets/locales/en.json

270d60d

Co-authored-by: Marcin Rataj <lidel@lidel.org>

SgtPooki assigned hacdias Sep 1, 2022

hacdias force-pushed the feat/ux-protocol-handler branch from 9c8b2b9 to 270d60d Compare September 2, 2022 12:18

Merge branch 'main' into feat/ux-protocol-handler

b73c451

SgtPooki marked this pull request as draft September 12, 2022 17:02

lidel closed this Nov 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: improved UX when opening IPFS URIs #1966

feat: improved UX when opening IPFS URIs #1966

hacdias commented Jan 28, 2022 •

edited

Loading

lidel left a comment •

edited

Loading

lidel Feb 4, 2022

hacdias Feb 10, 2022

lidel Feb 11, 2022 •

edited

Loading

hacdias Feb 17, 2022

hacdias Feb 18, 2022 •

edited

Loading

hacdias commented Feb 9, 2022

lidel left a comment

lidel Feb 11, 2022 •

edited

Loading

hacdias commented Feb 17, 2022 •

edited

Loading

SgtPooki commented Mar 3, 2022

lidel commented Mar 4, 2022 •

edited

Loading

hacdias commented Mar 11, 2022

hacdias commented Mar 17, 2022

SgtPooki left a comment

SgtPooki May 6, 2022

hacdias commented May 10, 2022

SgtPooki Jul 7, 2022

hacdias Jul 15, 2022

SgtPooki Jul 7, 2022

hacdias Jul 15, 2022

SgtPooki Jul 18, 2022

SgtPooki Jul 7, 2022

hacdias Jul 15, 2022

lidel Jul 25, 2022

SgtPooki Jul 7, 2022

lidel Jul 25, 2022

hacdias commented Jul 20, 2022

lidel left a comment •

edited

Loading

lidel commented Nov 6, 2023

feat: improved UX when opening IPFS URIs #1966

feat: improved UX when opening IPFS URIs #1966

Conversation

hacdias commented Jan 28, 2022 • edited Loading

lidel left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lidel Feb 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hacdias Feb 18, 2022 • edited Loading

Choose a reason for hiding this comment

hacdias commented Feb 9, 2022

lidel left a comment

Choose a reason for hiding this comment

Polishing the UX

lidel Feb 11, 2022 • edited Loading

Choose a reason for hiding this comment

hacdias commented Feb 17, 2022 • edited Loading

SgtPooki commented Mar 3, 2022

lidel commented Mar 4, 2022 • edited Loading

hacdias commented Mar 11, 2022

hacdias commented Mar 17, 2022

SgtPooki left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hacdias commented May 10, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hacdias commented Jul 20, 2022

lidel left a comment • edited Loading

Choose a reason for hiding this comment

lidel commented Nov 6, 2023

hacdias commented Jan 28, 2022 •

edited

Loading

lidel left a comment •

edited

Loading

lidel Feb 11, 2022 •

edited

Loading

hacdias Feb 18, 2022 •

edited

Loading

lidel Feb 11, 2022 •

edited

Loading

hacdias commented Feb 17, 2022 •

edited

Loading

lidel commented Mar 4, 2022 •

edited

Loading

lidel left a comment •

edited

Loading