What you’re trusting, and how we keep it true.
SilentPost holds messages that may sit untouched for years — messages you may never read again. That asks a lot. This page names what you’re actually trusting us with, and how those promises are kept verifiable instead of assumed.
Two questions are worth asking about a service like this. The rest of the page answers them honestly.
If something happens to me.
A service that depends on its founder being alive isn’t a service — it’s a hobby with consequences. SilentPost is built so the messages inside it don’t depend on me.
-
01
Delivery is fully automated.
Once a message is sealed and a schedule is set, no human input is required to deliver it. The system runs on a clock. Deliveries aren’t approved, can’t be sped up, and don’t pass through anyone’s inbox along the way.
-
02
The infrastructure is pre-funded.
SilentPost runs lean, with multi-year operating runway held in reserve. The bills, certificates, and DNS that keep your messages reachable cannot lapse because of a missed payment or a missing person.
-
03
A graceful wind-down, not an orphaned vault.
If SilentPost ever has to close, the closure procedure isn’t a shutdown — it’s a flush. Every pending message is delivered to its recipients before the lights go out. Even a worst-case outcome ends with your message arriving, not disappearing.
I use SilentPost myself, to leave access behind me.
The instructions, access keys, and successor handoff that keep SilentPost running — or trigger the wind-down — live inside a SilentPost vault of my own. If I miss my check-ins, my own message fires, and what needs to happen, happens. SilentPost is protected by SilentPost.
We are not reading your messages.
“Trust me” isn’t a guarantee. The right framing isn’t that we won’t look — it’s that you don’t have to take our word for it. SilentPost is built so that any access to your message leaves a permanent, public record.
-
The architecture forbids casual access.
Every message is encrypted at rest with a unique per-message key. That key is wrapped by AWS Key Management Service, and only the automated delivery process is permitted to unwrap it — and only once your delivery trigger has fired. Application servers do not hold standing permission to decrypt anything.
-
Every decrypt is logged.
KMS records every key-unwrap operation in AWS CloudTrail. Those logs are mirrored into a separate, append-only audit account that the operating account cannot silently edit or delete from.
-
A public counter you can check.
The counter above is the test. Lifetime decrypts must equal lifetime deliveries. Any drift is evidence that something happened that shouldn’t have — and a story we would have to explain.
I can’t claim it’s impossible for me to read a message — only that I can’t do it silently.
I’m the account owner. Any read I performed would register on the public counter above — lifetime decrypts would diverge from lifetime deliveries, and I’d owe the world an explanation.
This isn’t a promise that I can’t read your message. It’s a public test that says I haven’t. That’s a stronger commitment than “trust me,” and an honest one for a service like this to make today.
If anything on this page feels imprecise, vague, or like I’m hedging — write to me at hello@silentpost.io. The point of writing this down is so I can be held to it.
The founder, SilentPost