> Is this one of those things that has mostly disturbing illegal content, drugs, and fringe political stuff on it?

Disturbing, illegal content often relies on encryption (to hide what's going on) and/or anonymity (to hide who's doing it). IPFS isn't about either of those: if you serve something over IPFS, anyone can fetch it and anyone can see that you're serving it. Presumably encryption and anonymisation can be layered on top of this, by those who want it (just like TOR does for normal Web).

The main point of IPFS is content-based addressing: serving a file, like a Web page, via IPFS gives it a URL automatically, which is just the cryptographic hash of that file. This means that:

- Multiple people serving the same file on to IPFS will be serving the same URL

- Anyone trying to fetch a URL can get the file from anyone that's serving it

- Serving a different file (e.g. updating the latest stories on a news page) will end up with a different URL

On the normal HTTP Web, each URL is a request which refers to a particular machine (usually via a domain name which is associated to one or more IP addresses). When we fetch a URL (e.g. example.com/cat.jpeg) on the normal Web, we're relying on that machine (e.g. example.com) to exist, we're relying on it knowing/understanding the request (e.g. cat.jpeg) and we're relying on the result to be what we expected (e.g. a particular picture of a cat). Those expectations can be violated at any point, e.g. the server may respond with some porn rather than the cute cat picture it gave us yesterday. What's worse is that, if something goes wrong (e.g. a domain expires, some URL becomes a 404 due to deletions or changing the server software, etc.), nobody else is able to fix it: we're able to serve copies of content, at different addresses (e.g. like the Internet Archive does), but users must manually seek out those copies, and have no way of knowing if they're real.

With IPFS, anyone can choose to serve files that they're interested in. Anyone can serve their own blog on IPFS, but readers of the blog can also serve it; that way, even if the author disappears or their server explodes, anyone fetching those URLs will still get the content they wanted (they would just so happen to be getting it from the readers rather than the author). Since URLs contain a hash of the content, it's trivial to check if the fetched content is correct: just hash it and compare against the URL (IPFS might do this automatically, I'm not sure).

I like the idea of hosting my blog and git repos on IPFS because it's more resilient than a HTTP server. I currently have a VPS dedicated to serving HTTP, even though most of that server's capabilities are wasted since it requires hardly any resources. Yet I daren't use it for anything else, since any breakages will take my Web site offline. The same single-point-of-failure applies to reverse proxies, load balancers and other such HTTP endpoints.

On the other hand, I can stick an IPFS daemon on a few different computers and have them all able to serve up those files in the background, whilst I use them for other tasks like gaming, writing, home servers, etc. If any of them falls over, my IPFS site doesn't care. I even had my laptop serving my Web site via IPFS, which was suspended when travelling to and from my office; that would be unthinkable for a HTTP site's availability.

Unfortunately the main IPFS implementation is currently too resource-intensive for me to keep this up. Running it on a RaspberryPi was difficult and it slowed my normal laptop down noticably, so for now I've stopped running the daemon. I keep an eye on new releases and bug reports about resource usage, so maybe it will become more usable soon :)