Hello, everyone. I am writing this report as a user, and possibly it is out of scope of protocol itself; however, it seems that some part of user-facing infrastructure is in a defunct state due to breaking of some implicit assumptions.
Trustless way (for a web user) of interacting with IPFS is supposed to be an extension ipfs-companion. It is combined with a node (either through ipfs-desktop, or kubo), to enable natively opening ipfs links.
I am not aware of any other ways of ensuring trustlessness of ipfs links when browsing the web. There is a trustless gateway API, and verified-fetch library, but I am not sure if it is integrated into anything usable in browser (natural place to that would be ipfs-companion).
Behavior of ipfs-companion extension, currently is the following:
- It is able to detect ipfs:// links, and remap them to default gateways, such as dweb.link and ipfs.io.
- If you have an IPFS node running (using kubo, or ipfs-desktop), it will attempt to retrieve data from the public DHT.
- Otherwise, it will use specified gateway.
However, this has a problem: it assumes that data that is available on a public gateway is actually available on public DHT. This is not the case anymore.
Reproduction steps:
- Open literally almost anything (as a test example, here is some random soulbound NFT: https://dweb.link/ipfs/QmRPevngdAmN5ds61DSj3ffcQxauzkdhu3gAm21XswtEGe - I’ve also did checks with libraries such as libgen and other valuable usecases of IPFS). It will open.
- Fire up ipfs-companion and local node, open the same link. It does not open.
- Can also check availability here: IPFS Check if you don’t want to run the node by yourself.
What happens is that in fact, that “pinning services” (which do not actually pin data to public DHT) do serve the data to public gateways. Moreover, MOST data is served in this way. I think previously (maybe year ago?) gateways runners did share this data to public DHT, but now that have also stopped.
Effects of that is that it effectively “bricks” ipfs-companion: most of the content that is supposed to be on IPFS is actually inaccessible to ipfs-companion users, while being served on a web version (in a trusted manner).
What I think could be done:
- We probably should ask public gateway runners nicely to serve the data to DHT. This looks like a sensible intermediate step.
- Ipfs-companion should integrate verified-fetch and in case data is not found in public DHT fallback to trustless-gateway. This would at least recover verifiability for the end user - which is mission critical for Ethereum contract frontends.
- I am not sure could be done to steer ecosystem back to public DHT, it seems like a major design flaw that in long term means IPFS unmaking.
Overall, preserving at least verifiability for the end-user will be the best possible outcome, it seems.