Open interfect opened 8 years ago
I think adding a configuration option where user can provide a list of domains from which https?://<domain>/ipfs/
is redirected to the local gateway is a better idea.
That way not only ipfs.pics
is supported, but any other site.
make sense to me.
want to point out --though-- that:
ipfs.pics/<hash> != ipfs.io/ipfs/<hash>
See:
the ipfs.pics server returns the ipfs.pics UI in the same page. I would probably build it with URIs like this:
So the app is always returned, and the parameter is fed to the app directly via the URI hash (or query string params).
though yeah, hash-links are really annoying... maybe we can come up with some way to make ipfs implementations understand that a url like:
/<rest>
could be /ipfs/<hash>
)means
/<rest>
to that app.maybe we could establish a convention of defining apps such that ipfs implementations know to load a resource and feed "the rest of the path" to the app? (the same way that unix file systems will defer to a filesystem implementation mounted at a particular mount point, and feed the rest of the path to that, or the way that url routers in servers (or single page webapps) work)
maybe continue that part of the discussion here https://github.com/ipfs/notes/issues/73
Even with current design of ipfs.pics
we can fetch images from IPFS.
Look at the actual, direct URL of a single image -- It is what we expect:
<img src="//ipfs.pics/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3" class="picture">
Which gives:
ipfs.pics/ipfs/<hash> == ipfs.io/ipfs/<hash>
FYI I added ipfs.pics
to the list of known public IPFS gateways in ipfs-firefox-addon v1.3.1
To be precise, the implementation in my addon is that only URLs matching
<one-of-whitelisted-gateway-hosts>/ipfs/<hash>
are redirected to a local gateway
oh nice
Can you make the actual image urls from ipfs.pics go through the local gateway instead?