3 ms·

In IPFS "the servers" aren't restricted to the original content hosts / large-scale CDNs / a single corp, so saying "the load is being transferred to the IPFS s

In IPFS "the servers" aren't restricted to the original content hosts / large-scale CDNs / a single corp, so saying "the load is being transferred to the IPFS servers" doesn't take into account the fact that you, your roommate, your neighbor, or 6K other people on the internet could be storing/serving this same data, helping compensate for increased load when accessing/re-accessing a spiking piece of content. There's still a ton of room for performance improvement here - but where this will really shine is not where Cloudflare and existing tools do great, but in the edge cases where a more resilient solution matters (be that for offline caching, local-first collaboration, or censorship resistance).

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...)

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...)