IPFS badge broken on public gateways
See original GitHub issueFound this in
brave-browser-nightly-1.23.32-linux-amd64
cc https://github.com/ipfs/in-web-browsers/issues/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):
- read content path value from
x-ipfs-path
header - remove first slash and replace second one with
://
- 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/
- This is especially nice: removes the need for Brave to do any conversion of
@spylogsster does this sound feasible?
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (1 by maintainers)
Top GitHub Comments
Removing Android label for now as we don’t have option to load pages via local node
cc: @bbondy
Verified
PASSED
using modified steps from the testplan in https://github.com/brave/brave-core/pull/8254case 1
ipns://en.wikipedia-on-ipfs.org/wiki/Prime_Minister_of_New_Zealand.html#cite_note-11
Use a local node
to install and configureVerified that the anchor went to the right place in the viewport
case 2
https://en-wikipedia--on--ipfs-org.ipns.dweb.link/wiki/Tokyo_National_Museum.html#cite_note-IAI05report11-3
Verified that the anchor went to the right place in the viewport
case 3
ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Tokyo_National_Museum.html#cite_note-IAI05report11-3
Verified that the anchor went to the right place in the viewport
case 4
https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
Verified that the anchor went to the right place in the viewport
case 5
https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html
https://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
Open using IPFS
button in the URL bar, which started loadingipns://en.wikipedia-on-ipfs.org/wiki/Tokyo_National_Museum.html#cite_note-2
Verified that the anchor went to the right place in the viewport
case 6
http://brantly.eth/#/privacy-policy
Open using IPFS
in the URL bar, which started loadingipns://brantly.eth/#/privacy-policy
Verified that the anchor went to the right place in the viewport