Organizations & the active organization¶
A Limestone account can belong to several organizations. One of them is your active organization — the org that every org surface follows at once: the header Organization menu, Settings ▸ Organization / Invite Members / Permissions, and the vault encryption controls.
Switching organizations¶
- Header ▸ Organization lists your orgs when you belong to more than one; pick one to make it active (the active org is marked). Settings ▸ Organization has the same switcher.
- The choice is remembered per device. Every screen tracks it — no more each tab quietly showing a different (first) org.
Roles & the encryption gates¶
Roles are strictly hierarchical: owner > admin > user > read-only, each inheriting everything below it (ADR-0088). Settings ▸ Permissions shows the full role→capability matrix; owners can retune the adjustable minimums.
Vault encryption is governed by three adjustable capabilities (ADR-0101), shipped with these defaults:
| Capability | Default minimum role |
|---|---|
| Encrypt a vault | Admin |
| Create a shared vault | Admin |
| Decrypt / un-share a vault | Owner |
So by default an admin can encrypt a vault, but only an owner can decrypt it. The Encryption settings tab disables the Encrypt / Decrypt buttons (with a reason) when your role in the active org isn't high enough. A personal vault — one not tied to an organization — keeps the simple behaviour: any signed-in user can encrypt it, and its owner can decrypt it.
Enforcement note. In this first step the role gates are advisory — a UI guard, like note-locking. The real access control for a shared vault is cryptographic: only members whose key wraps the vault key can read it. Wiring membership to the keyring (grant-on-join, rotate-on-remove) is the next step in the shared-vaults epic (ADR-0101, Sprint 3).
Shared vaults¶
An organization can own shared vaults — always encrypted, and accessible to every member of the org (your org role governs what you can do inside). They appear under a Shared vaults heading in the "Open an existing vault" picker on the landing screen when the owning org is active — alongside your personal vaults, which are listed under Local vaults.
Creating one (admins). In the Shared vaults list, choose Create shared vault…, give it a name and an encryption passphrase, and pick an empty folder. Limestone creates and encrypts the vault, registers it to your org, and grants the key to members who've already set an encryption passphrase. You'll get a one-time recovery code — save it — and a reminder to share the folder with your org through your sync tool (Google Drive, Syncthing…). Members who haven't set a passphrase yet show as pending and can't open it until they do.
Opening one (members). The vault must be on your device — get its folder from your organization via the shared sync tool. Then pick it under Shared vaults in the "Open an existing vault" picker: Limestone opens it straight away if it already knows the folder, or shows Locate folder… so you can point it at the synced copy the first time. Unlock with your passphrase as usual.
How files travel. Limestone never uploads your vault — the account service
only knows which vaults an org has and who's in it. The files reach you through
your own sync tool, exactly like a personal vault (see
docs/syncing-your-vault.md).
Joining, onboarding & removing (the key lifecycle)¶
Because vaults are end-to-end encrypted, access is a key wrapped to you — and only an admin's unlocked device can hand one out. So the lifecycle is reconciled when an admin opens the vault (ADR-0103):
- Set an encryption passphrase first. Until you do, you're pending — an admin can't grant you a key. In the Shared vaults list (or Settings ▸ Encryption) choose Set an encryption passphrase; it publishes your public key so admins can grant you.
- Joining after a vault exists. When an admin opens a shared vault, Limestone auto-grants the key to any member who needs it and shows a short summary ("granted N; M pending"). There's also a Re-sync members button.
- Removing someone. Removing a member stops all future grants immediately. To cryptographically revoke them, an admin uses Rotate key to revoke (Settings ▸ Encryption) — this re-encrypts the vault to a new key and issues a new recovery code. Rotation protects future content only: a removed member keeps whatever already synced to their device — you can't un-send bits.
See planning/adr/0101-org-shared-vaults.md,
…/0102-org-owned-shared-vaults.md, and …/0103-shared-vault-key-lifecycle.md.