# CloudSave - **Build only the front-end** of your app; storage is solved, including for your customers. - Feels like having your existing **object graph persisted**, _not_ interacting with a DB. - Automatic **registration & authentication** of app users. - **Sharing** between users through capabilities. - **Collaborative** edition of the same objects. - **Offline** support (IndexedDB). - **End-to-end encryption**. - Pay per customer data usage. Data cap, or pay per GB. +------------+ | App author | ← | CloudSave app editor | +------------+ +---------+ ← | Webpage host (eg GitHub) | | | | Browser | ← | CloudSave SDK (JS) | | | ←→ | CloudSave data protocol (websocket?) | +---------+ ← | CloudSave API | CloudSave app editor: 1. Authenticates author 2. Manages app authentication 3. Database schema and migration editor 4. Billing CloudSave data protocol: 1. Author implements app authentication to CloudSave 2. Author writes app with the data SDK 3. [SDK streams database queries and updates](./data-protocol/stream.md) 4. SDK encrypts data 5. Backend persists data 6. SDK authenticates users (unless anonymous) 7. SDK authorizes users (access control) 8. SDK migrates database version automatically CloudSave user API: 1. Sign up user 2. [Login user](./user-api/login.md) 3. Invite user 4. App subscription payment ## Front-end ```html

New article ``` ```js // blog.js const DB = CloudSave({app: 'tnysmojbema73'}); class Blog extends HTMLElement { // /index.html?=machine-interface-musings&id=sx3qb6komh572 } class BlogArticle extends HTMLElement { // Fetch URL id; say /blog/article.html?=tribute-to-alan-kay&id=h3pa4zkfvxwcsl } class BlogArticleNew extends HTMLElement { // /blog/new.html?id=sx3qb6komh572 render() { // Show a default form from type information. return DB.Blog.defaultHTMLInputRender(); } } ``` ## Underlying technologies - [HTML Custom Elements][CustEl] [CustEl]: https://html.spec.whatwg.org/multipage/custom-elements.html ## Backend There are many apps. Each app has a unique schema and migration scheme. Each app can have many users. When a user creates a new object space, they create a new database. That database can be accessed by other users (if granted). ### App authentication CloudSave has a global key. Each app has an appKey (secret to the author alone) which is hash('appKey ' + appID + appKeyRevision, key = globalKey). ### Storage Databases are hard. Persistence (and loss) is dangerous. Let's map onto CockroachDB and minimize DB access. #### Option 1: Exploit DB KV system Every piece of data is a protobuf compressed in Brotli. Every object is stored as one row in database, with the following fields: - App ID - Table ID - Object ID - Causal timestamp: - Causal ID: max known peer causal ID at time of object creation. - Session ID: unique for each session (= tab). - Local ID: incremented counter. - Content (contains byte slice with said Brotli protobuf). - Meta access (array of User ID) - Write access (array of User ID, excluding those with meta access) - Read access (array of User ID, excluding those with write access) An index has this form: - App ID - Index ID - Key - Object ID The schema has this form: - App ID - Database ID - Table or Index ID - Type (table or index) - Schema version - Format (contains byte slice with Brotli protobuf) - Size (byte from content sum, accounted for with a delay) #### Option 2: Distributed B-tree Each database is cut in pages, with a target page size of 16 kB to ensure it is easy to load atomically and not too expensive to write wholesale. Pages are organized as a B-tree. B-tree metadata updates (page creation or splitting) are logged and propagated to all consumers when they come online. Clients load data on a per-page basis, and persist it in IndexedDB. Read access would then be at the database level (since you will inevitably load data from other rows). Write access can be at the row level however, since that can be checked backend-side. ### ID design Options: 1. 128-bit PRF presented as base32. 2. Blowfish PRP of a {16-bit server ID, 48-bit counter} input. 3. Luby-Rackoff on top of SipHash. 4. Fermat spiral: key + phi × n, where phi = (1<<64)×(3-sqrt(5))÷2 = 0x61c8864680b583eb, and n = (serverID << 48 + counter). Perfectly distributed IDs, no information about how early an ID was created. However, IDs created nearby in time can be computed. 5. Distributed IDs as {64-bit session ID delivered by the backend, 64-bit counter}. Allows validation (that one node isn’t maliciously/erroneously taking the ID from another node), unlike 128-bit PRF. ### Design tradeoffs #### Inviting users Desirable features: - E2EE. - Supports public pages. (How to do that with E2EE? Decryption key in webpage?) - Link sharing to someone that does not have an account. - No account creation step (with tedious password entry etc) when opening a link. - Share password: - Cons: - Must transmit password from author to viewer: inconvenient - No public pages - Password in URL as query parameter (**Best tradeoff**): - Pros: - Link sharing works. - Cons: - Risk having the password leak in logs. (Mitigation: one-time-password, eg. share token.) - Risk conflicts with query parameters used by the hosting server. - Password in URL as hash segment: - Cons: - Cannot link to in-page location.