A Christmas wishlist containing all the technologies that I eventually want supported in Beaker so that we can crush Facebook and create a powerful open Web
This is a list of APIs or tools that we want in Beaker. Some of them are planned for a future launch; others are purely speculative. If any of the ideas catch your interest, consider writing a proposal or spec for how it can be done, and submit it to https://github.com/beakerbrowser/specs. The issues board for that repo is also a good place for discussions.
What: A way to represent users which provides a user filespace and public key ID. These "user dats" will be used to store user content, and can be shared across apps.
Why: 1st, we want an easy way to share data and identity between applications. 2nd, we need a foundation for identity that can be used to authenticate connections and encrypt data.
What's the blocker? The core features have been proposed with 0002-shared-data-layer, and we're planning to include it in the next major release.
What: A database built on top of Dat archives which makes it easy to build apps on the peer-to-peer network. WebDB is basically a wrapper around json files that are read from and written to a dat. It indexes the json files' content so that it's easy to query, and makes it possible to write applications without having to think about files at all.
Why: The Dat FS is powerful but somewhat difficult to use. WebDB gives a lot of easy-to-use primitives for writing applications, and helps apps stay compatible with each other.
What's the blocker? WebDB was proposed with 0003-webdb with a planned release in 0.8. We're still discussing whether it should be buitin to the browser, or live entirely in userland.
What: A way to look up users, either by a name or other identifying information, and get their public keys in a way that is trustworthy.
Why: Trustable key lookup is a key part to ensuring privacy; if the key lookup is compromised, then you can be tricked into sending sensitive information to the wrong party.
What's the blocker? Time and resources. It's possible we can cook up a solution with the concepts from NodeVMS but we shouldn't be blasé about the risk of getting it wrong.
What: Methods and parameters in the DatArchive APIs for encrypting files at rest. These parameters would specify the public keys of the intended recipients, and could optionally hide the recipients.
var archive = new DatArchive(window.location)
archive.writeFile('/secret.txt', 'For alice\'s eyes only!', {encrypt: true, recp: [alicesPubKey]})Why: Privacy is a key feature of peer-to-peer networking. With end-to-end encryption, we can have private exchanges within Dats which are otherwise public.
What's the blocker? We need user identities to land first (see 0002-shared-data-layer). We also need to have a plan for how we handle multiple devices; multiwriter might be a part of that. Good key distribution tools will also be important, but can actually come after this feature.
What: WebRTC with signalling solved.
Why: Direct connections are very handy for chat, notification, video/audio calls, screensharing, and many other basic application features.
What's the blocker? Signalling. Mafintosh thinks he can build a DHT which supports it, which would be pretty awesome. Another solution would be to use a service, and that's a place where the services registry would be handy.
What: A URL scheme where the hostnames can be set by users. For instance, "I'd like facebook.com to be THIS custom app instead." We sometimes call this the app scheme, though we're not sure if we're going to use app:// yet.
Why: Application URLs create friction against user choice. If I want to have a custom gist app, then I need that gist app to load when somebody uses the https://gist.github.com/pfrazee/cb29ce22b2ad7e4ffe418d7c673b1b4b URL.
What's the blocker? There are edge-cases that we need to figure out, such as: what happens if you don't have anything assigned to the hostname? How do we deal with incompatible apps at a hostname? Etc
What: A descriptive URL scheme which encodes an action. For instance, the URL intent:follow?url=dat://bobs-profile.com/ would open the social app and confirm a "follow user" flow. This can also be used to create contextual menus or buttons in the browser UI; for instance, if you are on a "user profile" site, the "follow" action would be available.
Why: Cross-app actions would improve the composability between applications. Rather than implementing everything in one application, you can rely on many different applications (which are probably all operating on the same internal data).
What's the blocker? Time and resources. We'll also need a way to "install" handling applications, and we're still thinking through how that should work.
What: A services registry maintained by Beaker, so that dat apps can ask the browser (and thus the user) for the services they need. This registry would also create and manage sessions for the app, which would hopefully reduce the number of password entries you have to do, and also ensure revokable access.
var hashbaseSession = await navigator.sessions.request('hashbase.io/protocol/v1', {
permissions: {
archives: ['read', 'create', 'update']
}
})
var hashbaseClient = new HashbaseClient(hashbaseSession)
var usersArchives = await hashbaseClient.archives.list()
// ...Why: Hardcoded backend URLs remove user choice. We want p2p to handle lots of stuff, but we still need services for some things. The registry would add a layer of user control, help modularize services, and simplify app development.
What's the blocker? Time and resources. We're going to introduce the navigator.sessions API for accessing user dats in 0.8. We'll need to extend that API to support remote services.
What: A way to run long-running background processes in the browser. These processes would serve a similar purpose to Web services, but they'd run on the user device and manage data locally. Using Beaker's application stack, these processes could service requests from peers on the network.
Why: We're going to need a way to share custom-built resources between applications. WebDB, for instance, is a good candidate for a long-running service. A service could export custom APIs to apps and could persist state more reliably than tab-based processes.
Bonus feature: Create an environment for these daemons that can run on nodejs, so that a service written for Beaker can also be run on a cloud server.
What's the blocker? Time and resources. It's also very awkwardly similar to ServiceWorkers, so we'll need to figure out how to square that circle. We also need to figure out the UX of daemons -- if we're too liberal with including them, user devices will fall down.
What: The ability to have multiple authors ("writers") on a Dat Archive. You can make changes offline, and then sync the changes afterward. If there are conflicts, you choose from the conflicting versions.
Why: It lets you use multiple devices. It also can be used by multiple users to collaborate on a Dat.
What's the blocker? Mafintosh is working on this for the Dat protocol now.
What: A Dat which is hosted on a server, and therefore can provide Highly Consistent collaboration from multiple writers.
Why: Sometimes you want to make sure there are never conflicts. Hosted dats are like multi-writer dats, in that they allow collaboration and multiple devices, but because a server manages the dat, you can reject writes and therefore avoid conflicts.
What's the blocker? This could be done in userland, in some form. You also need a server to host the dats.
What: A way to install Dat sites as "applications" and give them elevated permissions. When implemented, any "builtin app" for the browser, such as the bookmarks or history page, would become an installable Web app.
Why: We want users to be able to customize the applications they use.
What's the blocker? This is actually half-way implemented, but we pressed pause so we could think through some of the related technologies. User-controlled DNS and Intents are connected to IWAs, for instance.