1
Provisioning
Create the tenant
A DID provisions a tenant. That DID becomes the permanent owner identifier for the personal data store and receives the root capability.
How it works
The platform flow stays simple even when the trust model is strong.
TurtleShell is built so provisioning, storage, delegation, and sync all reinforce the same idea: the owner remains the source of authority.
Short version
DID ownership, ZCAP authorization, isolated storage, portable records.
Each layer tightens the trust boundary instead of weakening it.
2
Authority
Delegate only what is needed
The owner grants sub-capabilities to apps or collaborators with explicit caveats for operations, time windows, and data boundaries.
3
Storage
Write records into an isolated tenant
Records are stored in the tenant's dedicated backend boundary, encrypted at rest, and tracked with immutable version history.
4
Usage
Query through whichever API fits the job
REST, GraphQL, gRPC, and JSON-RPC all route through the same authorization layer, so the rules stay consistent across products and services.
5
Resilience
Replicate, export, and move when needed
Tenants can replicate across nodes with CRDT-based sync or move across deployments without abandoning the DID and capability model.
What this means in practice
Teams can build product experiences on top of stronger data ownership rules.
For product builders
Give apps access to exactly the records they need without making the app the new owner of the data.
For operators
Keep deployment choices practical while preserving clear tenant boundaries and auditability.
For end users
Let identity, records, and permissions stay portable across products instead of being stranded inside one service.