Group-based authorization
In TinySync, access to a vault is granted at the group level — never directly to individual devices. A device gets access to a vault by virtue of being a member of a group that has access to that vault.
Why groups, not direct device authorization?
Consider a workspace with 50 users each with 2 devices (100 devices) accessing 20 vaults. Without groups, adding a new vault requires 100 authorization records. Adding a new device requires 20. With group-based auth, adding a vault is one group-vault edge. Adding a device is one device-group edge. Neither requires touching the other.
Why devices get individual identity at all is its own decision — see the device identity record.
Group membership is opaque to TinySync
TinySync stores group IDs as opaque identifiers. It does not know what a group "means" in the ecosystem — whether it maps to a team, an organization, a billing tier, or a product subscription. That interpretation lives entirely in the Platform Service. TinySync only answers: "is device X a member of a group that has access to vault Y?"
Authorization at request time
TinySync resolves authorization lazily, at each request. When a device presents a token and requests access to a vault, the server checks: is this device in a group that has access to this vault? If yes, the request proceeds. There is no pre-computed access matrix that needs to be kept in sync.
groups, group_devices, group_vaults — and the request-time check is a single indexed EXISTS over the two edge tables (migration 0004_groups.sql).Multi-group access
A device can belong to multiple groups. A vault can belong to multiple groups. This is a deliberate design choice that enables complex organizational structures without requiring TinySync to understand them.
In this example: Alice's MacBook is in both groups and can reach both vaults. Carol's MacBook is only in the Engineering group and can reach both vaults her group has access to. Bob's MacBook is only in the All-Access group and can reach only the company drive.
Access is the union of all group memberships
If a device belongs to groups G1 and G2, its effective vault access is the union of vaults accessible via G1 and vaults accessible via G2. There is no "deny" — group membership is purely additive. Access restriction is achieved by keeping a device out of a group, not by adding a deny rule.
Practical patterns
| Ecosystem concept | Mapped as |
|---|---|
| Organization-wide Drive | One group containing all org members' devices, one vault |
| Team-specific Drive | One group per team, one vault per team; devices in team group |
| Cross-team shared vault | Vault accessible by multiple groups; each team group gets the edge |
| Personal Drive | One group per user containing all their devices, one personal vault |
| Admin full access | Admin devices added to all relevant groups, or a special admin group with all vault edges |
Containers: namespace, not authorization
A container is a tagged view inside a vault. Containers carry product namespace and policy information — they are how different consuming products carve out their space within a shared vault without interfering with each other.
What containers are for
Imagine Scribe and Drive both use the same vault for an organization. Scribe might store document attachments; Drive stores the full file tree. Containers let them tag their items differently and apply different access policies without requiring separate vaults per product.
Container ↔ Group: no direct relationship
This is a deliberate choice. A device authorized to a vault (via a group) can read any container in that vault — unless container-level access controls are added separately. The primary access gate is the group. Containers add a layer of namespace and policy on top, not a separate authorization layer.