Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ipfs.pics support? #10

Open
interfect opened this issue Nov 21, 2015 · 6 comments
Open

ipfs.pics support? #10

interfect opened this issue Nov 21, 2015 · 6 comments

Comments

@interfect
Copy link

Can you make the actual image urls from ipfs.pics go through the local gateway instead?

@lidel
Copy link

lidel commented Nov 22, 2015

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.

@jbenet
Copy link

jbenet commented Dec 1, 2015

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:

  • /ipns/ipfs.pics/view#/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3
  • /dns/ipfs.pics/#/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3

So the app is always returned, and the parameter is fed to the app directly via the URI hash (or query string params).

@jbenet
Copy link

jbenet commented Dec 1, 2015

though yeah, hash-links are really annoying... maybe we can come up with some way to make ipfs implementations understand that a url like:

  • /dns/ipfs.pics/view/ (where /<rest> could be /ipfs/<hash>)

means

  • use the app at /dns/ipfs.pics/view
  • feed /<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)

@jbenet
Copy link

jbenet commented Dec 1, 2015

maybe continue that part of the discussion here ipfs/notes#73

@lidel
Copy link

lidel commented Dec 2, 2015

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

@jbenet
Copy link

jbenet commented Dec 2, 2015

oh nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants