System model

TinyCloud is easier to use when you keep four pieces distinct:

• identity
• space
• capability
• service

​

The core pieces

​

How the pieces work together

1. A user signs in with a wallet or with OpenKey as the signer.
2. TinyCloud establishes a session and resolves the identity that should act for that session.
3. The SDK composes the requested capabilities and provisions missing owned resources when the flow requires it.
4. Requests go through the node with the capability chain and resource scope that the session carries.

​

Reading order by task

• If you are building a browser app, start with Browser app path.
• If you are building a backend service, start with Backend service path.
• If you are checking ability spelling or manifest fields, start with Protocol path.
• If you are deploying or debugging the stack, start with Operator path.

​

Trust note

This page explains the model, not the full protocol surface. For exact action names, statuses, and aliases, use the generated capability registry. For shipped behavior around auth, spaces, and storage, defer to the linked guides and the SDK source.