Hostless applications, using the dat:// protocol

[pfrazee]

Overview

Sites can be served in Beaker using dat://. Some facts about the protocol:

• Beaker supports DNS lookup for dat links. So, you can have dat://{dns_name} or dat://{hash}.
• On load, if there is an index.html in the dat archive, it will be displayed.
• The URL scheme will support versions: dat://{hash_or_name}/{path}@{version}#{...}
  • Example: dat://pauls-js.com/explorer.js@3.0.0
  • 3 kinds of version tags:
    • The change version, which is hyperdrive's internal version counter. That looks like @c{num}.
    • The hash of a version, which looks like @{hash}
    • A semver, which looks like @{maj}.{min}.{patch}.

dat:// will be a "hostless app protocol" for Beaker. Hostless apps will work differently than hosted apps, and get more privileges. Only hostless apps will get access to the client-side protocols which Beaker is adding.

The intent of hostless apps

Hostless apps are self-contained programs. Their assets are served by peer-to-peer networks, instead of by hosts, and they are integrity- and signature-checked for security. User data is stored on-device, by default, and confidential information should be encrypted end-to-end. Ideally, any point-to-point communication should occur between devices, without servers. Services, however, may be used with permission.

Security basics

The dat URL has an authority tuple of ["dat:", hash]. The policies and sandboxes will be applied to that authority. If the dat is loaded with a DNS name, the name will be resolved to a hash prior to setting policies.

Hostless apps are expected to handle secrets and privileged resources. They will be served with strict CSPs to prevent injections. A hostless app has to ask permission for new Beaker APIs and for the network; by default, an app can only access sandboxed JS APIs, and the assets within its own archive.

App updates

By default, updates to the dat will be automatically installed. The user can view the version history, and choose to revert to a past version. The user can also choose to be prompted before running updates.

New APIs

Hostless apps should be self-sufficient, and capable of (almost) anything an electron-based desktop app can do. They wont be able to bundle native modules, so Beaker will need to provide their platform of APIs.

Beaker's first 5 APIs will be:

• sqlite3
• fs
• libsodium
• secret/key storage
• dat

These 5 will handle data-modeling, data-storage, p2p data-publishing, and all basic cryptography. In the future, we'll explore integrating APIs for an identity system, payments, async push-messaging, and async push-mail.

TODOs and open questions

App update events

Should there be a JS API for the application to handle upgrades and downgrades to the application? For instance, suppose the user moves from 2.0.0 to 3.0.0 -- or 3.0.0 to 2.0.0. There may be data schemas to change. And, if handled poorly, there could be data loss. Applications may benefit from builtin migration events, to handle this.

User data control

The dat apps will create files, SQLite databases, dat archives, and other artifacts, which the user may want to export and share within other contexts. How should we handle this? Should the browser/apps have a toolset for users to configure the paths of an app?

FS api

The node community has had a lot of time to consider how a browser-based fs api should work. What are those thoughts now?

DNS changes

If the dat app is loaded via a DNS name, and the registered hash is changed, how should Beaker react to this? Should it alert the user, that a wholly new app has been put there? How can the user get back to their old app?

cc @mafintosh @maxogden @Karissa

[pfrazee]

It would be nice if users could select files, outside of an application's sandbox, to access with fs. This is generally convenient, and it lets users share files between applications.

Problem is, it also invites unplanned concurrent access by applications.