So you want your decentralized browser to work correctly

By Paul Frazee and Tara Vancil, the Beaker browser team

Yesterday, Tom MacWright wrote “So you want to decentralize your website”. It’s a thoughtful and detailed review of what it’s like to publish a website on the Dat network using the Beaker browser, and we recommend it to anyone interested in decentralized publishing.

Tom’s post is right on the mark. He clearly understands the goals, the problems, and the properties of Beaker and Dat.

We want to respond to some of the problems he highlighted, to affirm that he sees the situation correctly, and explain why these problems exist and how we plan to solve them.

What happens if your computer explodes?

Dat & Beaker both have plenty of documentation for how to publish, but not very much in terms of how to continue publishing. If your computer explodes, how do you publish your hot new blog post?

As Tom explains, each Dat website has a private key which endows its owner the ability to write to that website. If you lose the private key, you lose the power to publish.

Hope you have a backup

We don’t currently have a good flow for backing up your keys, and Tom intuited why:

There’s a pretty good reason why both Dat and Beaker are sketchy about describing keys: right now, you can kind of break it if you try to write to the same Dat from two computers. So, if you were to share your secret keys, you could make bad things happen.

Dat uses an append-only log to publish updates to websites. The append-only constraint is an important security feature: it prevents authors from delivering targeted payloads on the network, and makes sure that every node receives the same content. (Read this blog post to understand why.)

This append-only constraint is a critical piece of what makes peer-to-peer publishing safe on the Dat network. But even if you accidentally publish conflicting updates, the protocol will treat you as a bad actor and will stop distributing your Dat website.

We don’t yet have a solution for handling accidents gracefully, so to prevent it from happening in the first place, we’ve been hiding the private keys from users.

We’re not happy with this solution, so key management won’t be hidden from Beaker users for long.

It’s been hard, but we’ve been hiding all these keys.

How will we solve key management?

1. We will add tool for exporting keys, so that users can back up their private keys. Hiding the keys doesn’t work in the long term.
2. mafintosh is working on a protocol improvement that will allow multiple computers/users to author a Dat archive. This “multi-writer” feature will allow multiple computers to each maintain an append-only log, and then to merge the logs later. This makes it possible for multiple computers to author changes, but doesn’t protect you from corruption if you reuse a keypair on multiple devices.
3. Ultimately we need safeguards, key-distribution, and device-pairing protocols. The goal is “It Just Works,” and it’ll take us some time, but we’ll get there.

Beaker’s strict CSP

…It’s my blog post about a trip to Cuba: here it is on HTTPS. You’ll notice that the version hosted on Dat doesn’t have any images or embeds available. That’s by design: Beaker Browser enforces a strict Content Security Policy:

Beaker enforces a fairly strict Content Security Policy for websites published with the dat:// protocol.

default-src 'self' dat: blob:;
script-src 'self' 'unsafe-eval' 'unsafe-inline' dat: blob:;
style-src 'self' 'unsafe-inline' dat: blob:;
img-src 'self' data: dat:  blob:;
font-src 'self' data: dat:  blob:;
media-src 'self' dat:  blob:;
connect-src 'self' dat:;
object-src 'none';

We use a strict CSP so that you can’t access https:// resources on dat:// websites unless you ask the user for permission first. We have two motivations for doing this:

1. If you only access dat:// resources, it makes it possible to use Beaker’s “save for offline use” feature so your website will still work offline.
2. If you can’t send network requests to specific http/https endpoints, then it becomes much harder to track user activity.

We’re on the fence about whether Beaker’s CSP is too strict. We’ve seen nearly every new Beaker user get burned by the CSP, and it’s not clear yet whether the above two goals will be fulfilled by a strict CSP.

Beaker’s CSP is under active discussion, and we’d especially like to hear developers’ feedback. We want to get this right, so if you have a strong opinion about how https:// network requests should work on the decentralized Web, please let us know!

