Never having used or looked into Beaker, dat, ipfs, etc, some immediate questions about security implications come to mind: 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? if not, or something more dynamic please advise). So, are there security implications here? Is there…
> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is…
I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself.
It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for example, that includes some tests/runner.html. You could open it Firefox to run the automated tests, but Chrome will choke on it because Chrome doesn't allow XHR for file:// URIs. The only way around this is to either put it online or run a local webserver (e.g., `python -m SimpleHTTPServer`) and access it through localhost. This is perverse. Dat is solving this in a way that's very similar to what would happen if file:// got first-class attention from the browser makers. If it's in a Dat, it doesn't actually matter if it's on your computer or hosted somewhere. All that matters is that you have the content.
This might not be exciting to HN types who are comfortable and willing to go rent some DigitalOcean instance and put up with administering it, but this will have a huge impact on the long tail of businesses—both small and large—that are quietly chugging along on little more than Excel and email (maybe the odd SharePoint installation).
On the other hand, developers should be excited about this, too, because it means they can start building apps that are _actually_ serverless (compared to Amazon and Google's definition). We're back to where we were in the 90s: you can go write some neat client software and share it with me, without having to think about the headache of needing to run a server in perpetuity just so that it can continue being useful.