-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
I think adding a configuration option where user can provide a list of domains from which That way not only |
make sense to me. want to point out --though-- that:
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:
means
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 ipfs/notes#73 |
Even with current design of <img src="//ipfs.pics/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3" class="picture"> Which gives:
FYI I added To be precise, the implementation in my addon is that only URLs matching
are redirected to a local gateway |
oh nice |
Can you make the actual image urls from ipfs.pics go through the local gateway instead?
The text was updated successfully, but these errors were encountered: