Organisations and roles
An organisation has members with roles: owner, administrator, editor and viewer. Roles govern who may administer membership and content, never who can decrypt. That distinction is the whole point of the design.
Policy is set per organisation: requiring two-factor authentication, requiring device approval before synchronisation, restricting sign-in methods, and limiting session lifetime. Session-recording enforcement is a client-enforced disclosure requirement and is labelled as such, not as a technical guarantee.
Groups, invitations and key access
Sharing is granted to user groups rather than to individuals wherever possible, so a new member does not need a separate grant for every collection.
When an invitation is accepted, membership is immediate and key access is explicitly pending. The server cannot manufacture a key envelope for the new member; an authorised, unlocked client wraps the content key for each of their devices. Until that happens the new member can download ciphertext they cannot read, and the interface says so.
Revocation and rotation
Removing a member or revoking a device revokes server-side access immediately and returns the list of collections that now need re-keying. Only a client that holds the current key can perform that rotation.
Rotation protects future content. Anything a person was legitimately given, they may still have. Any product that implies otherwise is not telling the truth about how encryption works.
Source documents
This page summarises the files below. Read them for the full, authoritative text.
docs/ARCHITECTURE.md
Repository pathcontracts/openapi.yaml
Repository path