First off, I'm a developer working on IPFS for Protocol Labs. Let me try to answer some inaccuraties and questions from this blogpost, to clear any confusion.<p>> There is even the Beaker browser to help you surf IPFS<p>Beaker does not currently support IPFS, even though it used to in the beginning. We're hopeful Beaker might support IPFS once again in the future, but for now, Beaker just supports Dat.<p>> How common are petabyte or even gigabyte files on the Internet? There is definitely an increase in size trend due to the popularity of the multimedia files. But when will this become a pressing issue? It is not a pressing issue right now because CDNs help a lot for reducing traffic for the Internet. Also bandwidth is relatively easy to add compared to latency improvements<p>Bypassing the fact that centralized vs decentralized are fundamentally different models with different reliability, argueing that CDNs help with reducing traffic is just wrong. CDNs just moves the traffic from "your server -> your client" to "your server -> someones CDN -> your client", it doesn't actually reduce traffic. However, using a decentralized protocol like IPFS would actually reduce traffic, as closests nodes can help serve content and maybe clients would not need to contact your own IPFS node at all, if the data already exists in a closer node (at your ISP or even neighbor)<p>> For scalability, shard it, georeplicate it, and provide CDNs for reading. For fault-tolerance, slap Paxos on it, or use chain replication systems (where Paxos guards the chain configuration), or use the globe-spanning distributed datastores available today.<p>IPFS is actually a globe-spanning distributed datastore, so IPFS would be excellent choice if you're building a CDN. IPFS gives you the benefits you want for a CDN, scalable, content-addressed and used to passing around a lot of data.<p>> Case in point, Dropbox is logically-centralized but is very highly available and fault-tolerant, while serving to millions of users. Facebook is able to serve billions of users.<p>For now. In the future, who knows? The argument for using IPFS is that we don't know if a central server will be around in the future, but to make sure, let's add content-addressing to data so we can serve this data from anywhere. Then it doesn't matter if Dropbox is around in the future, I can just pull down the data from anywhere and verify it's correct locally.<p>> If you want to make the natural disaster tolerance argument to motivate the use of IPFS, good luck trying to use IPFS over landlines when power and ISPs are down, and good luck trying to form a multihop wireless ad hoc network over laptops using IPFS. Our only hope in a big natural disaster is cell towers and satellite communication.<p>Here the author is comparing a physical network with a software stack. Of course IPFS is not a antenna, so it'll be hard to use it as such. But, IPFS works excellent over radio and ad-hoc networks, because it's content-addressed. The current web? Not so well, as we have bunch of assumptions that the endpoints we're using are all serving us "good" content and that you have a server-client model. Ad-hoc networks are bandwidth-constrained, and everything we can do to reduce that bandwidth is worth doing. IPFS helps a lot with that since everything is content-addressed.<p>> Does IPFS mean I may be storing some illegal content originated by other users?<p>No, IPFS only shares what you already accessed (until GC) or when you explicitly "pin" something (basically tell IPFS you want to help share this content with others)<p>> How does IPFS deal with the volatility? Just closing laptops at night may cause unavailability under an unfortunate sequence of events. What is the appropriate number of replicas for a data to avoid this fate? Would we have to over-replicate to be conservative and provide availability?<p>This questions lead me to the belief that the author hasn't really understood IPFS before writing this post. Yes, shutting down your server will make content stored on that server unavailable. IPFS does not automatically distributed data. Just as your local HTTP server does not automatically distribute data to other servers.<p>> But can the Byzantine nodes somehow collude to cause data loss in the system, making the originator think the data is replicated, but then deleting this data? What other things can go wrong?<p>Again, other nodes can't control your data. If you add data to your IPFS node, it's there until you remove it. No other nodes can control your data. Also, data is fetched based on hashes and when the content is downloaded, it's verified again to make sure it's correct. No way of screwing around with that.<p>Happy to answer any more questions people have about IPFS.