Skip to main content
This page records the manifest fields the TinyCloud JS SDK accepts and the rules it applies when turning a manifest into a sign-in capability request.

Manifest v1

manifest_version is optional for v1. If it is omitted, the SDK treats the manifest as version 1.

Complete runtime app manifest

This example is deliberately explicit about app data and secret authority. It disables the default tier, names the default space and prefix, and declares the runtime capabilities the app uses. The composer still adds space-level capability introspection and, by default, account-registry permissions.
The SDK resolves the important entries as follows: secrets declarations request access; they do not contain or create secret values. Store values with tc.secrets.put(...), tc secrets put, or TinyCloud Secrets using the same name and scope. A scoped lookup does not fall back to a global secret: the name and scope together identify one vault entry. The example omits did because an ordinary app manifest grants its signed-in session access. Add did only to a manifest that targets a known backend or agent delegate. If that DID is learned at runtime, compose a separate delegate manifest in application code rather than hard-coding it here.

Fields

The TinyCloud App Kit schema also accepts a descriptive top-level resources object for app packaging. The JS SDK manifest composer does not currently read that object when it builds sign-in capabilities; declare runtime authority in permissions, defaults, and secrets instead.

Secret declarations

Use the object form when a secret needs a scope, non-default actions, an expiry, or a user-facing description. The manifest object key is the secret name unless the object sets name explicitly.
true means read access. Secret actions accept read, write, delete, list, and metadata; the SDK expands them to the backing encrypted vault KV actions. Secret names use upper snake case. Scopes are normalized to lowercase kebab case, and default and global are reserved—omit scope for a global secret.

Permission entries

Each permission entry names a service, optional space, path, and action list. The SDK expands short actions such as get, put, and read into full TinyCloud ability URNs when it builds the recap.
Rules to keep in mind:
  • space inherits from the manifest when omitted
  • space defaults to applications
  • path is app-relative unless you set skipPrefix: true
  • skipPrefix: true tells the SDK not to prepend the manifest app_id
  • expiry can override the manifest expiry for one permission
  • description is user-facing context and does not change authority
  • encryption permissions use raw network URNs as the path value

Default tiers

When defaults is enabled, the SDK starts from a standard permission set for the app prefix. Higher tiers add more capabilities:
  • standard: KV read/write/delete/list/metadata and SQL read/write
  • admin: standard plus SQL schema
  • all: admin plus DuckDB read/write
The SDK also adds tinycloud.capabilities/read separately for each requested space so capability introspection stays space-scoped.

Composition rules

  • capabilityRequest takes precedence over manifest
  • includeAccountRegistryPermissions defaults to true
  • manifest composition can add account-registry writes
  • owned encryption networks can request tinycloud.encryption/network.create when the manifest asks for tinycloud.encryption/decrypt

Source note

The manifest composer, default tiers, and encryption-network behavior are implemented in the JS SDK and covered by sign-in tests. Keep this page aligned with those sources instead of the whitepaper drafts.