Trust isn't a tagline. It's an architecture.
Everything below is what we actually do, and what we explicitly choose not to do, so you can decide whether to trust us with the things that matter most.
End-to-end encrypted by default
Your content is encrypted on your device with libsodium (the same battle-tested library Signal uses) before it ever touches our network. Each Safe gets its own symmetric key. That key is then wrapped — once per recipient — with the recipient's public key.
Our servers store the encrypted content blob and the wrapped keys. They don't store anything that lets us decrypt your content. If our infrastructure is breached, the attacker gets ciphertext. If a court order lands on our doorstep, we can hand over ciphertext and metadata — and that's all we have to give.
Belt and suspenders, all the way down
Your content blobs sit on enterprise-grade cloud storage, encrypted end-to-end by your device before they ever leave it — so we don't rely on infrastructure for confidentiality. The storage layer adds defense-in-depth on top: encrypted at rest, TLS-only in transit, redundant across multiple physical datacenters with eleven-nines durability. Your encrypted Safes are storage-grade resilient the moment you save them — not just secure, durable — for the 30-year delivery window TRS is built to honor.
The keys live on your device
Your private key — the one that unwraps wrapped keys — lives in your phone's secure enclave (Face ID / fingerprint protected on iOS, equivalent on Android). It never leaves the device. We don't have a copy. We can't reset it. Even we can't recover it for you — and that's the point.
Recovery without a master key
So how do you recover access if you lose your phone?
Through Designees. You pick a small circle — typically 2 to 5 people you trust — and configure a quorum (usually "2 of 3 must approve"). If you're locked out, a quorum of them can verify it's really you and help you back in. Each Designee verifies independently. There's a deliberate cooling-off period between recovery initiation and key restoration. You're notified of every step and can cancel a recovery you didn't initiate.
No single Designee can restore your account on their own. Neither can we. The math forces collusion of multiple trusted people, with friction and observability — exactly the right shape for the kind of attack we're worried about.
Two-layer recovery — explained plainly
We separate your sign-in password from your encryption keys, on purpose:
- Sign-in password — proves who you are to the server. Recoverable by email reset.
- Encryption keys — decrypts your Safes. Recoverable through Designees.
This means a forgotten password on the same phone takes 30 seconds. A forgotten password and a new phone is a Designee-recovery flow — slower, deliberately. Both layers have to come apart for someone to reach your content, and "both layers come apart" is the threshold where the system asks your trusted circle to vouch for you.
The Pending Release window
When a release trigger fires, the Safe enters a Pending Release state — a cooling-off window before content actually goes out. 24 hours by default, 72 hours for inactivity-based releases (where you might just be on a flight). You're notified the moment a trigger fires, by every channel you've enabled. You can cancel with one tap during the window.
After the window closes, delivery is irrevocable. We commit to that line and we tell you exactly when it crosses. No silent extensions, no "oh we paused it for you," no calls to support to claw a release back. The certainty is the feature.
Releasee abstraction — privacy from your own helpers
If you designate a Releasee — a person who can fire releases on your behalf — they only see what they need. They never see your Safe names, file names, recipient names, or contents. Only the count: "3 Safes." When they fire, it fires all-or-nothing. They can't browse, edit, or pick. This protects your privacy from your own trusted helpers.
The release key
Every release attempt by a Releasee requires a release key — a credential you give them out-of-band, separately from the app. Identity verification (their email + phone) scopes which Safes they can release. The key authorizes the trust circle. Both are required; neither is sufficient on its own.
The key isn't stored in the Releasee's app. It's held only by them, however they choose — memory, paper, password manager. It's rotatable from your phone at any time. Every key submission is logged and you're notified the moment one is attempted, correct or incorrect.
What we log, what we don't
We log enough to detect abuse and audit your own activity:
- Sign-in events (timestamp, device fingerprint, region — not exact location)
- Safe state transitions (Draft → Sealed → Pending Release → Released)
- Trigger fires, including which Releasee or system event caused them
- Release-key submission attempts (success or failure)
- Recovery requests, Designee verifications, cooling-off-window timing
We don't log:
- Plaintext content, file names, or thumbnails (we don't have access to them)
- Recipient names or relationship metadata beyond what's required to deliver
- Read receipts on contents (recipients see them, we don't)
External audit and bug bounty
We're commissioning an external security audit with a reputable firm (Trail of Bits, Cure53, or NCC Group) prior to public launch — and we'll publish the findings, including anything they find. Annual re-audits thereafter.
A public bug bounty program (HackerOne or Intigriti) opens with public launch. Trust earned by exposure beats trust earned by marketing.
Compliance posture
- SOC 2 Type II: readiness work begins after V1 launch.
- HIPAA: on the roadmap for the B2B / healthcare tier.
- GDPR / CCPA: compliant from day one. You can export everything, and you can delete everything.
- Data residency: currently US-only (AWS US-East). EU residency option planned for V1.5.
Patent
The email-bound multi-party delegated authorization model — both for content release and for account recovery — is the foundational architectural claim of TRS. Patent application has been filed for prior-art search. We don't talk about the patent because we expect to enforce it; we talk about it because if it issues, no other consumer service can build the same architecture without our license.
Want the full threat model? Once the audit completes, we'll publish a public threat-model document covering attacker classes, assumptions, mitigations, and known residual risks. Subscribe to be notified when it lands.