Today, IPFS stands out as the predominant decentralized network for hosting dapp frontends and static assets, such as NFT images. Nevertheless, users commonly retrieve these CIDs from trusted gateways with browsers without verifying. This undermines the benefits of verifiablity in IPFS, as users place implicit trust in gateways, leaving them vulnerable to various attacks.
The challenge of verifying CIDs within the browser context varies depending on what the CID is. It proves more straightforward to verify static assets like images and JSON compared to verifying the CID of a frontend. In the case of a frontend's CID, the only viable method involves running a separate IPFS node that exposes a gateway for verification purposes.
@helia/verified-fetch
for verified in-browser retrieval of CIDs with better DX
ipfs.io
, trustless-gateway.link
, cloudflare-ipfs.com
or self hosted.@helia/verified-fetch
@helia/verified-fetch
127.0.0.1
was blocked but localhost
allowed on some browsers, subdomains on localhost
weren't allowed at the time we were working on subdomains but are now; one of the workarounds is clever management of subdomains of subdomains.add --cid-version 1 -Q -n
bafkreibel3v5edjm2tebwxkkyj6hg5dcph2dnvrph32syrjkg2pg555wca
ipfs routing findprovs bafkreibel3v5edjm2tebwxkkyj6hg5dcph2dnvrph32syrjkg2pg555wca → relay providers
dweb.link
.inbrowser.dev
WIP: Problems with DNSLink leading to problems loading the "loader", i.e. the SW gatewayinbrowser.dev
.
chrome.debugging
? Example, why isn't everyone struggling with the move from blocking requests in MV3 doing this?fetch
from Iceland 2022 https://www.youtube.com/watch?v=_omtM02_uYw