To make the keyserver work as a platform, we need to be able to guarantee E2E encryption. Users should feel comfortable installing any app in our app store without having to worry about how that app uses their data.

To that end it's important that we prevent platform apps from accessing the Internet directly. All communication into and out of a platform app has to go through our APIs. This is ultimately what we mean by a "sandbox".

Our APIs

  1. Network All network traffic needs to be routed through our network APIs, which guarantee that all communication occurs through E2E-encrypted channels, and that the user has verified all destinations as valid peers.
  2. Social When we talk about "valid peers", we're initially referring to the users' friends. Our social API allows an app to discover which of a user's friend are using that same app, and to communicate directly with them. Long-term we'll also support other kinds of peers, including chat bots and external services. Apps that rely on peering with another party will have to ask for that permission from the user.
  3. Messaging Our unified inbox approach means that messaging and notifications are one and the same. For that reason we expect that most apps will need to use our messaging APIs. Apps can message users directly to send them notifs and can implement chatbot functionality to allow users to talk to the app. Apps can also be added as participants in a sidebar, which allows them to provide useful functionality in a social setting.
  4. Database A crucial promise of the keyserver is that your data stays under your control. Our database API handles all data for a given app and includes a filesystem abstraction. The user can explore a given app's database and see how much space it's using (both on your keyserver and on the backup service). Eventually we'll add AI functionality that can access your database directly to give you insights in a fully private way. Our database API will also encrypt all data at-rest for all devices that support it.
  5. Media Our APIs include a shared media library that can accessed across all apps with the appropriate permissions. Media includes photos and video, but also text and links. Whereas an app's database is private to that app, media is indexed on a per-user basis, and can be shared to other users and other apps. We store media in a denormalized flat database, with structure being supported through a user-defined system of tags.
  6. Passwords Comm includes a password manager. But unlike other password managers, it's not just a database: with your permission, apps on Comm can access your passwords to perform actions on your behalf. These actions include scraping your data off of websites, filling out forms, etc. To guarantee the privacy of your passwords, Comm handles the log-in process itself, and restricts access to the website's runtime. We do allow access to the website's DOM, but only after making sure that the user's password is stripped from it. You can think of this use case as Selenium on steroids.
  7. Pipes Long-term we want apps to be able to interoperate with each other outside of the Media API. The Pipes API allows an app to declare a certain set of data it exports, and for other apps to get permission to access that data. You can imagine an app that uses your Chase log-in to scrape financial records, and another app that uses those financial records to display a dashboard of your financial activity. We expect the privacy guarantees of the keyserver to enable a universe of data inter-op possibilities.

Building interfaces

Apps on Comm can declare three kinds of interfaces:

  1. Chat One possible interface is chat. If you don't declare a chat interface, you can still send messages to a user (eg. for notifs), but the user won't be able to send messages back.
  2. Community interface An app can declare a community interface, which allows a community admin to configure that app to run on their community. Imagine a calendar app that shows a community's upcoming events, or a wiki app that lets community members collaboratively edit documents together.
  3. User interface An app can declare a user interface, which will allow the user to install and access that app directly, outside of any specific community. Some apps (like the aforementioned calendar app) might have both community interfaces and user interfaces, while other apps might only support one or the other.

Both community interfaces and user interfaces will be implemented in some React-like subset. Note that all three of these interface types can only be accessed through the Comm app, as we can't guarantee privacy inside third-party apps.

Root services

Sandboxed apps have two important restrictions: