Skip to content

Instantly share code, notes, and snippets.

Last active Oct 26, 2017
What would you like to do?
Musings on BeakerBrowser compatibility

Browser should respect /dat.json

  • It's JSON so it's easy to parse

So far the fields in dat.json are:

.url The URL of the archive.

  • Need clarification on what the defined behavior is. Should I throw an error if the URL used to download the site and the URL specified here don't match?
  • Thought: role kind of overlaps with a CNAME file. But CNAME is for DNS and not dat URLs.

.title A short but descriptive human friendly title.

.description A one- or two-line description of the archive.

  • I can't foresee any problems supporting these two.

Wait a sec... One of the requirements of being a Progressive Web App is to have a Web App Manifest file. There's definitely redundancy here.

dat.json Web App Manifest
filename convention dat.json filename set in a <link rel="manifest"> header tag
name, short_name title
description description
url see below

I think that the dat://... URL would actually fit canonically into the related_applications field. The syntax for that is:

"related_applications": [
    "platform": "play",
    "url": "",
    "id": "com.example.app1",
    "min_version": "2",
    "fingerprints": [
        "type": "sha256_cert",
        "value": "92:5A:39:05:C5:B9:EA:BC:71:48:5F:F2"
    "platform": "itunes",
    "url": ""

so I think a good version for Beaker & friends might be:

"related_applications": [
    "platform": "beaker",
    "url": "dat://123456789"

That said, there are thankfully no conflicts between the PWA requirement and the current Beaker requirement. Redundancy is a burden to update and maintain but not a technical obstacle to compatibility! Hurray!

.fallback_page The path for the page to serve when a user hits a 404. (See this demo gif.)

.web_root The path of the folder which all requests should be served from. (See this demo gif.)

  • Here I'm worried we're starting to see a home-grown static-site-routing solution.
  • but if it stays at only two or four things then 100% compatibility shouldn't be a challenge


  • fallback_page and web_root are routing directives, no? Will these configs grow into a monster of more and more settings? I looked at several static site hosts to see if a more powerful general-purpose solution exists. Unfortunately there are several competing schemes for defining "static site routing".

Surge uses a combination of files + custom formats.

  • 404.html
  • 200.html (for single page apps)
  • ROUTER (eww... not JSON :( )
  • CORS (newline delimited list of domains)

Firebase uses firebase.json to do redirects and routing and set custom headers.

"redirects": [ {
  "source" : "/foo",
  "destination" : "/bar",
  "type" : 301
}, {
  "source" : "/firebase/*",
  "destination" : "",
  "type" : 302
} ]

Now uses rules.json to do routing.

"rules": [
  { "pathname": "/api/register", "methods": ["POST"], "dest": "" },
  { "pathname": "/api/**", "methods": ["GET", "POST"], "dest": "" },
  { "dest": "" }

Browser must have a global DatArchive object.

I think these ones could be supported in a client-side script using BrowserFS

  • new DatArchive(url)
  • DatArchive.create(opts?)
  • DatArchive.fork(url, opts?)
  • DatArchive.selectArchive(opts?)
  • DatArchive.resolveName(url)
  • url
  • getInfo(opts?)
  • stat(path, opts?)
  • readFile(path, opts?)
  • readdir(path, opts?)
  • writeFile(path, data, opts?)
  • mkdir(path)
  • unlink(path)
  • rmdir(path, opts?)
  • diff(opts?)
  • commit()
  • revert()
  • history(opts?)
  • download(path, opts?)
  • createFileActivityStream(pattern?)
  • createNetworkActivityStream()

so the challenge is the remaining API methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment