early access · source not yet published
Watch the text behind this sentence turn into ciphertext on its own — then move your cursor across it and drive the wavefront yourself. Kalvien generates your keys on your device and never sees them, so we can deliver your words and never open them.
The actual app
This isn't a screenshot or a video — the composer works. Type something and watch it get sealed on this device before it moves: the byte count under your bubble is a real ciphertext length and those first three bytes are really yours. It is a demonstration, not the shipped client — the app is Android and encrypts with libsodium; your browser only offers its own cipher suite. Same guarantee, different primitive, and we say which is which further down.
In the app today
crypto_box — X25519 key agreement, XSalsa20-Poly1305 cipher. Your private key is generated on the device and stored in Keystore-backed storage.Also in the build: pinned, muted and archived chats · block and report · read receipts off by default · passcode app lock · push notifications · light and dark themes · delete your account and everything in it, from inside the app.
Six screens, all of them real
One thread can't show you group key handling, your privacy defaults, or the way out. Every screen here is backed by something that runs — where a screen shows a limit rather than a feature, it says so on the screen. Swipe, or use the arrows.
Pinned
All
Encryption
4 members
When someone joins or leaves, the key rotates to a new epoch and is resealed. We store four envelopes and hold no key that opens any of them.
This removes your account, your messages, your keys, your contacts and your settings. It cannot be undone.
No retention window, no "deactivated" state, no email asking you to reconsider. Two taps from Settings.
Other ways
We never read your address book — there is no contacts permission in the app. But a full number typed here does resolve to an account, and we don't hash it yet. next
Your theme is stored on the device. It never becomes account data, because there is no profile for it to sit in.
Defaults matter more than settings: a private app that ships loud defaults isn't private. off is the starting position here. No screenshot blocking or biometric unlock yet — both are on the next list.
Scroll to send · the network is watching
your phone
their phone
The interceptor sees an opaque blob. It knows a message happened. It cannot tell you what it said.
Real cryptography · running in this tab
Each tile below is one real byte of ciphertext, produced right now by your own browser. Change a single character and watch how many of them flip — that avalanche is the property that matters, and it's the same one the app relies on. The algorithms differ: this runs on what browsers ship, and the Android app uses libsodium's X25519 and XSalsa20-Poly1305. Saying "the exact construction the app uses" would be easier and untrue.
—
Fresh nonce every keystroke · nothing here touches the network
· the app does the same job with crypto_box
Don't take our word for it
We haven't published the source yet, so a promise is all we'd otherwise have. Instead: here is the request that leaves your device, the row it becomes on our server, and what happens when someone tries to open it. All three are generated live from the box above — edit it and watch them change.
encrypting…
Nothing on this page talks to a server — the keys, the ciphertext and the failed decrypt all happen in this tab, which you can confirm in the same network panel. When the source is published this section becomes redundant, and that will be a good day.
The differences that matter
Three of these are in the app today. Six are designed, specified, or half-built, and say so on the tag — a feature grid that blurs those two is how every other privacy page oversells itself. Two of them used to sit in the top group on this very page until we checked the source. The full order of work is on the roadmap.
01
in the appPhotos and video are encrypted on your phone with a one-off key, and that key is sealed to the recipient. What lands in our storage bucket is a file we cannot open — verified by a live end-to-end test, not by assertion.
02
in the appSet a timer and a sweeper on the server deletes the row every sixty seconds — not a client-side trick that hides the message while the bytes quietly persist. The copy on your phone and the copy on ours both stop existing.
03
in the appSigning up needs a number and an SMS code — we're not going to pretend otherwise. What's different is afterwards: no other user is ever shown it. It isn't in your profile, it isn't in the API response your contacts get, and people reach you at an @username. The gap we still have to close is search — see card 06.
04
nextReactions work today, but the emoji is stored on our server in the clear — we can see that you sent a skull. Sealing the emoji itself is the fix, and until it ships this card sits on this side of the line. This page listed it as done for a while. It wasn't.
05
nextThe fingerprint is computed correctly from both public keys in the crypto layer. The screen that shows it to you still renders a placeholder, so it cannot yet catch us handing you the wrong key — which makes it the most important unfinished thing here.
06
nextRight now, someone who already knows your full number can resolve it to your account. It's a deliberate limit — no short prefixes, so it isn't an enumeration oracle — but it isn't the same as "unfindable". Hashed lookup and an off-by-default switch are the fix.
07
nextRotating message keys, so one compromised device can't unlock your history. Today it's one long-term key per pair of people — the weakness in our own threat model, and the next thing we build.
08
nextA second passcode that opens a harmless-looking inbox. Forced to unlock your phone at a border or a checkpoint? You enter the decoy, and your real chats aren't there to find. The account can already hold a second passcode; nothing is wired to it yet.
09
laterBlur-until-tapped with the flag inside the envelope; a re-encrypting edit window; sixty-second encrypted voice notes. All three are designed and none of them are built — there is no microphone permission in the app at all, which is the simplest way to prove it.
10
laterGroup chats already work — the key is sealed separately to each member, so the server never holds an openable copy. What's missing is broadcast channels, and key distribution that stays honest at scale as members come and go.
11
laterEnd-to-end encrypted calling, one-to-one and in groups. Calls are a different problem to messages — real-time key agreement, and far more metadata to spill — so we'd rather ship them late than ship them leaky.
12
exploringYour account on a laptop as well as your phone, without handing us your keys. Every honest way to do this is hard; the dishonest way is an escrow we could be compelled to open, and that one isn't on the table.
Disappearing messages
An hour, a day, a week. A sweeper on the server deletes the ciphertext at rest every sixty seconds — not a client-side trick that hides the row while the bytes quietly persist.
deleted · both devices · and the disk
Fit, not funnel
A privacy tool that claims to be for everyone is either lying or dangerous. Kalvien is for everyday privacy, not operational security — and the second list matters more than the first.
The gap between "nobody's business" and "my life depends on it".
These aren't edge cases. If you're in this column, we'd rather lose you than have you rely on us.
The part everyone else omits
Every messenger lists what it protects. Almost none list what it doesn't. Here is where Kalvien is weak today, written down before you ask — a privacy tool that oversells itself is worse than one that's honest about its edges.
Two people share one long-term key. If your device key leaked, past messages with that person could be read. Signal rotates keys every message; we don't — yet. It's top of the list.
Message content is sealed. The metadata around it — sender, recipient, timestamp — is not. We can't read your words. We can see the shape of your conversations.
We hand out public keys, so in principle we could hand out a wrong one. A safety-number comparison defeats that — and ours isn't finished. The fingerprint is computed correctly in the crypto layer; the screen that would let you compare it still shows a placeholder. So today you are trusting us on key distribution with no way to audit it.
Your private key is generated on the phone, kept in Keystore-backed storage, and can't be exported. That's what makes it safe and it's also the cost — new device means new keys, and old messages stay unreadable. There is no recovery.
No independent party has reviewed our cryptography or our server. We use vetted primitives through libsodium rather than rolling our own, which is the floor, not a substitute. Until someone outside this team has looked, treat every claim on this page as ours rather than verified.
If you start typing and don't send, that draft syncs to your account so it survives closing the app — and unlike a message, it is stored in the clear. It's the least obvious thing on this list, which is exactly why it's on it. Clearing the box clears the stored copy.
Message bodies, media and group content are sealed. Reaction emoji are not — they sit in a plain column on our server, so we can see that you reacted with a skull. It's a small leak next to message content, and it's still a leak, so it's listed here rather than quietly omitted.
A number and an SMS code, like everyone else — it's how we keep one person from minting a thousand accounts, and how you get back in if you lose your device. So we do hold a number for you. It is hidden from every other user by default, it can't be used to search for you, and you talk to people at an @username. But "no phone number" would be a lie, so we're not saying it.
Threat model
Encryption isn't a yes or no. It's a list of adversaries and what each one walks away with — so here's ours, including the four rows where the answer is they get in. Two of those four moved into that column when we checked the code against this page rather than against our intentions.
A café network, a hotel, an ISP, anyone tapping the wire. They see that a message moved and nothing about what it said. Scroll back to the interceptor — that's this row, animated.
A dump of our storage is a table of ciphertext and a bucket of encrypted files. There is no body column, no preview field, no search index — we verify this with a live test that encrypts, stores, and then fails to read it back. What a thief does get is the metadata row: who, whom, when.
We hold ciphertext we can't open — and sender, recipient and timestamp that we can. We can't read your words. We can see the shape of who you talk to.
Content we genuinely cannot produce; metadata we can, because we have it. That is the whole honest answer. We do not publish a warrant canary — we'd rather say nothing than sign a document we have no process to keep true.
We distribute public keys, so in principle we could hand you an attacker's. A safety-number comparison is the only thing that catches that — and ours is not finished. The fingerprint is computed correctly underneath, but the screen that shows it is still a placeholder, so today you cannot actually perform the check. This is the row we most want to move.
A logged-in device is a logged-in device. There is a passcode lock, but no biometric unlock and no screenshot blocking, so a shoulder or a screen recorder wins. The decoy passcode that would help at a checkpoint is on the roadmap, not in the build.
No forward secrecy yet: one long-term key per pair of people. If that key leaked, past messages with that person could be read. This is our biggest weakness and the next thing we're building.
Someone with the budget to attack your phone directly, or to compel us and gag us about it. We are not the tool for that, and no messenger should tell you it is on its own.
Notice what isn't on this list: "unbreakable", "military-grade", "NSA-proof". If your adversary is in one of the bottom rows, read who this is for again — we'd rather you used Signal than trusted us with something we can't carry.
Including the rows we lose
Comparison tables are usually built so one column wins. This one has four rows where we lose outright, two of them to a free app we actively tell people to use instead — if we hid those you'd have no reason to believe the rest of the page.
| Feature | Kalvien | Signal | Telegram | |
|---|---|---|---|---|
| Your number hidden from other usersNot just from strangers — from your contacts and groups too, as the default. | Never shown to anyone | With a username set | Shown in every chat | Optional setting |
| Can someone find you by number?Hidden and unfindable are different claims. This is the second one. | Yes, with the full number | Yes, unless you restrict it | Yes | Yes, unless you restrict it |
| Encrypted by defaultNot a mode you have to find and switch on. | Every chat | Every chat | Every chat | Secret chats only |
| Forward secrecyRotating keys, so one compromised device can't unlock your history. | Not yet — next up | Yes | Yes | In secret chats |
| Metadata the operator holdsEveryone sees something. This is what we see. | Sender, recipient, time | Least — sealed sender | Contacts and timing | Contacts and timing |
| Source publishedVerifiable beats stated. We're not there. | Not yet | Fully | Protocol only | Clients only |
| Independently auditedNobody outside the team has reviewed our cryptography. | No | Repeatedly | Protocol only | Contested |
| Ads or ad-adjacent dataWhat the business model does to the privacy promise. | None in the codebase | None — nonprofit | Meta account linking | Sponsored messages |
Compiled July 2026 from each app's own published documentation, not from reviews. If a row is wrong or has gone stale, tell us and we'll correct it here rather than quietly leave it.
Designed, not shipped
Prototyped and specified. Not in the app today — listed so you know what you're getting on the list for.
The fingerprint already computes correctly; the screen that shows it needs to render the real one. Until it does, nobody can check that we handed out the right key — which makes this the most important item on the list, ahead of anything new.
Seal the emoji itself so the reaction column stops being readable. Small feature, and the difference between "encrypted messaging" being true and mostly true.
Rotating message keys, so one compromised device can't unlock your history. Today it's one long-term key per pair of people.
Stop a full phone number resolving to an account unless you've opted in, and match on hashes rather than the number itself.
Two things people assume a private messenger already does. We don't, yet.
A second passcode that opens a harmless-looking inbox. Forced to unlock your phone? Your real chats stay invisible.
The three product features that were designed but never built. Below the security work on purpose.
Broadcast channels for people who want an audience — and someone outside this team reviewing the cryptography, which is worth more than any feature here.
End-to-end encrypted calling, one-to-one and group.
Your account on more than one device, without handing us your keys.
The thing that would make this whole page checkable instead of merely stated.
Before you ask
Early access is free. We haven't decided how Kalvien pays for itself long term, and we'd rather say that than invent a pricing page. What we can commit to: there is no ad system in the codebase, and adding one would mean reading metadata we currently don't touch.
Your message history becomes permanently unreadable. Your private key is generated on the phone and cannot be exported — that's what makes it safe, and it's also the cost. There is no recovery and no backup. This is the single biggest trade-off in the product, and multi-device is on the roadmap precisely because of it.
No. Message content, media and group content are encrypted on your device before they reach us; we only ever hold a nonce and a blob of ciphertext. Two honest exceptions: we can see metadata — who messaged whom, and when — and reaction emoji are currently stored in the clear. Both are listed in what we don't claim rather than buried.
libsodium's crypto_box: X25519 for key agreement and XSalsa20-Poly1305 for the message itself, with sealed boxes distributing group keys and a separate key per media file. We use a vetted library rather than writing primitives ourselves. The demo higher up this page runs in your browser, so it uses the cipher suite browsers ship instead — it demonstrates the property, not the exact algorithm, and we'd rather say that than let you assume.
No, and we won't pretend otherwise. Signal has forward secrecy — rotating keys so a single compromise can't unlock your history — and we don't. Signal's code and cryptography have been audited repeatedly; ours have never been reviewed by anyone outside the team. Signal also asks for a phone number, and so do we. If your safety depends on the answer to this question, use Signal.
Not published yet. For a tool that asks you to trust its cryptography, that's a fair thing to hold against us — verifiable claims beat stated ones. It's the reason the page shows you real ciphertext rather than just describing it.
Android, in early access. iOS is next. There is no web client and no desktop client — if you've read something on this page that sounds like a browser app, that's the demo above, which exists to show you ciphertext rather than to be the product.
Store it, confirm it, and email you once when we launch. Nothing else — no drip sequence, no sharing, no analytics profile. Details in the privacy notice.
Before you join the list
No dark patterns and no surprise permission prompts — so here is every screen, in order, including the two that exist only because we ask for a phone number.
01
Your number A country and a number. This is the step we'd remove if we could — it's how we stop one person minting a thousand accounts.02
The six digits The second and last step that involves your number. After this it's hidden from every other user and can't be searched.03
A handle and a vibe Your @username is how people reach you, plus an optional note — 60 characters, gone in a day.04
Keys, made here Generated on the phone, held in Keystore-backed storage, not exportable. We receive the public half and nothing else — which is also why nobody, us included, can recover your messages later.about 40 seconds
Never asked for: your contacts, your location, your camera, or a credit card. The one thing we can't give you is a way back in if you lose the device — that's the trade-off, spelled out in what we don't claim.
One email, when there's something real to open. No drip campaign, no newsletter, no "we've updated our privacy policy".