0.6.0: UX improvements

0.6.0: UX improvements

Excited for a new release, folks!

A big part of this release was about improving the UX. We’re thinking very specifically about how we want Beaker, as a product, to work. We took inspiration from a lot of different products, including CodePen, GitHub, and even iTunes.

The other major half of this release was making fixes to the Dat protocol. We’ve improved our debugging techniques, and found some key issues that we’ve patched.

New navbar

When you’re on a Dat site, you now will see a bunch of new buttons in the URL bar. Most of these functions already existed, but they were hidden away behind two clicks (or more). We realized, despite the UI clutter, it’s much better to have these tools easy to access and discover.

The Save button adds the site to your Library, where it stays for offline access and serves itself on the p2p network. If you like a site, and want to keep it forever, that’s the button for you. For simplicity’s sake, we’ve also decided that saving a site makes Beaker serve it too. (We’ll keep evaluating that choice as we go.)

The Fork button lets you create a new copy of the site, under your control, which you can modify and share. That’s the foundation of our goal for a more participatory Web, and we wanted it to be right there for you to use.

Live-reloading is insanely handy when you’re doing site-development. I now author static sites by running bkr dev in a new directory to spawn a temporary, file-watching dat. Then I turn on live reloading and start writing the html/css/js. It’s really nice. (You can get bkr via npm,

New Sites Library

We were never very happy with the old saved-sites interface, so when we decided to make some UX improvements, we took the opportunity to overhaul the interface entirely. Somewhere along the way we discovered whitespace and thin fonts, and the new Sites Library is the result of that.

Fixes to the Dat Protocol

We had a couple of sneaky issues that, I’m happy to say, have been solved.

The two most significant issues we discovered had to do with swarm-discovery, which I had mis-implemented in Beaker, and replication, which was failing due to an mistake in the protocol itself. The latter took some serious debugging, and resulted in a solution called “read-verification on replication.”

Each of these commits include a long message explaining them, in detail:

We’ll keep working on Dat’s reliability, and we should be releasing a self-deployable Dat hosting server soon to help with uptime.

Other Changes

« All posts