Skip to content

Instantly share code, notes, and snippets.

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

Browser should respect /dat.json https://beakerbrowser.com/docs/apis/manifest.html

  • 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": "https://play.google.com/store/apps/details?id=com.example.app1",
    "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": "https://itunes.apple.com/app/example-app1/id123456789"
  }
]

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

Footnotes:

  • 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" : "https://www.firebase.com",
  "type" : 302
} ]

Now uses rules.json to do routing.

"rules": [
  { "pathname": "/api/register", "methods": ["POST"], "dest": "api-register-wcepelgodl.now.sh" },
  { "pathname": "/api/**", "methods": ["GET", "POST"], "dest": "api-tuhpdtgoja-now.sh" },
  { "dest": "ui-dbuyejqwio.now.sh" }
]

Browser must have a global DatArchive object. https://beakerbrowser.com/docs/apis/dat.html

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