8 ms·

> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker

> It's pretty much the same security model as regular web content, as you mention. 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.

zapita 9y ago
I completely agree that the file access APIs in Beaker are extremely cool, and solve a real developer problem. From a security point of view, it does slightly expand the attack surface, since there could be a vulnerability in that code which isn't present in other browsers. But given the simplicity of the APIs, I think it's a very acceptable risk given the benefits. The biggest downside IMO of these additional APIs is that they only work in Beaker. If I were the Beaker team I would prioritize making them available to mainstream browsers in some way: javascript library, browser extension, webassembly... It would really help adoption if they found a way to do that.
cutler 9y ago
I'm not getting this. Fine if you want to go back to the early 90s when sites were all static but what does this model offer for dynamic sites and in particular sites which are intended to scale beyond a single, home user box? How do I migrate my Rails app to dat/ipfs?
- allannienhuis 9y ago
  My understanding is that you can't - the use case isn't for dynamic websites - it's for static content. You could migrate your angular/react SPA (who's front-end is based off of static content), and continue to use the REST / WS services you already have, but not sure what the point of that would be. I think it's better to think of this more as a data store than web sites/apps.
  - carussell 9y ago
    This is not true. See the remarks about the DatArchive APIs in my original comment. You can also look at Fritter[1], which is a prototype Twitter clone built as a Dat web app. It's true that there are some types of web apps that exist on the traditional (HTTP) web but that cannot be made as a Dat app, but it's also true that there are a class of apps that could be built with Dat but that cannot be built on the traditional web. 1. dat://fritter.hashbase.io
swsieber 9y ago
No, you still need to host it yourself or pay somebody else to, otherwise it still has a chance of dissappearing... but I agree that it's much close to the literal interpretation of "serverless" (I personally don't mind the term because it seems rather defined at this point - an idiomatic label)

zapita 9y ago

I completely agree that the file access APIs in Beaker are extremely cool, and solve a real developer problem. From a security point of view, it does slightly expand the attack surface, since there could be a vulnerability in that code which isn't present in other browsers. But given the simplicity of the APIs, I think it's a very acceptable risk given the benefits. The biggest downside IMO of these additional APIs is that they only work in Beaker. If I were the Beaker team I would prioritize making them available to mainstream browsers in some way: javascript library, browser extension, webassembly... It would really help adoption if they found a way to do that.

cutler 9y ago

I'm not getting this. Fine if you want to go back to the early 90s when sites were all static but what does this model offer for dynamic sites and in particular sites which are intended to scale beyond a single, home user box? How do I migrate my Rails app to dat/ipfs?

allannienhuis 9y ago
My understanding is that you can't - the use case isn't for dynamic websites - it's for static content. You could migrate your angular/react SPA (who's front-end is based off of static content), and continue to use the REST / WS services you already have, but not sure what the point of that would be. I think it's better to think of this more as a data store than web sites/apps.
- carussell 9y ago
  This is not true. See the remarks about the DatArchive APIs in my original comment. You can also look at Fritter[1], which is a prototype Twitter clone built as a Dat web app. It's true that there are some types of web apps that exist on the traditional (HTTP) web but that cannot be made as a Dat app, but it's also true that there are a class of apps that could be built with Dat but that cannot be built on the traditional web. 1. dat://fritter.hashbase.io

swsieber 9y ago

No, you still need to host it yourself or pay somebody else to, otherwise it still has a chance of dissappearing... but I agree that it's much close to the literal interpretation of "serverless" (I personally don't mind the term because it seems rather defined at this point - an idiomatic label)