Ciphertext on the open core
On the open-core standard record, resume, and daemon paths the coordinator holds only ciphertext, paths redacted. That is not the hosted Standard account.
Security & trust
Your code, your secrets, your keys on Private accounts.
You hold the keys on Private accounts and in the open core. Standard accounts are not end-to-end encrypted: the operator can read Standard-account Drive content. The limits we still mean, including deletion we do not perform, are below.
You hold the keys
You hold the keys on Private accounts and in the open core. Private accounts sign in with OPAQUE and a mandatory recovery key, shown once, and encrypt Drive content on your Mac before upload. Open-core scope keys use a sealed device key, a scrypt floor, and Shamir 2-of-3. Standard accounts are not end-to-end encrypted: the operator can read Standard-account Drive content.
(Software custody. Secure Enclave / Touch ID is not in the shipping Mac app.)
Secrets are leased, not copied
The open-core secrets engine hands the agent a lease and can refuse it later with a kill-list.
(Crypto-shred of an account is designed, not live. Account deletion is suspended and does not shred keys.)
Open core = anti-lock-in
Read it, run it, self-host the coordinator. Hosted early access operates that same engine — it is not a second codebase.
01 — Encryption model
Open core and Private accounts: the coordinator holds ciphertext.
Standard accounts are not end-to-end encrypted. The operator can read Standard-account Drive content. On the open-core record, resume, and daemon paths, bytes are encrypted on your device before anything leaves it. The coordinator stores ciphertext, and the file paths themselves are redacted, so it can't see what you named your files. Each of those paths gets its own data-encryption key (a per-path DEK), so access is scoped, not all-or-nothing. On the way back in, content is checked against its hash before it's trusted — verify-on-fetch, so corrupted or tampered bytes fail closed instead of silently rehydrating.
Private hosted accounts encrypt the content and the tree on the Mac, with keys unlocked by OPAQUE sign-in. The server holds ciphertext envelopes. Each envelope wraps its own data-encryption key, and a signed manifest names those objects. That key is per object, not per path.
A key-holder resumes transparently; a non-key-holder fails closed. You
can prove this for yourself: cli/test/ciphertext-default.ts.
plaintext stays on device
# open core
plaintext → stays on your device, encrypted before it leaves
ciphertext → what those paths store
paths → redacted; the coordinator can't see file names
per-path DEK → a distinct data-encryption key per path
verify-on-fetch → content hash checked before bytes are trusted
# Private hosted: content + tree encrypted on the Mac; keys unlocked by OPAQUE sign-in; server holds ciphertext envelopes
# Private hosted keys → per-object envelope DEKs in a signed manifest, not per path
# Standard accounts are not end-to-end encryptedAccount modes
What each door actually protects.
The hosted product has two account modes. They do not share one encryption claim. iOS, Windows, and Linux apps do not ship.
| Surface | What is true | What the server can see |
|---|---|---|
| Web Private account (Door A) | OPAQUE keeps the password off the server. A browser write can encrypt before it leaves the page, and the server still ships the JavaScript. The browser Drive is not a complete product surface. Treat this as protection against a database breach and honest-but-curious hosting, not as a check you can run on the served page. | OPAQUE records, public recipients, ciphertext envelopes |
| Mac app, Private account | Drive content is encrypted on the Mac before upload; keys are unlocked by OPAQUE sign-in. You hold those keys. The shipping app is signed and notarized. Key custody is software. Secure Enclave / Touch ID is not in it. | Ciphertext envelopes and public sync metadata |
| Standard account (Door B), web or Mac | Standard accounts are not end-to-end encrypted: the operator can read Standard-account Drive content. Sign-in is Clerk. | Standard-account Drive content, under the hosted auth path |
| iOS, Windows, Linux | Not shipping. There is no client on those platforms to hold a key. | No app |
02 — Key custody (KeyUnlock)
You hold the keys on Private accounts and in the open core.
Sealed device key + scrypt floor
The device key is sealed at rest behind a scrypt key-derivation floor — a deliberate work factor that makes brute-forcing the unlock passphrase expensive rather than instant.
Mandatory Shamir 2-of-3 recovery
Recovery isn't optional and isn't a single point of failure: the key is split into three Shamir shares, any two of which reconstruct it. Lose one and you're still safe; a single stolen share reveals nothing.
Enroll & panic-revoke
Enroll a new device into your key set, and panic-revoke a device or share the moment it's compromised — custody is something you operate, not a one-time setup you forget.
Honest note Hardware: gated
The shipping Mac app is signed and notarized (0.2.0). Key custody in that app is still software. Secure Enclave / Touch ID is not in it. Private hosted accounts add a separate door: OPAQUE, plus a mandatory recovery key shown once. We won't imply a hardware key we don't ship.
03 — Secrets as timeline events
Your agent gets a lease, not a copy.
Secrets aren't pasted into a prompt or copied into a config the agent keeps. Every access is a recorded timeline event you can audit and revoke.
X25519 + AES-GCM
Secrets are sealed with X25519 key agreement and AES-GCM authenticated encryption — confidentiality and tamper-detection in one envelope.
Broker leasing
A broker hands the agent a leased secret for the run, instead of dropping the raw value into its environment. The lease is the unit, and it's scoped.
Kill-list
Revoke a secret and it lands on a kill-list — future accesses are refused across the timeline, not just on the machine where you noticed.
Crypto-shred — designed, not a live deletion
Destroying key material so leftover ciphertext is noise is the design for a secret that must become unreadable. It is not a live way to delete a hosted account. Account deletion is suspended: the request does not revoke devices, shred keys, or delete rows.
04 — Provenance & signing
What a signature proves — and what it doesn't.
Every run carries a receipt. Receipts are signed with Ed25519 and packaged as DSSE / in-toto attestations, so you can verify before you trust: a TrustPolicy decides which signers and which claims you accept, and unsigned or untrusted provenance is rejected rather than quietly imported.
The honest limit, in the same voice
A signature proves who produced something and that it's untampered. It does not prove the claim is true — a signer can sign a false statement perfectly. And time is weak evidence: a timestamp is a claim, not a backdating oracle. We treat provenance as accountable attribution, never as a truth machine — and we say so out loud rather than letting "signed" read as "verified-correct."
05 — Anti-lock-in
Choosing hosted means choosing not to operate it — never to be trapped.
The core has zero runtime dependencies — only
node:crypto — so there's no supply chain to audit and nothing
proprietary you can't read. The R2 backend talks raw SigV4 with
no AWS SDK, so the cloud adapter is small enough to verify.
Everything sits behind one conformance-tested CoordinatorContract. Swapping from the local loopback backend to your own R2 + NATS is one config line; standing up R2 + NATS is ordinary provisioning on infrastructure you control. And you can always self-host the coordinator — the open core is the same engine, and it's yours to run.
One conformance-tested contract means every backend behaves identically — the code swap can't change what your data means.
the code swap is one config
# the code swap is one config line
eidos coordinator serve --backend=loopback # default, zero cloud
eidos coordinator serve --backend=r2+nats # your bucket, your queue
# standing up R2 + NATS is ordinary provisioning — your infra, your keys
# the core has zero runtime dependencies — only node:crypto06 — Honest limits & status
We don't hide the hard parts.
Here's the ledger, and the limits we state as plainly as the claims. If we don't ship it, the row says so.
| Capability | Status | What it means for you |
|---|---|---|
| Self-host (open core) | Live | Clone and run. Zero cloud, zero account. |
| Mac app 0.2.0 | Live | Notarized DMG at /downloads/Timestore.dmg. Finder drive (File Provider) ships. Trusted / FSKit does not. |
| Hosted coordinator | Live | Convex, R2, and NATS are operating for early access. |
| Accounts | Live | Standard sign-in via Clerk, or Private / E2EE via OPAQUE with a mandatory recovery key. |
| Billing | Live | Hosted Solo and Team checkout, and the customer portal, live in signed-in Settings. No public price list. |
| Storage quotas | Live | Free 1 GiB, Solo 50 GiB, Team 500 GiB. No per-plan device, seat, or repo cap. |
| Teams | Live | Shared folders with roles, invite links, and member removal — on the web and in the Mac app. |
| Restore | Live | Whole project, one file, one folder, or a deleted file this Mac saw, with undo. Mac app 0.2.0. |
| Reviews | Gated | Live on the web. The Mac app says review on the web. |
| Conflicts | Gated | Kept and surfaced, never silently merged. Resolve by restoring an earlier point. Keep mine / Take theirs are not functional yet. |
| Agent-run resume | Gated | Recording a run and its transcript needs the CLI and hook. Not in the DMG. Live process state never resumes. |
| Account deletion | Not built | Suspended. Crypto-shred of an account is designed, not live. A request does not delete rows or shred keys. |
| Deletion recovery across Macs | Not built | Restoring a deleted file is local to the Mac that saw the delete. |
| Windows, Linux, iOS | Not built | Not shipping. The CLI and coordinator are Node; we do not ship those apps. |
| SOC 2 | Not built | Not started. We'll publish a dated roadmap, never a premature badge. |
No edit is ever silently merged
Conflicting work is preserved and surfaced — never silently merged. Today you resolve it by restoring an earlier point. Keep mine and Take theirs are not functional yet. We'd rather show you the fork than invent a merge.
Resume rehydrates files + transcript, not RAM
A CLI resume reconstructs the working tree and the transcript when the hook recorded them. It does not restore live process state — RAM, ports, running servers. The Mac app syncs files; it does not record that transcript. The CLI prints the process-state limit on every resume.
The loopback coordinator is non-durable by design
The zero-cloud loopback coordinator runs in memory and forgets on restart. That's intentional for local, credential-free work — durability across restarts and machines is exactly what the hosted coordinator adds.
Hosted adapters are operating
Our Convex / R2 / NATS coordinator is operating for early access. The same contract is what you self-host. If you point the open core at your own backend, the cloud-live tests stay red until you provision it. That red is yours, not a claim that our early-access coordinator is down.
07 — Compliance, honestly staged
Architecture first. Attestation when it's earned.
We lead with verifiable design, not badges we haven't earned. Here's exactly where compliance stands today.
- Not started SOC 2 — not started. We'll publish a dated roadmap when it begins, never a premature badge.
- By design Privacy by design, deletion not live — you hold the keys on Private accounts and in the open core. Standard accounts are not end-to-end encrypted. Crypto-shred of an account is designed, not available. Account deletion is suspended. We will not call that true deletion.
- By design Encrypted before upload on Private accounts — Private accounts encrypt Drive content on the Mac before upload. The open-core coordinator holds ciphertext. Standard accounts are not end-to-end encrypted.
- Available now Self-host available today — the open core is the same engine. Read it, run it, host it yourself — the strongest assurance there is.
08 — Responsible disclosure
Found something? Tell us before you tell the internet.
If you discover a vulnerability, please report it privately at security@timestore.dev so we can verify and fix it before disclosure. Include reproduction steps and the affected version or commit. We'll acknowledge receipt, keep you updated, and credit you on request — no legal threats for good-faith research.
Because the core is open and self-hostable, you can verify a fix against the source the moment it lands — not wait for a vendor's word.
Trust the design, not the marketing.
Read and run the core yourself — or join early access to the hosted coordinator. We'll show you reproducible tests, not a fake dashboard.
See the full live-versus-gated picture on pricing, how the engine works on how it works, or the straight answers on the FAQ.