Improve UX when localhost gateway is offline

[lidel]

Problem

Right now, when one tries to open localhost URL and the gateway is down, they get a connection error.

Improvement proposal

IPFS Companion could catch when the local gateway is down, and ask the user if they would like to open the requested path using a public gateway, or in the case of DNSLinks, the upstream http server.

The intefrace should be similar to uBlock's interstitial, asking user if they want to allow tracking link Temporary, or Permanently.
So if user wants to always recover using public gateway, and they select Permanently, they will be bothered by this interstitial only once.

Note: the same interstitial UI can be used for asking the user if they would like to load DNSLink website from original URL, or from local gateway.

[juliaxbow]

Including three mockups based on @whizzzkid 's recovery process as defined in #1125 . WRT text and related actions, they are the same.

could catch when the local gateway is down,

Are there any reasons a gateway would be down that would be concerning to the user? I.e. any additional troubleshooting or FYI text we can add in? I attempted to solve for this by linking to documentation on public gateway for the curious user but there's an opportunity to include language in the interstitial

The intefrace should be similar to uBlock's interstitial, asking user if they want to allow tracking link Temporary, or Permanently.

Rather than introduce a "save preferences" button (which we can do if anyone feels strongly), mockups include suggested help text and link to preferences where we should definitely allow folks to update and save their preferences. You can see what a "save preferences" checkbox would look like under V2 mockups.

Screenshots and video mockup below. WRT designs, me know which direction is preferred.

V 1: slightly modifies your structure, @whizzzkid but is essentially the same. Visually this is probably my least favorite

V 2: Similar to V1, this interstitial appears as a standalone web page. Copies elements from the "not connected" notice that new companion users will see if they don't have IPFS up and running

V2 with save preferences checkbox:

V3: This interstitial appears as a side panel alongside the current webpage and allows users to continue to navigate that page.

Recover.Client.Mockups.3.versions.mov

[whizzzkid]

Thanks @juliaxbow I think I can do V2 (without the save preferences check-box) my question is regarding the back button behaviour:

• since the node is disconnected for some reason, the previous page might not be available anymore, so where does the user land in that case?
• also if the user is coming from a new link the previous link could to a public URL which got redirected to local but now the back button takes them back to the public url?

To implement the save-preference option, we would need some more digging:

• do we save preferences per site
• do we recover all pages automatically
• can we add this to the options page

Regarding the v3 you mentioned, I am not sure where does the interstitial appear after someone clicked a link?

• What if we showed them a notification from the companion itself?
• What is the Fake Legit Site. is this the public page for the URL? because that won't be acceptable I assume.
• We also need to account for scenarios where this is the first link they are visiting.

[juliaxbow]

Responding to your other questions shortly but quick clarification re: v3

I am not sure where does the interstitial appear after someone clicked a link?

• You can see how this would look in the screen recording starting at 18sec.

What is the Fake Legit Site

• literally just a fake webpage I had in the figma prototype to show what would happen to the existing web page when the interstitial/panel appears. In the video it's more clear. I should have used a wikipedia screengrab instead :)

side.panel.mov

[whizzzkid]

@juliaxbow the webpage may or may not be available for this action to happen.

[juliaxbow]

since the node is disconnected for some reason, the previous page might not be available anymore, so where does the user land in that case?

• If a user clicks "back" from their browser (vs the "return to previous page" button) they would run into the same problem. In that scenario, I would expect that we would show the interstitial page, now updated with a link that public URI. Am I right in that assumption?
• This could lead to an endless succession of interstitial pages with corresponding public URI links, which could be frustrating and confusing.
  -Most users would (hopefully) attempt a different approach but after 2-3 instances we could show another message to help guide users to troubleshoot
• Regardless, I'm ok to remove the "back to previous content" page and force the user to click "back" from their browser. Updated mock (clearly a fake version # haha):
  

do we save preferences per site

• Hm, seems a little time consuming for the user to do per site. Can you think of any examples where you wouldn't want to connect to a public gateway?
• If we do have saved preferences, we should have another interstitial page along the lines of "can't connect, you are being redirected to a public gateway" so the user is aware

do we recover all pages automatically
can we add this to the options page

What if we showed them a notification from the companion itself?

• Are you suggesting a notification in the extension icon vs interstitial page? I think it's important to include more prominently so the user isn't stuck waiting on something to load if they miss the notification alert
• re: Saved preferences - If we do have saved preferences, we could do a notification from the companion extension in lieu of another interstitial page alerting the user that they're being redirected to a public gateway

We also need to account for scenarios where this is the first link they are visiting.

• The updated mockup should still work but lmk if I'm not addressing your question!

[lidel]

Can you think of any examples where you wouldn't want to connect to a public gateway?

Privacy and Security:

1. Local gateway verifias hashes. Public gateways are not verifiable without extra steps which we can't do in browser ATM.
2. Arguably, harder to track users who use local node and fetch blocks from random peers than sending all IPFS traffic via a specific HTTP server controlled by a single entity.

For these reasons, we always ask user, and don't automatically redirect to a public gateway when the local one is down.

To implement the save-preference option, we would need some more digging:

do we save preferences per site
do we recover all pages automatically
can we add this to the options page

We should NOT recover automatically for the reasons mentioned above, and keeping a preference per website is a bit too much work/complexity/maintenance imo, given how rarely user will see this screen (local node will rarely be down – usually user will see this if they had opened local gateway tab from previous session, and after reboot forgot to start IPFS daemon for some reason).

If we really want, we could add a global OPT-IN toggle on Options page etc, but this must come with security warning:

• (toggle button) When custom gateway is down, redirect to the public one.
  Warning: your browser history will be sent to a third-party HTTP server specified in "Default Public Gateway" and hash verification will no longer happen locally. Make sure you trust your public gateway.").

👉️ But I'd keep it simple; no automatic recovery, no saved preference per websire, just an user-friendly error page that reminds user to turn on the local node + have shortcut to open via public gateway if they are in the rush.

[lidel]

@juliaxbow I really like the version you proposed in #1090 (comment):

Left some text suggestions in #1125 (comment), but it needs some refinement (the longer warning about public gateways probably needs to be in a smaller font?).

[juliaxbow]

Thanks for the comments! Updated per suggestions in #1125. Changed the language slightly, though feel free to tweak if this doesn't capture the right intent:

Alternatively, you can try to open the requested resource using the Public Gateway configured in IPFS Companion. In doing so you will be delegating trust to that HTTP server and the hash verification will no longer occur on your machine.

[lidel]

Closed in #1125 🥳