3 ms·

Sure, it is possible that IPFS would spread out the usage across the other users, and this could still work for people bypassing Cloudflare. But there's no demo

by joecot 7y ago

Sure, it is possible that IPFS would spread out the usage across the other users, and this could still work for people bypassing Cloudflare. But there's no demonstration here of that really working. Just that Cloudflare is really great at what it does. And yes, it's a chicken/egg scenario -- how do you prove that IPFS adoption would negate the need for CDNs, without widespread IPFS adoption? But currently this isn't some amazing Slashdot proof solution. They needed to setup 3 servers and a whole bunch of software when a single server + free CDN would've accomplished the same thing, faster and cheaper. It's presented as though CDN+IPFS is why this works so great, when really it's just CDN and IPFS just makes it more complicated. If the goal is to learn, try out new tech, break dependence on CDNs, then this is great, but a single note in the article that this is a learning opportunity and it can be done easier without IPFS would've saved the author a lot of back and forth in the comments here.

momack2 7y ago
Valid point - I'm a huge consumer of posts where people experiment with new solutions and share it back with the community (like the author's other blog post on how to set up static website hosting with IPFS: http://127.0.0.1:8080/ipns/withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-works-and-scales.html http://127.0.0.1:8080/ipns/withblue.ink/2019/03/20/hugo-and-... ), so I think we should generally encourage/support this sort of experimentation and documentation. But I agree the timing here is likely coincidence - the IPFS component is likely more for learning/experimentation/resiliency than specifically for the described performance gains. (Unless a large portion of users are browsing with IPFS Companion: https://chrome.google.com/webstore/detail/ipfs-companion/nibjojkomfdiaoajekhjakgkdhaomnch https://chrome.google.com/webstore/detail/ipfs-companion/nib... | https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/ https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...)

by joecot 7y ago

momack2 7y ago

Valid point - I'm a huge consumer of posts where people experiment with new solutions and share it back with the community (like the author's other blog post on how to set up static website hosting with IPFS: http://127.0.0.1:8080/ipns/withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-works-and-scales.html http://127.0.0.1:8080/ipns/withblue.ink/2019/03/20/hugo-and-... ), so I think we should generally encourage/support this sort of experimentation and documentation. But I agree the timing here is likely coincidence - the IPFS component is likely more for learning/experimentation/resiliency than specifically for the described performance gains. (Unless a large portion of users are browsing with IPFS Companion: https://chrome.google.com/webstore/detail/ipfs-companion/nibjojkomfdiaoajekhjakgkdhaomnch https://chrome.google.com/webstore/detail/ipfs-companion/nib... | https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/ https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...)