01
Own it.
Hosts can store and serve a space, but the user’s key remains the root of authority over its data.
TinyCloud Protocol
The user-owned data layer for AI and applications.
TinyCloud stores structured data in spaces you control, then lets you grant apps, services, devices, and AI agents precisely scoped, revocable access. Your data stays portable across tools, so changing an app or agent does not mean starting over.
User-owned spaces KV + SQL Scoped, revocable access Portable across apps and agents
Why TinyCloud
Make data useful without giving it away.
AI needs structured, machine-readable context. Traditional clouds make that context useful by trapping it inside a platform. TinyCloud keeps the user at the root of authority: data is legible to the software they choose while access stays explicit and bounded.
02
Share precisely.
Capabilities define who may do what, against which resource, for how long — and can be revoked.
03
Use it everywhere.
The same authorized data can follow a user across apps and agents instead of being rebuilt in every silo.
What it unlocks
A data service for the agentic era.
Use TinyCloud’s hosted services directly, or build products on the open protocol. Spaces provide a common substrate for data, communication, authorization, and composition.
AI + agents
Portable agent memory
Give an assistant approved context from conversations, notes, preferences, and prior work. Change the model without abandoning the memory.
App data
User-owned applications
Build notes, media libraries, personal CRMs, knowledge tools, and other software whose data remains with the person using it.
Delegation
Controlled automation
Let a backend or agent ingest data, call services, or run long tasks with a narrow delegation instead of the user’s master credentials.
KV + SQL
Private knowledge systems
Store documents, transcripts, structured records, and secrets in one capability-gated data layer that the user’s chosen tools can query.
Emerging
Credential-aware experiences
Create emerging workflows where access can depend on portable proof — such as a verified identity or credential — rather than a platform account.
Super-operable
Cross-app products
Turn one authorized app’s output into another app’s input, enabling feeds, copilots, and workflows no isolated data source could produce.
Super-operable applications
Build apps that start with the user — not an empty database.
A super-operable application combines the data it creates with the user’s other authorized TinyCloud data. Instead of every app owning a silo, the user owns the shared substrate and grants each experience only the pieces it needs.
A feed might combine meeting transcripts from Listen with preferences, credentials, and other TinyCloud-held data. An assistant can read that same approved history, write a result back, and let another app build on it — all under owner-rooted permissions.
Explore the architectureUser’s data sources
Listen conversations
TinyCloud apps structured app data
Credentials + secrets portable context
User-owned substrate
TinyCloud spaces + capabilities one owner
New experiences
Personal feed
Contextual assistant
Cross-app workflow
Super-operable = TinyCloud-interoperable. The application is replaceable; the user’s data and identity persist.
How the stack fits together
Three layers, one path from ownership to experience.
Layer 1
Protocol
User-owned spaces, identity, capabilities, delegation, storage, encryption, and policy.
Layer 2
TinyCloud Apps
Apps such as Listen, OpenCredentials, and Secrets bring structured data into those spaces.
Layer 3
Super-operable Applications
Experiences compose the user’s authorized data into something no single source could provide.
Open Knowledge Format
Explore the protocol.
This reference contains 99 source-linked concepts covering the protocol, services, application architecture, SDK, and roadmap.
Foundations · 4
Framing, thesis, and the trust model that motivate the TinyCloud protocol.
Identity · 5
Owner and session identities — DIDs, SIWE sign-in, and OpenKey.
Spaces · 4
The autonomic space primitive, its addressing grammar, system spaces, and hosting.
Authorization · 8
The capability model — delegation, invocation, revocation, attenuation, and validation.
Policy Engine · 5
The central permissioning primitive: owner-signed policies that the Node turns into credential-gated delegations (Policy v3).
Sharing · 1
Native Share links — read-only bearer links and addressed (Policy v3) links for an email address or email domain, with re-delegation and revocation.
Services · 8
Node-hosted services exposed over capability-gated abilities.
Encryption · 5
At-rest column encryption, user-bound encryption networks, and threshold decryption.
Storage · 4
Content-addressed blob store, metadata DB, per-space SQL, and storage quota.
Consistency · 4
Epoch ordering, conflict resolution, hybrid consistency, and replication.
Applications · 6
The manifest model, capability composition, install registry, and TEE backends.
Build an App · 2
The developer track — how apps work, getting started, and the app-kit + tinyboilerplate reference.
Secrets · 2
The secrets space and encrypted vault entries.
Credentials · 4
OpenCredentials — holder-bound vc+sd-jwt credentials that the Node verifies before minting a policy session.
Nodes · 3
Node architecture, TEE confidential compute, and host delegations.
SDK · 7
How to use the protocol — packages, sign-in, data APIs, delegation, and CLI.
Agents · 2
How AI agents reach TinyCloud data — the MCP server, the tc CLI's agent skill, and app skill packs — always through delegated, owner-approved authority.
Future · 7
Roadmap and design-intent items not yet shipped.
For agents: the raw markdown bundle is served verbatim at
/llms.txt and under
/concepts/<section>/<name>.md.
concepts/ is the source of truth; this site renders it in place.