But that only works for static data?

ignitionmonkey · on April 16, 2018

I think most websites can be generated statically. But yes, it does mean a lot of the existing patterns used on the current web needs to be redesigned for it. Again, this is all very new so there's a lot that needs to be worked out.

I can give an example of non-static data (though what is static vs dynamic can be a grey area):

SPAs work great with Beaker/Dat since users can download the app and use it offline. The data can be any Dat archive. So for a social network, each user can have their own Dat archives of images and posts. The root site can hold an index of each user and download individual files from their Dat and display them using client-side routing. In this scenario, each user has their own database as a Dat which is indexed by a parent Dat website.

Demo, a Twitter clone: https://github.com/beakerbrowser/fritter

Also, at the end of the day, they are still websites. So you can still use a central HTTP server to:

- Serve your data directly

- Provide an API to edit your Dat archive instead of distributing it into multiple user-owned archives.

It also means you don't need to migrate a website to a completely different paradigm in one big bang.

pfraze · on April 16, 2018

Dats aren't static. They're public key addressed, so you can make changes. The next protocol iteration will have support for multiple writers using CRDTs (sometime this summer).

staticvar · on April 16, 2018

Web apps can read / write existing Dat archives and new Dat archives from Beaker Browser using the Dat Archive API. https://beakerbrowser.com/docs/apis/dat.html

Myself and others are currently volunteering to help bring the Dat Archive API to Bunsen Browser, a mobile Dat Web client currently only for Android (unless someone wants to jump in and make the build for iOS).