the gateless gate （無門関）

[Mithgol]

If a web site uses IPFS hashes as the names of some of its files (especially in the /ipfs/ path from the root), such site (as discussed in #92) should probably be detected as an IPFS gateway.

But what if such a web site merely uses IPFS multihashes to name its files (for example, using multer to decode an uploaded file and then using multi-hash to determine its IPFS hash and rename that file) without being an IPFS gate in the stricter sense (i.e. without publishing these files to the IPFS filesystem afterwards)?

Why that site would do that? — well, because, for example,

• it needs some unique names for files anyway, so why not IPFS multihashes,
• on the other hand, configuring and running an IPFS gateway is more complex (requires more memory, more traffic, more configuration…) and thus it might be avoided.

What would happen then?

• When such site's files are common (i.e. we can reasonably expect them to be previously shared in IPFS), then detecting and rerouting these addresses to a local IPFS gate (as discussed in Recognize IPFS gateways on arbitrary websites #92) would theoretically be benefitial in many ways (for example, speed up the access).
• When such site's files are unique (i.e. we can reasonably expect that they aren't in IPFS yet), then detecting and rerouting these addresses to a local IPFS gate (as discussed in Recognize IPFS gateways on arbitrary websites #92) would fail (i.e. the rerouted browser would wait for a long time and even then won't get the file eventually).

When the site does not run an IPFS daemon, it cannot differentiate between these two cases.

However, could such site give some signal to the rerouting clients (Firefox addon, Chrome extension, etc.) telling them that they may hope for the former case but should still have some fear of the latter case?

Such signal might mean, for example,

• that it's okay to try two concurrent downloads simultaneously (one from the site and one from the local gate) and use the one that would yield the complete file faster,
• that it's okay to publish the file (downloaded from the site) to IPFS (through the local gate) if it's not there yet.

For unique files that should cause some form of web seeding to IPFS (it might require some complex bandwidth throttling such as BitTorrent's BEP 17, it might also be as simple as BitTorrent's BEP 19).

[lidel]

I feel this belongs to this discussion:
@haadcode created PoC that uses manual URL hint to opportunistically redirect downloads to IPFS: whyrusleeping/ipfs-webext#1
(This is something I already mentioned in ipfs/ipfs-companion#16 (comment))

[lidel]

I've just found RFC 6249: Metalink/HTTP: Mirrors and Hashes.
It defines a way to provide all the Metalink info in HTTP headers instead of XML:

Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby; type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby; type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby; type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlODYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==

The "IPFS signal" could be as simple as:

Link: <https://ipfs.io/ipfs/QmVFUNn2dBhy6USZ3Mup8d1HSstjUw4CtWwNxGHAWvdyRy>; rel=duplicate

In theory, browser add-ons (Firefox, Chrome) could then detect this signal during onHeadersReceived event, initiate parallel download or abort and replace response with redirect to local gateway, or add resource to local IPFS cache.

[lidel]

Latest version of our browser extension (ipfs-companion) performs path validation followed with opportunistic redirect to local gateway on every website: ipfs/ipfs-companion#16 (comment)