How it works

End-to-end encryption

Every message is encrypted on the phone that sends it and decrypted on the phone that receives it. The keys that can open it exist only on those two devices. We never hold them, so we cannot read your messages — no matter who asks.

There is no setting for this and no “secret chat” mode to remember to switch on. A conversation that is not end-to-end encrypted is not a state Tacendum can be in.

Tacendum uses the Signal protocol family — the same design published and peer-reviewed for over a decade, rather than something we invented. Two properties matter in practice. Forward secrecy: today’s key is thrown away, so taking your phone tomorrow does not unlock yesterday. Post-compromise recovery: the keys keep ratcheting forward as you talk, so a compromise that ends stops paying.

The key exchange

When you first message someone, the two phones agree on a shared secret without ever sending it. We pass the public halves between you and cannot derive the private ones from what we carry.

That handshake is PQXDH — post-quantum extended triple Diffie-Hellman. Alongside the classical exchange it mixes in a post-quantum key (ML-KEM/Kyber), so a recording of today’s traffic is not something a future quantum computer can quietly decrypt — the “capture now, decrypt in fifteen years” attack is designed against rather than ignored. From there a Double Ratchet advances the keys with every message.

Safety numbers

Encryption protects a conversation from eavesdroppers. It does not, on its own, prove you are talking to who you think you are — that is the one attack a messenger has to hand you a tool for.

Every conversation with one person has a safety number, and both of you see the same one. Compare it once — read it aloud on a phone call, or hold the two screens side by side — and you have confirmed there is nobody in the middle. A room has no number of its own, because a safety number is between two people: you compare them member by member, and no room ever checks out as a whole.

If that number ever changes, Tacendum stops and tells you before you send anything else. An account is its key, and the server will not let an account change keys, so reinstalling or moving to a new phone makes someone a new contact with a new id — it cannot change the number on a conversation you already have. If a safety number changes, something is wrong. There is no innocent explanation left.

Check with the person on a call you place yourself, or in person, before you accept it.

In a room, a failed check quarantines that one member rather than stopping the room — that member stops receiving, the room carries on and says so by name. The Privacy Policy has the full mechanics.

What the server can see

This is where most security pages get vague, so: our servers can see who sent a message to whom, and when. They cannot see a single word of what it said.

Tacendum does not implement sealed sender. A message waiting for a phone that is offline sits in a queue as ciphertext with those routing fields attached, and is deleted when the recipient’s device acknowledges it — or after 30 days if it never does.

The trace above lists four smaller facts beside the routing:

• size — we hold the ciphertext, so its length is visible.
• session-start — each message flags whether it opens a fresh cryptographic session, so we can see when two accounts begin corresponding.
• urgent — a time-critical bit marks a frame as probably call signalling; it is what lets a call ring a sleeping phone.
• no-notify — a bit marks a frame as transport — a read receipt, a reaction, an edit — rather than conversation, which makes a read receipt inferable from timing.

Fetching someone’s keys to start a conversation also briefly counts against a rate counter keyed by both account ids.

A room does not change that picture; it multiplies it. A room message is not one thing the server understands — it is N separate pairwise-encrypted messages, one per member, with no room id, no shared identifier and no sequence tying them together, so the service cannot join them back up. What it can see is the fan-out: N copies leaving one account for N particular accounts, seconds apart, again on the next message. The contents and the room’s name are hidden; the membership is not, and an operator who wants the member list can infer it from that pattern.

The full inventory of every field our servers hold, how long each lives, and who else touches it is in the Privacy Policy — and the rooms section sets out exactly what a room leaves behind. Both are deliberately more detailed than this page.

Photos and files

A photo is encrypted on your phone before it is uploaded, with a key generated for that one photo. The key travels to the other person inside the encrypted message — never alongside the file, and never to us.

What sits in our storage is a blob of ciphertext with a random name. We cannot open it, produce a thumbnail of it, or tell you what it is. Blobs are deleted 30 days after upload, plus up to 7 days for a copy superseded by a re-upload.

Screenshots and screen recording

