Personal Clouds

The "right model" ...

1. All user data and services are behind a single OAuth gateway that the user controls
2. All user data is portable via syncing with another personal cloud
3. Personal clouds can share permissioned data via link contracts
4. Personal clouds can push data via event notifications (webhooks, XMPP, etc.)
5. Apps can interact with personal clouds in three ways:
   1. Installed: behind the OAuth gateway with full API access or in VM (KRE model)
   2. Client: in browser or similar where personal cloud is used as app backend (unhosted model)
   3. Server: app server interacts with personal cloud API on user's behalf (OAuth app model)

Personal clouds provide the following basic services ...

1. OAuth API
2. data API – normalized data (Singly) and client app backend (Firebase)
3. pub/sub API
4. user messaging API
5. discovery API

Background

Traditional apps are built around centralized servers with connectors to fetch data from other services. If a user wishes to create a backup of app data, he/she must manually export the data to a personal data store (PDS) or harddrive. Additionally, the app developer must manually support each 3rd party data provider.

Zephyr's Personal Data Store architecture puts users back in control of their data while making it easier for developers to create data rich and scalable apps. In an ideal PDS architecture, user data is proxied through the user's PDS. This enables auto-caching of data, a signle API endpoint for personal data, and a distributed architecture similar to email.

While Zephyr's ideal architecture uses the PDS as the user's single API data endpoint, almost any hybrid configuration is possible. The main purpose of Zephyr is to make it easy to permission and manage distributed personal data. As PDSs become more interoperable, more and more apps' architecture will look like the ideal diagram.