Musings on BeakerBrowser compatibility

dat.json.md

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" }
]

DatArchive.md

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.