What it is
A drop-in authorization layer for SpacetimeDB modules that provides roles, hierarchical scopes, permission grants, invite links, expiring access, an audit log, and row-level security. It sits between your module's data tables and the clients that subscribe to them, ensuring each connected identity sees only the rows they are permitted to see and can only perform actions their current grants allow.
Where it fits
- Multi-tenant SaaS tools: An app with organizations, workspaces, and projects needs per-tenant roles and scoped permissions without rebuilding the same grant logic for every resource type.
- Collaborative creative tools: A stream overlay editor or shared document tool where different contributors hold viewer, editor, or admin rights on specific overlays or documents.
- Time-limited access: A platform that needs to grant temporary access to a contractor or beta tester, with the grant automatically expiring on a set date.
- Invite-based onboarding: A community or team product where existing members share invite links that carry a specific role, with use limits and optional expiry on the resulting grant.
- Regulated or audited environments: Any module where you need a complete record of who granted or revoked access to whom, and when, across all scopes.
How it works
Permissions are expressed as dotted strings, and roles collect one or more of those permissions, including wildcard forms that cover an entire category. Roles can inherit from other roles, and the full flattened set of permissions each role implies is kept up to date automatically. Scopes form a tree, so a grant made at a parent scope flows down to every child scope beneath it. This means you can model any nesting your app uses, such as organizations containing workspaces containing projects, and a single grant at the top covers the whole subtree.
Grants tie an identity to a role within a particular scope, with an optional expiry time. When a grant expires, a scheduled task removes it and writes a record to the audit log. Invite links work similarly: a member with the right to hand out a role can generate a code that, when redeemed, creates a grant. If the inviter later loses that right, the invite stops working. The no-escalation rule means no one can grant permissions they do not already hold themselves, so a team lead cannot accidentally promote someone above their own level.
Row-level security is the mechanism that enforces what each client can subscribe to. Tables tagged with a scope are filtered so that a connected client only receives rows for scopes where they hold the required permission. The module's own internal tables follow the same rules: you see a scope's membership list only if you belong to it, and you see its audit log only if you hold the audit permission there. When a grant changes, the affected rows appear or disappear on the client's screen in real time without any extra polling.
