Improving UX of IPFS in Address Bar

[lidel]

Related to IPFS Integration - Roadmap and discussion: #819

UX challenges

Loading IPFS from public gateways falls under regular HTTP/HTTPS and that is okay.
However when user is running IPFS node on their own machine (provided by ipfs-desktop or experimental embedded js-ipfs+chrome.sockets), they effectively replace HTTP with IPFS transport and it would be beneficial if Browser UI reflected that.

Current state

When content is loaded from IPFS via HTTP Gateway running on the localhost the UX around address bar is pretty rough:

• URL with IPFS path for a content identified by a CID:

  

• URL with IPNS path for a website with DNSLink:

  

Problems:

• raw IP of local gateway is highlighted, but it does not provide any meaning to non-technical user
• content identifier (CID) is long, faded-out and takes a lot of space
• http://127.0.0.1 location does not make much sense for content-addressed context
• security indicator is confusing:
  Browser assumes regular http:// (no encryption/integrity guarantees) while IPFS provides a different set of guarantees that are not reflected in UI:
  • transport encryption between you and your peers
  • payload integrity (hashed payload blocks needs to match requested CID)

Potential improvements

Below are some ideas I discussed with various people (including IPFS Camp).
This is by no means a final design: the goal of this issue is to start the conversation about the UX in address bar and find a sweet spot between what is technically feasible and what would produce good UX. Please provide feedback in the comments.

Prerequisite: detect requests to local gateway

Brave should be able to tell when local Origin is backed by IPFS.

One way to implement this is to leverage IPFS Companion extension. When it is installed, the address of local gateway can be read from its browser.storage.local: the URL is under a key named customGatewayUrl (eg. http://127.0.0.1:8080).

(1) Hide local gateway from address bar

Low hanging fruit is to detect that content was loaded from IPFS and change the way address bar shows address to the user. Prior art from Beaker Browser:

In content-addressed contexts the location of local gateway does not bring any additional meaning. I documented initial exploration of how IPFS addresses could look like if we drop local gateway from the UI:

• We know content comes from trusted local gateway. Let's show only the IPFS path:
  
• CID indicates the content root, so we want to highlight it:
  
• At the same time CID is not human-readable, so we may just show short version by default:
  
  which gives more space for content paths after it:
  
  • for CID we care about first 2 (familiarity) and last 4+ characters
    (this gives user low quality uniqueness for quick eyeballing)
  • this is similar to what Github does with commit hashes
• Path-addressing can be replaced with regular protocol-looking ipfs:// and ipns:// if it makes implementation easier:
  
  • Note: if this is more than visual tweak and ipfs:// becomes a real protocol handler, we get proper Origin-based separation per CID and can mark all IPFS pages loaded from local node as secure context

(2) Enable user to inspect transport details

Right now the default warning indicator for unencrypted http:// is displayed, and clicking on it shows this message:

Instead, an icon could indicate IPFS transport was used for loading the site:

Clicking on it could open small popup informing user about IPFS details.
Initially it could be info about the gateway we removed from address bar:

For the MVP just showing the URL of local gateway should be enough. In the future this popup could be a place that shows more details about the protocol, eg. include information about payload integrity, type of encrypted transports, state of peers, DHT (public/private) etc.

---

@bbondy @yrliou @autonome @olizilla

[RubenKelevra]

This is superseeded by recent changes in the IPFS-Daemon/IPFS-Plugin and can be closed. :)