The problem
TinySync is a file sync engine. It has its own identity primitives: devices and device tokens. Everything that reads or writes to a vault authenticates as a device. There are no users, sessions, or roles inside TinySync itself.
But Drive is deployed into other products — Scribe, a workspace platform, a developer tool. Those products have their own users, login flows, roles, and organization structures. When a user opens the Drive app on their laptop, something has to bridge the gap between "Alice logged in to Scribe" and "device dev_7a3b is authorized to read vault v_docs".
That bridge is what this chapter describes. The goal is to keep TinySync's sync engine simple and product-agnostic while giving ecosystems the control they need over who can access what.
The boundary
This boundary is intentional and load-bearing. The sync engine stays simple and testable precisely because it never has to reason about user identity, organizational membership, or product-level access rules. It asks one question: is this device token valid, and does the device belong to a group that has access to this vault?
The Platform Service owns the translation. It watches ecosystem events — a user logs in, gets promoted, leaves the workspace — and converts each one into TinySync API calls: register a device, add it to a group, revoke a token. The engine never sees the ecosystem event directly.
What the next chapters cover
- The Six Elements — the vocabulary of the integration model: users, devices, groups, vaults, containers, and the Platform Service itself.
- Groups and Access — how authorization works: group-based vault access, multi-group membership, and why there is no "deny".
- The Platform Service — the translation layer in detail: what it must implement, the API surface it calls, and how it maps ecosystem events to TinySync operations.
- Lifecycle — the full arc from device registration through token issuance to revocation, and what happens at each transition.