System Spaces

System spaces are the reserved, conventional space names that every owner DID has by convention: default, public, account, secrets, and applications. They are not a special kind of space — each is an ordinary autonomic space off the owner's DID, created lazily by a tinycloud.space/host capability like any other — but the ecosystem agrees on these names and what lives in each, so apps and agents can find data without discovery.

Role

System spaces are Layer 1 convention. They give the manifest model and L2 TinyCloud apps a shared map of where data goes: an app declares which spaces it needs in its manifest, the user grants scoped capabilities over them, and reads/writes address them through the URI grammar (tinycloud:{did-suffix}:{name}/{service}/…). Because the names are conventional rather than enforced by the node, this is genuinely a protocol convention, not a runtime feature.

Shape

There is no backend reserved-name list — tinycloud-node will host a space of any name (tinycloud-auth/src/resource.rs::Name accepts any string; validation is a TODO). The only name with backend behavior is public, special-cased for unauthenticated reads by tinycloud-node-server/src/routes/public.rs::is_public_space. The canonical set is conventional, defined in the SDK as named constants (packages/sdk-core/src/manifest.ts: ACCOUNT_REGISTRY_SPACE="account", SECRETS_SPACE="secrets", DEFAULT_MANIFEST_SPACE="applications", ENCRYPTION_MANIFEST_SPACE="encryption"). The names:

The applications overload. "applications" names two distinct things: (1) the applications space that holds app data, and (2) the applications/ key-prefix inside the account space that holds the install registry. They are not the same location — the registry is account/…/applications/, the data is the applications space.

encryption is NOT a space

The encryption label is synthetic: it resolves to an encryption-network URN urn:tinycloud:encryption:{ownerDid}:{network}, a Resource::Other (see uri-addressing-grammar), not a hosted space. Encryption networks are user-bound and managed separately (see encryption-networks); SDKs auto-create an owner-owned network during manifest sign-in.

Mechanics

A system space is materialized exactly like any space: the first time an app needs it, the SDK transacts a delegation carrying tinycloud.space/host over tinycloud:{did-suffix}:{name}/space, and the node inserts the SpaceId (see autonomic-space for the lazy-host path). Authority over a system space still roots at the owner DID — public differs only in that its read capabilities are granted to everyone.

Used by

The L2 TinyCloud apps enshrine these spaces: Listen writes conversation data into the applications space (keyed by its app_id), Secrets owns the secrets space, and the manifest/install registry lives in account. An L3 super-operable app reads across several of them under the user's policy.

Relationships

Each is an autonomic space addressed by the URI grammar; populated through services (kv/sql); access via capabilities + delegation; declared in an app manifest; secrets ↔ secrets; the applications space ↔ Listen and other manifest apps; encryption ↔ encryption-networks.

Status & drift

Shipped. Drift: the whitepaper lists the system space as apps; the code uses applications — code is canonical (see contradictions). The set is SDK-enforced, not node-enforced, so it is a convention that could evolve; treat the list as current-as-of-code, not a frozen protocol constant.

Sources

• js-sdk: packages/sdk-core/src/manifest.ts (space-name constants), packages/sdk-core/src/account/AccountService.ts (account registry + applications/ / spaces/ prefixes), packages/sdk-services/src/secrets/paths.ts (resolveSecretPath → vault/secrets/<NAME>, scoped variant), packages/sdk-services/src/encryption/networkId.ts (buildNetworkId/parseNetworkId)
• tinycloud-node: tinycloud-node-server/src/routes/public.rs (is_public_space), tinycloud-auth/src/resource.rs (Name accepts any string — no reserved-name list); confirmed via cx