IPFS badge broken on public gateways

[lidel]

Found this in brave-browser-nightly-1.23.32-linux-amd64 cc ipfs/in-web-browsers#64

People visiting a random public gateway should be able to open resources via their own node to ensure the integrity of downloaded data. Unfortunately it does not work yet: the badge is broken on gateways in 1.23.32 (nightly).

How to Reproduce

https://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi.ipfs.cf-ipfs.com/ shows:

Clicking on a badge opens an invalid URI:

(expected behavior in this case is to open ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi)

Underlying problem

I know we have a simple situation for DNSLink websites: when x-ipfs-path is present we swap the protocol from https to ipns and call it a day.

Unfortunately this does not work for non-DNSLink resources such as gateways.
I think we focused on DNSLink pages so much that we never discussed how non-DNSLink contexts like public gateways should be handled.

We need to ensure a reverse transformation to what is described in addressing guideline happens when the user clicks on the badge.

Proposed fix

For the sake of reducing complexity and future-proofing, Brave could tweak the badge logic to make things work on all types of gateways (path, subdomain, dnslink):

1. read content path value from x-ipfs-path header
2. remove first slash and replace second one with ://
3. append any ?queries or #fragments present in the original URL

To illustrate, assuming URL in address bar is https://{something}?query#fragment and HTTP response has x-ipfs-path header, the x-ipfs-path value → URI of tab to open after clicking on the badge mapping could look like this:

• /ipfs/{cid}/path → ipfs://{cid}/path?query#fragment
• /ipns/{libp2p-key}/path → ipns://{libp2p-key}/path?query#fragment
• /ipns/{dnslink-fqdn}/path → ipns://{dnslink-name}/path?query#fragment
  • This is especially nice: removes the need for Brave to do any conversion of {dns-safe-fqdn} because {dnslink-fqdn} in the header is already correct.
  • Test with this edge case: https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/

@spylogsster does this sound feasible?

[spylogsster]

@lidel yes, looks good, thanks for detailed clarification

[spylogsster]

@lidel what about 5xx when we resolve dnslink record?
for https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html we have dnslink=/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco
should it be ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Tokyo_National_Museum.html as a result?
It will be redirected to after navigation ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Tokyo_National_Museum.html

[lidel]

@spylogsster for DNSLink websites we always want human-readable ipns://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html in address bar, including the recovery logic for 5xx.

[stephendonner]

Verified PASSED using modified steps from the testplan in brave/brave-core#8254

Brave	1.24.12 Chromium: 89.0.4389.90 (Official Build) nightly (x86_64)
Revision	62eb262cdaae9ef819aadd778193781455ec7a49-refs/branch-heads/4389@{#1534}
OS	macOS Version 11.2.3 (Build 20D91)

case 1

1. loaded ipns://en.wikipedia-on-ipfs.org/wiki/Prime_Minister_of_New_Zealand.html#cite_note-11
2. clicked Use a local node to install and configure
3. waited for content to load

Verified that the anchor went to the right place in the viewport

case 2

1. loaded https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/Tokyo_National_Museum.html#cite_note-IAI05report11-3
2. waited for content to load

Verified that the anchor went to the right place in the viewport

case 3

1. loaded ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Tokyo_National_Museum.html#cite_note-IAI05report11-3
2. waited for content to load

Verified that the anchor went to the right place in the viewport

case 4

1. loaded https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
2. waited for content to load

Verified that the anchor went to the right place in the viewport

case 5

1. loaded https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html
2. clicked on https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
3. now, clicked on Open using IPFS button in the URL bar, which started loading ipns://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
4. waited for content to load

Verified that the anchor went to the right place in the viewport

case 6

1. loaded http://brantly.eth/#/privacy-policy
2. clicked on the button to resolve using Cloudflare's DNS servers for Ethereum domains
3. clicked on the button to Open using IPFS in the URL bar, which started loading ipns://brantly.eth/#/privacy-policy
4. waited for content to load

Verified that the anchor went to the right place in the viewport

Case 1	Case 2	Case 3	Case 4	Case 5	Case 6

[srirambv]

Removing Android label for now as we don't have option to load pages via local node

cc: @bbondy