I'm really excited to see what the future holds for IPFS! However, hosting websites with custom domains is not quite feasible yet. Using IPFS' DNS (IPNS) means you have to keep the IPFS daemon running constantly, or else the files will be purged within an hour.
> However, hosting websites with custom domains is not quite feasible yet
Sure, point your domain to your IPFS hash and use dnslink, it's quite reliable already actually. That's how ipfs.io is hosted for example, and we haven't hit any issues so far.
> Using IPFS' DNS (IPNS) means you have to keep the IPFS daemon running constantly, or else the files will be purged within an hour
So, the files won't be purged, but the record you push out with IPNS won't be valid after 24 hours. You can solve this easily by using /ipfs/:hash instead of /ipns/:id and it wont disappear.
Yet again I failed to include important details...
:p
Yeah, it certainly is possible to host static sites on IPFS -- I have been testing it on my site[0] just for kicks. However, since I really enjoy using my domain name, rather than "ipfs.io/ip{f|n}s/$hash", I'm reluctant to try adapting my site to IPFS. I am aware that this is an alpha product, though, and I can't stress enough how cool it is for files containing the same data to be given the same ID (hash). That way you don't have to run shasum ever again :D
The HTTP gateway included in go-ipfs will try to use a Host header on requests for constructing an /ipns path. So e.g. http://ipfs.io/docs gets turned into /ipns/ipfs.io/docs -- this is actually how we host all webpages within the ipfs project.
edit: And the part which turns /ipns/ipfs.io into an /ipfs path is called dnslink: https://github.com/ipfs/go-dnslink -- it resolves to what's in TXT _dnslink.ipfs.io.
> (on a random note: what's up with /blog returning the IPFS blog, instead of my own content? did i misconfigure something?)
I'm so sorry, that's a bug I put into the nginx configuration -- will fix it!