No iPhone app can block screenshots. What Tacendum does instead is disclose: take a screenshot inside a conversation and the other person is told, in that conversation — everyone in it, if it is a room — and there is no setting that turns that off. One gap: in a room containing somebody you have blocked, the notice goes to nobody, because the notice is sent as one copy per member and sending everyone else’s after the blocked member’s is refused would tell the room who you blocked. The Privacy Policy has the full mechanics.

Separately, while your screen is being recorded, mirrored, or sent to AirPlay, Tacendum hides your conversations until that stops. That one is a setting, on by default, because it protects you rather than the person you are talking to. Whether your screen is being captured is observed on your phone and never reported to us.

On your phone

We keep no copy of your conversations. There is no Tacendum archive to breach or subpoena — your history is stored only on your phone, protected by iOS Data Protection.

Your iPhone’s own backup should not carry your conversations either. The message database, the images in it, the decoy workspace, and the notification extension’s spool of decrypted messages are all flagged so that iCloud and computer backups skip them — as your keys already were. That flag is set in code and checked by our tests; we have not verified on a physical device that every backup pathway honours it. Until July 2026 this was not true — a backup took a readable copy, and this page said otherwise; the dated correction is in the Privacy Policy’s corrections list.

A little metadata is still included:

• your own account id
• the ids you have blocked
• the names you hold for the people you talk to
• your notification-preview level and its lease marker
• two badge counters

No message text, no images, no keys.

Your keys are never backed up. They live in files on this phone — in their own directory of the container the app shares with its notification extension, explicitly excluded from every backup and destroyed if you delete the app. So lose the phone and the account is gone — a restored backup gives you no way back into it, and we cannot issue one. There is no recovery of keys or messages, by design; a linked e-mail can win back the account grouping and discoverability only.

You can set a passcode that locks the app on top of the one that locks your phone.

Confidential work

Attorney–client privilege and patient confidentiality are duties the professional carries. No app discharges them. Tacendum holds no compliance certification of any kind, and nothing on this page is legal advice or a regulatory assurance.

What we can state as fact is the mechanics, which are what a duty of confidentiality actually needs:

• Message contents are unreadable to us, so there is nothing for us to disclose, mishandle, or be compelled to produce.
• We keep no archive of conversations. Undelivered messages clear within 30 days; delivered ones were never ours.
• Safety numbers let you verify you are talking to your client or your patient and not an impostor.
• We do not scan, profile, train on, or monetise anything that passes through.

Judge that against your own obligations — and note the limits below, particularly that the other person’s device is outside anyone’s control but theirs.

What this does not protect against

Stated plainly, because the gap between what encryption does and what people assume it does is where real harm happens.

• The other person — or, in a room, every person in it. They can screenshot, photograph the screen, or simply repeat what you said. You are told about screenshots; you are not protected from them. Encryption secures the channel, never the recipient.
• An unlocked or compromised phone. Anyone holding your device past its locks reads what you read. Malware on either phone sees messages after they are decrypted.
• Who you talked to, and when — and who is in a room with you. Our servers see that routing metadata, and so does anyone with lawful access to it. A room’s membership is part of it: we hold no roster, but we see who each copy of a room message goes to. Only the contents are beyond reach.
• Your IP address, on calls. Voice and video calls are end-to-end encrypted too, but a call has to find a network path, so our relay host sees your phone’s public IP address on effectively every call — and a direct call reveals each side’s address to the other phone. Your first call with someone new is relayed by default, and an app-wide always-relay switch keeps your address from the other phone entirely. The Privacy Policy’s calls section is the full account, including what the relay logs.
• No independent audit yet. The protocol is long-established and peer-reviewed; our implementation of it has not been audited by an outside firm. We will say so here when that changes.
• Encryption at rest uses provider-managed keys. The ciphertext queue and blob storage are encrypted by our infrastructure provider with keys they manage — a second layer under the end-to-end encryption, not a substitute for it.

Reporting a vulnerability

If you have found something, write to security@tacendum.com — hello@tacendum.com reaches the same people. A person reads it. Tell us what you found and how to reproduce it, and give us a reasonable window to fix it before publishing — we will not threaten you for reporting in good faith.

See also the Privacy Policy and the Terms of Service.