Improve UX of the root domain landing page

[2color]

We should use the opportunity before the SW is installed to let the user now how the SW is different from a normal gateway before auto-redirecting.

Tasks

Preview Give feedback

1. Show default configuration in config, i.e. delegated routing, DoH, and trustless gateway endpoints,
2. Inform user about in-browser verification
3. Mention Helia with link to repo
4. Add link to GH repo for issues
5. "Alpha" messaging
6. Add a comment at the top of the HTML for when users try URLs with CURL

[lidel]

+1, my wishlist for it would be to improve user agency and transparency:

• do not do automatic SW install and page reload, show informative intermediate page with a button which user needs to click to proceed
• leverage initerstitial page to
  • educate end user how SW gateway is different than dweb.link
    • things to highlight
      • the hash verification happens in the browser, and not on remote server
      • no dependency on specific backend, thanks to trustless, verifiable retrieval and in-browser instance of @helia/verified-fetch
  • give user visibility and control
    • show which gateways and routing / doh endpoints will be used by default (who will be able to infer information about their activity)
    • if they wish to adjust defaults before loading anything, they should be able to do so

As for page design, friendly pattern:

• Read-only defaults (URLs where SW will send requests) should be displayed upfront, not hidden behind a button.
• There should be one prominent "Approve" button, when clicked does initializing the worker and reloading
• There should be less prominent "Configure" button for editing/changing the defaults

[lidel]

suggestion from @aschmahmann

inbrowser.link might want a link to the GH repo for issues, etc.

Do we really want/need the config file on every new subdomain? Seems like we can just do it the first time inbrowser.tld is used and then leave it alone, right?

Yes, I think that we can use iframe to detect if user configured things before, and skip it if they configured things and clicked on init button before.

[2color]

Yes, I think that we can use iframe to detect if user configured things before, and skip it if they configured things and clicked on init button before.

Not sure what you mean here. But we have the default configuration from the code and the user can change that locally for each subdomain URL. This could result in config being different from one origin to another.

What's the idea with using iframe? (and do we need a separate issue for this)

[SgtPooki]

do not do automatic SW install and page reload, show informative intermediate page with a button which user needs to click to proceed

I can't entirely agree with the first part of this. SW registering should happen immediately, but we could block the content loading behind the button.

I've also talked with Adin about this, and he wants to minimize the friction for subsequent visits. That's fair and a good UX, but we should also add some messaging around how to configure the service-worker-gateway. We should always show the config and information when a user first visits the site, but if the user has seen things before and configured auto-reload, they should not see it.

Adin would prefer it if we defaulted to auto-reload so there was less friction on new subdomains where we must register a new service worker instance. Still, I think this could hide the configurability and users could shoot themselves in the foot by enabling "auto reload" and then not remembering how to configure trustless gateways (local/custom/pinata/infura/scaleway/etc) when they realize they need to.

To get around that issue, we need some explicit messaging about accessing the config page on the landing page discussed in this issue.

---

Not sure what you mean here. But we have the default configuration from the code and the user can change that locally for each subdomain URL. This could result in config being different from one origin to another.

@2color answered more in your issue #75, but I am reiterating it here for others who may see this. The config is globalized at the root domain and shared via iframe message passing.

---

I would also love a better-looking config page and better UI of that config page when rendered within the iframe.

[SgtPooki]

Still, I think this could hide the configurability and users could shoot themselves in the foot by enabling "auto reload" and then not remembering how to configure trustless gateways (local/custom/pinata/infura/scaleway/etc) when they realize they need to.

This may become less of an issue when we are fully utilizing responses from delegated routing in the TrustlessGatewayBlockBrokers. However, customization is still important since we have some providers that lock loading of content to their specific gateways.

[2color]

do not do automatic SW install and page reload, show informative intermediate page with a button which user needs to click to proceed

I can't entirely agree with the first part of this. SW registering should happen immediately, but we could block the content loading behind the button.

Yeah, I think if someone opens a subdomain SW gateway URL, there's no reason for us to hold off registering the SW.

Regarding "auto reloading" the page by default so that the CID is automatically loaded, I think that might actually be a case for auto-reload.

There are two things we get from not auto-reloading on the first load:

• Informing and educating the user about how this is different to normal gateways, e.g. local verification and installation reducing subsequent fetches, limitations, where to repot issues etc.
• User configurability of the different endpoints

I'm gonna play devil's advocate: users coming from normal trusted gateways don't care about this things and just want their site/dapp to load. It's not like any users have been desperately asking us for local-verification. At the end of the day, they just want their CIDs to load. With that perspective in mind, we should get out of the way and load things for them with sane default. Given local verification, this will still be much safer than trusting the gateway response.

---

