Changing language around Redirects and Gateways

[lidel]

Changing language around some features

We are at the stage where we need to rework language around some features provided by IPFS Companion. Current labels describe what happens at the technical level and don't tell much about the purpose unless user is already familiar with low level details of our stack.

Main menu looks like this.

Having two entries controlling "Redirect" do not help:

On the technical level, there are different things we can "redirect":

• content paths (resources loaded from /ipfs/{cid}/ on any website)
• DNSLink websites (which we should stop redirecting until Origin issues are solved: Disable default redirect of DNSLink websites if it breaks Origin #701)
• subdomain gateways (same situation as DNSLink)

However user does not care about the distinction.
They just want to "use local node where possible".

Current idea is to:

• Rename Global Redirect toggle (the one that controls all redirects)
  • I believe we should stop using "gateway" here, as we will have native protocol handler at some point, and "redirecting to a gateway" won't make sense anymore
  • Initial ideas: "Prefer local node", "Use preferred node", "Try local node first"
    (would love feedback on this)
• Replace or move Per-website redirect toggle (Enables user to disable redirect on a specific website)
  • Update: ✔️ Moved to Preferences in c7c3221
  • The main purpose for this was to give people a way to fix a website that was broken by a redirect without disabling redirects globally.
  • I think we should be more honest about this, and replace redirect toggle with one that disables all IPFS integrations on specific website.
    • Ideas: "Disable Companion on example.com", "Disable all integrations on example.com" "Ignore this site"
    • Alternative idea: remove this from browser menu, but keep a list of hostnames on Preferences. Rationale: the need for disabling companion on a specific website should be super rare, and when we ship (Disable default redirect of DNSLink websites if it breaks Origin #701) there won't be any need for having it in browser action menu. When DNSLink website is detected we would add something where you can "make this site available offline and re-host it" as an opt-in rather than doing an eager redirect (Load site via http first, fetch via IPFS in background #710 (comment)).

Would love to hear some thoughts on this.

[ericronne]

Re labeling, Try local node first and Ignore this site strike me as lovely and clear plain-language descriptions. It would be great to run usability tests, though, to see how users interpret the various options. 🤗

[hacdias]

@lidel kinda related: ipfs/ipfs-desktop#1034

[lidel]

@cwaring noted in #826 (comment):

but do you think it's widely understood what a Custom Gateway is? I would be inclined to be more specific, such as: Always load DNSLink websites via IPFS Companion's local gateway. (if that is a correct statement?)

In theory "custom gateway" could not be in local network, but I think "local gateway" is a better name as it reflects what most of users do (install ipfs-desktop, have local node).