Strict CSPs have pros and cons, so we’re open to your opinions.

Why Dat instead of IPFS?

Compared to IPFS, for instance, hosting websites is at best the third-highest priority for the Dat project. It makes sense that IPFS is the choice of NeoCities: IPFS is pretty clearly intended to be a replacement for the internet.

Tom isn’t asking why we chose Dat, but some people do and often point to the reason Tom gave, so we want to respond with some details.

First let us observe that Beaker and Dat are two different organizations: Beaker is developed by Blue Link Labs, a Delaware C-corp, and Dat is developed by Code for Science, a 501(c)(3) non-profit. This explains, to some extent, the focus of the Dat Project’s website: it wasn’t originally created to be a browser protocol. Beaker adopted it for that purpose, and Dat has been very supportive of our use case.

So Dat, the protocol, may not have been designed to replace the Internet as we know it, but those of us working on Beaker have adopted it entirely with that vision in mind.

The UX problem of two protocols

Dat and IPFS are both superb technologies, and we’d be happy using either in Beaker. We’ve debated this choice with Kyle a couple of times now, and we actually think he made the right choice for NeoCities, but we made the right choice for Beaker.

One thing you should be sure of is, we wouldn’t have chosen Dat if we didn’t think it’d be a great choice for a browser protocol.

The key challenge comes down to user experience. It’d be great to support both protocols, but how on earth would we explain that to a new user who doesn’t care? You end up with a flow like this:

User: I’d like to make a new website, please.

Beaker: Splendid! Would you like to use Dat or IPFS?

User: Uh, what’s the difference?

Beaker: Well, one has a focus on static hash-addressed bundles, while the other is focused on dynamic public-key-addressed archives, but TBH both can do either! ¯\_(ツ)_/¯

Yeah. If somebody can come up with a way to explain it to users, we’ll consider adding IPFS, but you also have to consider the overhead of a second p2p networking stack, and the development time for supporting a second networking stack… etc. We don’t see the benefit yet.

Honestly, Neo, both pills are pretty similar, but I’d go with red because I like that color.

Design disagreements

So, why did we choose Dat instead of IPFS? This is a bit like debating between chocolate and strawberry ice cream: they’re both tasty, but if you buy both you’ll end up with a fat browser. So here are the nits we had to pick:

• NURIs. IPFS uses a URL format called “Nested URIs,” or “Path addressing”. We disagree with the premise of the format, and we disagree with the work it would require to support it (which is much more than you’d think; URLs are security primitives as well as UI elements). Protocol Labs now has a roadmap to temporarily use the standard URL form, but they refused to budge on this when we were making the decision 6 months ago — and we only needed one protocol!
• Blockchains. One of the hardest parts of building Beaker is deciding what stack is required to build peer-to-peer applications. We don’t think a blockchain is necessary to achieve our goals. Moreover, we think blockchains are inefficient, and we have ethical concerns about the ecological impact of PoW. IPFS has saddled itself firmly in the blockchain camp, and its team is developing their own blockchain technology, Filecoin. Filecoin is a cool concept, but in the long run, we don’t think an automated market for disk space will provide much value beyond what a non-blockchain solution can provide. Credit where it’s due, Protocol Labs is working hard to make Filecoin provide immediate benefit and stay within the law.
• Dynamism. Dat is designed primarily for mutable public-key-addressed archives, and it uses the append-only log structure to distribute updates. The append-only structure is inspired by Certificate Transparency’s own log protocol, and we think the auditability is important for securely distributing application software. IPFS’s mutable archives are simply a signed hash with no protocol enforcement of append-only distribution, which consider insufficient. Ironic, yes, since that constraint is now creating usability problems for us — but we believe that’s a temporary issue.

And no, you can’t just have a Neapolitan, you heathen!

Wrapping up

Thanks again to Tom for such a great writeup. We’ll keep grinding and working on the issues he raised. Salut!