To get around that issue, we need some explicit messaging about accessing the config page on the landing page discussed in this issue.

One thing that isn't clear to me is what are we actually referring to when we say landing page.

There are two possible landing pages:

• The one when you load the naked sw gateway domain, e.g. inbrowser.link
• The one when you load a CID for the first time and the SW hasn't been installed yet, e.g. CID.ipfs.inbrowser.link

Which one are you referring to?

[2color]

Following our sync discussion today:

• we've decided to go forward with default config on the SW registration page and try to load the CID as quickly as possible without requiring user approval or input.
• We should provide the user with some textual and visual feedback to show progress, e.g. "loading CID" and spinner/breathing animation.

For configuration, users will be required to go to the landing page.

Pages and naming

To make sure we have the same understanding

• Landing and configuration page: the bare URL without a CID, e.g. inbrowser.link
• Loader / SW Registration page: (currently referred to as Redirect page in the code): the page on which we install the SW before actually loading the CID, e.g. CID.ipfs.inbrowser.link.

UX patterns and animations for the SW loader page

@lidel mentioned we already have some patterns for this in:

• IPFS Desktop
• IPFS Companion

[SgtPooki]

To get around that issue, we need some explicit messaging about accessing the config page on the landing page discussed in this issue.

One thing that isn't clear to me is what are we actually referring to when we say landing page.

There are two possible landing pages:

• The one when you load the naked sw gateway domain, e.g. inbrowser.link
• The one when you load a CID for the first time and the SW hasn't been installed yet, e.g. CID.ipfs.inbrowser.link

Which one are you referring to?

Below answer based on latest changes on main

I was referring to what is now called the HelperUi, I believe this is what you reference in the first bullet point. The second bullet point loads the redirect-page or redirect-interstitial page depending on where it's hosted.

Pages and naming

To make sure we have the same understanding

• Landing and configuration page: the bare URL without a CID, e.g. inbrowser.link
• Loader / SW Registration page: (currently referred to as Redirect page in the code): the page on which we install the SW before actually loading the CID, e.g. CID.ipfs.inbrowser.link.

I think "sw registration page" doesn't make sense for a name because we should register the service worker in 99% of scenarios, as soon as possible. The redirect page, helper-ui page, and config page each handle the sw registration because they can all be accessed directly via hash fragment or lack thereof.

I like "redirect-page" for the name, because that's what it's doing: handling the case where a user requested some content, and we couldn't intercept it with the service worker for some reason. We could meet in the middle and call it a loading page?

Also, I think the nuance of pages and loading is a little more clear with the latest changes, compared to when we discussed this previously.

[SgtPooki]

Looking at the tasklist above, i'm a little unclear on exactly what each action item is for. @2color if you're still planning to handle this lmk and I can step away, but here are some questions:

"Alpha" messaging

What is this messaging supposed to be exactly? Let me propose the following to kick us off:

Aside/Note in helper-ui above input form:

IPFS Service Worker Gateway allows you to fetch verified-content-addressed-data via a service worker so you can load dApps or content-addressable data securely. You can read more about all the intricacies at https://blog.ipfs.tech/dapps-ipfs/. This service worker is still in heavy development and is not 100% fully compliant with IPFS Specs (verified with gateway conformance tests). You can track our efforts to call this "Production ready" at xxxxxxxx.

Add a comment at the top of the HTML for when users try URLs with CURL

Are we talking about an HTML comment, or a note in the UI that's visible when viewing the content in a browser? just so we're clear, CURL will not hit service-workers.

[2color]

I like "redirect-page" for the name, because that's what it's doing: handling the case where a user requested some content, and we couldn't intercept it with the service worker for some reason. We could meet in the middle and call it a loading page?

Since that's also the name in the code, I'm happy to stick with that. I just wanted to make sure we're talking about the same thing since there was a bit of ambiguity about what we were referring to.

---

Looking at the tasklist above, i'm a little unclear on exactly what each action item is for. @2color if you're still planning to handle this lmk and I can step away, but here are some questions:

Feel free to take this over.

---

"Alpha" messaging

Looks like a good start. Some small refinements

IPFS Service Worker Gateway facilitates verified retrieval of content-addressed data with Helia and the verified-fetch library within a Service Worker. You can use it to securely load dApps and content-addressable (CID) data in the browser. This project is still under heavy development and not 100% fully compliant with IPFS Gateway Specs (verified with gateway conformance tests).
If you have a problem, report issues in the Github repository
You can track our efforts to make it Production ready at xxxxxxxx.

---

Add a comment at the top of the HTML for when users try URLs with CURL

That's already done.

The intention was to ensure that users who try to copy a SW Gateway URL from the browser and curl it in the terminal understand that you cannot use it to with CURL.