Ipfs-companion: Intercept URLs for JS libs at public CDNs
Extracted from https://github.com/ipfs-shipyard/ipfs-companion/issues/570#issuecomment-421811923
Summary
Intercept URLs from public CDNs like unpkg.com and load them from IPFS.
Detection
Two ways:
- Seamless: work with CDN operators to expose assets on IPFS paths
/ipfs/<cid>/**/*.min.js - Grunt: identify the most popular assets across free CDNs, create a JSON mapping between filename/URL and CID and ship it with ipfs-companion as additional hint for creating redirects.
Additional Resources
- prior art
lidel
All 4 comments
Will this conflict with Decentraleyes or is the plan to deprecate Decentraleyes? If it is, will there be automagic pinning of the newest versions of the libraries?
(Possibly related https://github.com/ipfs-shipyard/ipfs-companion/issues/682)
Mikaela
on 2 Apr 2019
Good question. Decentraleyes is limited by the size of assets they can bundle with extension before it gets too big (resources/ directory).
Companion could improve on that by bundling only a small mapping file (but with much better coverage) and fetching the data from IPFS + pin/preload the most popular ones.
lidel
on 2 Apr 2019
Decentraleyes fork using IPFS:
https://www.reddit.com//r/ipfs/comments/hu7bij/a_fork_of_a_fork_of_the_web_extension/
autonome
on 20 Jul 2020
GitHub repo link to the Decentraleyes fork: https://github.com/IPFS-Forced-Adoption/IPFS-CDN
I will be following it with interest
Mikaela
on 21 Jul 2020
Related issues
lidel
路
5Comments
djdv
路
5Comments
lidel
路
5Comments
lidel
路
3Comments
lidel
路
5Comments
Most helpful comment
Good question. Decentraleyes is limited by the size of assets they can bundle with extension before it gets too big (
resources/directory).Companion could improve on that by bundling only a small mapping file (but with much better coverage) and fetching the data from IPFS + pin/preload the most popular ones.