What TinyCloud verifies
- A signer proves control of the wallet or key that signs the SIWE flow.
- The session carries capabilities that bound what it may do.
- Delegations must stay within the parent capability’s scope.
- The generated capability registry records the exact action names, aliases, and statuses that the node currently accepts.
What TinyCloud does not hand you for free
- A session DID is not a durable user identity. Use
tc.didaftersignIn()when you need the owner’s DID. - An ability listed in the whitepaper is not automatically a shipped action. Check the generated registry and implementation docs.
- OpenKey OAuth is not the same thing as TinyCloud authentication. TinyCloud still uses SIWE for its own sign-in flow.
- Revoking a bearer Share link stops new reads, but cannot recall copies already downloaded. Anyone holding the complete URL can read it until then. Use an addressed share when only one person or domain should read it.
- An HTML page shared as a bearer link runs in a sandboxed frame. It cannot read the link or the viewer’s session, but it can reveal the reader’s IP address to the sender.
Trust boundaries
Security posture
- Treat the implementation docs as the source of truth for shipped behavior.
- Treat the generated capability registry as the source of truth for ability names, aliases, and status.
- Treat whitepaper material as normative only when it does not conflict with code-backed behavior.
- Do not infer extra guarantees from a page layout, a proposal, or a marketing summary.
