What we won’t do.

1 — We won’t read your email.

Mail content lives in local SQLite on every device you sign in on, protected at rest by your operating system (FileVault, BitLocker, Data Protection, File-Based Encryption). The Epistles relay never receives message bodies, attachments, subjects, or recipient lists. Our adapters talk directly from your device to your provider (Gmail, Microsoft 365, Fastmail, iCloud, Proton, IMAP), each in its native protocol.

The single, deliberate exception: web users on Fastmail. The browser’s CORS rules prevent direct JMAP requests, so the web client routes Fastmail traffic through a proxy on our relay. That proxy strips Authorization, forwards verbatim, logs only status codes and path shapes. This carve-out exists for web users only and lifts the moment Fastmail adds app.epistles.com to their OAuth client’s allowlist. Documented narrowly in our Security page.

2 — We won’t train AI on your mail.

There is no AI model on your inbox in our product, and no training pipeline behind our walls to feed one. We have not built a vector index of message bodies, we do not pass content to a third-party inference API for "smart features," and we have no plans for either.

Concretely: the relay receives no message content (see above), so even if we wanted to train, the corpus does not exist on our side. If we ever add an AI feature, it runs locally on your device against your local SQLite, with the input never leaving your machine — or it is opt-in per message and clearly labelled at the point of use. We will never silently route content through a model on our side.

3 — We won’t decrypt your vault, server-side.

Your Vault Encryption Key (VEK) is generated on your device at signup, wrapped with a key derived from your password (PBKDF2-SHA256, 600,000 iterations), and the wrapped bytes ride with your account row. We never store your password, only a bcrypt hash. We never store an unwrapped VEK anywhere — not in RAM, not in logs, not in backups.

Per-account credentials (IMAP passwords, JMAP session blobs, Cloud Vault settings, per-account notification rules) are AES-256-GCM envelopes that the server stores as opaque ciphertext it cannot read. If you forget your password, the wrapped VEK is unrecoverable; the recovery flow re-mints a fresh VEK and you re-OAuth your connected accounts. We chose that trade-off deliberately. See our Security page for the full architecture.

4 — We won’t quietly change these promises after an acquisition or funding round.

This is the clause that died with Skiff Mail in 2024. We’ve written it into our Terms in plain English so it cannot quietly die with us.

We’re not promising to refuse outside funding forever — that would be a promise we couldn’t honestly keep. What we’re committing to is that the privacy-architecture commitments on this page travel with the company. If the next round’s lead investor wants us to start reading mail to train a model, the structural choice is theirs: walk away, or accept that we owe every lifetime backer a refund and the world a working open-source mail client. No silent unbundling. No "we’ve updated our terms" email at 11pm on a Friday.

5 — We won’t charge you again after Bereans Edition.

The Bereans Edition is a one-time payment for the first 1,000 backers. Lifetime means lifetime. We won’t convert your lifetime to a subscription. We won’t introduce a "lifetime Plus" tier and quietly demote your current lifetime to "lifetime Basic." We won’t add a feature you already had to a paid tier you didn’t buy.

And after the first 1,000: lifetime closes permanently. No "lifetime returns at $129 in Year 2." If we ever raise the price or expand the cap, every existing Bereans Edition holder either keeps the original deal or gets a refund. The hard cap protects the cohort that bought in first, not the company.

6 — We won’t let the tool die with the company.

If Epistles is abandoned (no commits to the public client repo for 12 consecutive months) or shut down for any reason, the client source code publishes under MIT within 90 days. Local-first storage means your mail, contacts, and calendars already live on your devices — but the client release means the tool itself doesn’t die with us.

The relay’s scope is narrow enough that you can self-host it, and we’ll publish that source on the same trigger. The push fan-out, the OAuth rotator, the cloud-vault sync — small enough to fit on one developer’s machine, documented enough that one developer can run it.

7 — We won’t sell your data, ever, under any rebranding.

We will not sell your email address, your usage data, your account metadata, your contact graph, or aggregate "anonymized" derivatives of any of the above. This commitment is not subject to acquisition (see §4), is not subject to "business needs," and is not waivable by any change to our Terms made after you signed up. It binds the company, every successor entity, and every party that buys assets from either.

How to verify any of this

Each promise above maps to something concrete you can inspect or request:

• The architecture. The Security page describes the data flow, the encryption envelopes, and what each storage tier holds.
• The Terms. Each clause above is mirrored in our Terms of Service as a binding commitment, not a marketing line.
• The founder. Thiago Vinhas, publicly identifiable, reachable at [email protected]. Reply within 24 hours during Year 1; same hand at the wheel.
• The community. Bereans Edition backers get a private community space with weekly Office Hours where you can ask any of this in person.

Why “Bereans”?

From Acts 17:11 — “the Bereans were of more noble character than those in Thessalonica, for they examined the Scriptures every day to see if what Paul said was true.”

They were the ones who didn’t take a new teacher’s word for it. They checked. So check us. The code is structured to make it possible. The founder is public. The refund is one click. If anything on this page ever stops being true, the rest of this page tells you what we owe you.