Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Installable Web Applications
This spec is a work in progress.
The Dat protocol introduces a new opportunity to remove the Web's dependency on services. To do so, we need to create a new execution model for the Web application.
This spec explores a new "installable" Web application.
- Dat sites possess manifest files, located at
- Dat sites may request special APIs in the manifest. Doing so requires an installation step before the APIs are granted.
- The runtime environment will be expanded to support more powerful local behaviors, such as access to the filesystem, browser UI hooks, TCP/UDP sockets, and the peer-to-peer network.
With the Dat protocol, we substitute hosting services with a peer-to-peer network. This changes how websites are addressed: instead of using an IP address, the browser accepts a cryptographic ID, and then queries the network for any available hosts. The "host" is therefore interchangeable.
With no host attached to the address of websites, we can stop thinking of an app as a thin client. Instead, we can treat the HTML/JS/CSS bundle as a complete application. There is no backend; only the local computer and its APIs.
On this basis, it's suitable to think of Dat applications as a hybrid of desktop and web applications. Beaker's objective is to provide the extra capabilities necessary for Dat applications to do useful work.
Adding "installation" to the Web
By default, Dat sites behave as regular websites. If they wish to request special behaviors and permissions, they must do so through their manifest file, and get the confirmation of the user (installation).
/dat.json, a Dat archive encodes the standard manifest file. This manifest defines standard metadata such as name and description, and also outlines any special capabilities which the application requires.
Like HTTP/S, Dat sites can load instantly and work as simple sites and apps.
However, some Dat sites may want to use APIs and behaviors which require permission from the user. For instance, an application may want to be added to a menu, manage the user's files, or handle Web intents.
To handle these use cases, we use an "install process." The installer shows the user how the application will modify their system, and gives them an opportunity to confirm or deny the update.
Upon confirmation, the website is added to the installed applications, and is configured into the browser. Any behaviors which the application has requested, such as background scripts or intent handling, will be executed.
Updates which require changes
Sometimes applications need to change their configuration in the system. For instance, they may need to request additional permissions to system APIs.
If an update doesn't change their configuration, then the update happens automatically, in the background.
However, if a config or permission change is required, the user will be prompted to accept the update and its changes. (Declining is an option.)
The APIs which installation can request should give safe access to the device's resources. Examples include
- the network data structures, such as DatArchive, DatFeed, and DatTable,
- browser hooks, such as Web Intents, background scripts, and UI elements (see browser_action and page_action), and
- low level APIs, such as TCPSocket and UDPSocket
Some APIs are automatically available, and some others require permissions. (To avoid doing harm to the HTTPS ecosystem, these APIs are only available from websites served over Dat.)
Dat applications mimic the single-origin policy of http/s sites. All permissions are granted on the basis of origin, which is determined by the cryptographic ID of the site.
If a site has a DNS shortname, the shortname will be resolved to the cryptographic ID. This means that changing the DNS mapping requires an update prompt by all end-users. The update prompt does not need to be scary; it can be similar to the update prompts used when a new capability is requested by an app (see "Updates which require changes," above).
Dat is a secure delivery network. All updates are signed, and all files are referenced by a cryptographic hash. The network uses a flattened merkle tree to ensure auditable uniform distribution, similar to the system employed by Certificate Transparency.
Content Security Policies
By default, a Dat application is not allowed to access HTTP/S services. It cannot embed assets from HTTP/S, or use Ajax to contact an HTTP/S service. All access to the network must be specially requested of the user.
A Dat application can access the Dat network. It can embed assets from other Dat archives, and it can read other Dat archives using Ajax or the Web APIs. Writing permission must be granted specially.
A deeper discussion of this topic lives at this wiki page.
Installable Web Applications share a history with many other technologies:
- Chrome Apps, which provided installable desktop applications on top of Chrome's runtime
- Electron, which packages HTML/JS/CSS apps with Chromium to act as independent desktop applications
- Web Extensions, which provide APIs for hooking into the browser and potentially act as applications
- Progressive Web Apps, which enables Web applications to install offline behaviors
- Firefox OS, which was an attempt to out-Android Android using the Web platform
Here are some key differentiators to help you distinguish this spec from the others:
- (Compared to Chrome Apps and Firefox OS) This spec delivers applications using an ownerless peer-to-peer network. Therefore, there's no reliance on a vendor's Webstore or delivery service.
- (Compared to Web Extensions) This spec does not allow as many changes to the browser as Web Extensions allow. The goal is to run more powerful Web applications, not to modify the browser.
- (Compared to Electron) This spec runs applications on a common browser runtime, unlike Electron, which bundles the runtime with each application. That said, we <3 Electron, because that's what we're built on.
- (Compared to Progressive Web Apps) PWAs are designed to handle what happens when the hosting service isn't available. By contrast, this spec assumes there isn't a hosting service.
On "nag" screens
We should be careful to avoid nagging users about installation. Experience has shown that application developers will use every opportunity to escalate their presence to a user. See, for example, the mobile app install nag banners which users universally hate, but which sites continue to foist upon users.
To solve this problem, we need to consider two angles: the ideal flow, and the potentials for abuse. If a page can generate banners or prompts at will, for instance, then they are certain to abuse it. (Banners are extremely naggy anyway.)
Some countermeasures to consider:
- never uses popups or banners,
- require a user action (click) to spawn the install screens, and
- try to mimic flows that users don't mind, such as the registration/sign-in flow of existing web apps.
Removing the need for installation: stricter sandboxes
Web and mobile platforms have trained users to be concerned about sharing information with their applications, because of the risk that apps will steal their data.
There's probably no user that is happy to share their contacts with Uber, for instance. (Sorry Uber. It's the truth.)
This problem exists because the platforms are not creating a safe enough environment. Uber may have some really great reasons for accessing the contact list - helping friends coordinate their rides, for instance - but because there's no guarantee that Uber can't steal the user's contacts, then users have to assume they will steal the data. (Again, apologies to Uber.)
When users are scared to do something, then the Web loses some of its vibrancy.
Ideally, it would be possible to create a special-case execution model which is completely constrained to the local device, and which protects dangerous mutations, but which gives the application free access to the user's data.
Ideally, such an environment would never have a interface that resembles a "permissions request." Permission would instead be granted through flows that involve trusted interfaces.
For example: an application might have full access to read the user's contacts, but no ability to change them. If, however, a change is required, it could use a Web Intent flow to direct the user to the central contact-management app, with a prompt to affect a change. After completion, the user would return to the previous page.
Looking to the future: alternative application models
As has been often said, the GUI was a boon to end-users, but it required developers to pay a heavy price. Building GUI applications is a tedious task.
To create simpler, more productive programming environments, we can create more constrained application models. An example of this is the Web Terminal spec, which makes it simple to create command-line styles of applications.
As we progress the browser environment, we should look for additional ways to create useful constrained environments, and therefore enable new and simpler programming models.