Terms of Service

What this is

Tacendum is an end-to-end encrypted messenger for iPhone. Tacendum is operated by Mirana Technologies Inc. (“we”, “us”). By creating an account, or by using the app or this website, you agree to these terms. If you do not agree, do not use it.

A conversation carries either two people or a room of up to twelve, and a room is made by one person from people they already talk to: only its maker can add or remove anyone. There are no channels, no feed and no directory, and no way to browse or search for people: you reach someone by their account address — a 26-character identifier, normally exchanged by scanning a code in person — or, only if they chose it, by typing an exact email address or username they linked and switched on. The home page describes everything the app carries; what matters for scope here is that it carries messages and their attachments, a shared vault, and calls — voice and video between two people, and a voice call of up to six in a room. A room’s call is voice only; video calls remain one to one.

Messages are end-to-end encrypted on your phone before they reach us, and your conversation history lives on the phones in the conversation rather than on our servers. We do see routing information — which account sent something to which account, and when. The ciphertext sits in that row too, so its length is visible to us even though we store no size field. The Privacy Policy sets out exactly what we hold and what we cannot see. It is part of this agreement and it is worth reading before the rest of this page.

The command-line client

A command-line client and a no-send integration server — an MCP server — exist in pre-release form. The integration server can read stored messages and mark them read; it cannot send. Where we make these available, these terms apply to them as well, alongside the licence in section 11.

The Privacy Policy covers the command-line client and the MCP server by name, and the server side is the same for a machine as for a phone — everything in this document about what we hold applies unchanged. What differs is the machine you run it on, and that belongs in the agreement as well as in the policy: the command-line client writes decrypted messages to disk in the clear, under its own home directory, in a compartment beside the one holding its protocol keys but under the same root — so a backup of that root copies both. The Privacy Policy states the retention passes exactly — how long the spool keeps a message, and why nothing runs between commands. Files are created private to your user account, and anyone who can read that directory can be that account.

Your account is a key

The first time you open the app it generates a cryptographic key pair on the phone. The private half never leaves the device. To create an account or to sign this device back in, the app asks our server for a one-time random challenge, signs it, and sends back only the signature and the public half of the key. In exchange the server issues an account id: 26 characters, generated by us, carrying the time it was made and nothing else about you.

There is no phone number, no email address, no username and no password required in any of that. Your key is your account, and one key answers for exactly one account. Afterwards you may link an email address, or claim a unique username — each optional, each revocable, each off for finding you until you switch it on. An email can also win back your account grouping if every device is lost; a username can do nothing but let someone who types it find you. None of them becomes a login, and none is proof of who anyone is. We cannot verify who you are, and we do not try.

The binding is permanent, and this is the term that matters most

Your account id is bound to that one public key at the moment the account is created, and the binding never changes. If the app ever tried to put a different key on an existing account, our server would refuse the upload outright. A different key is a different account. There is no key rotation, and there is no second factor to fall back on.

So if the key is gone, the account is gone. There is no password to reset, no recovery key, no recovery code, and no support route that gives an account back — an account we could restore on request is an account someone else could talk us into. We will not build one.

Your keys are deliberately kept out of iPhone backups — and so, as “The phone itself” below sets out, is your message history — so restoring a backup onto a new phone brings back neither. And if the app ever does find conversations on a phone with no identity key behind them, it treats that as final rather than quietly making you a new account: it tells you that this iPhone no longer has the identity key those conversations belong to, that the key cannot be restored — not from a backup, and not by us — that what is already there is safe to read, and that the identity can no longer send or receive. To keep talking you start a fresh identity, and the people you know add you again as a new contact.

We can remove rows from our own database, so we could delete a stranded account by hand — and section 03 describes the one case where we do: a parent’s request about a child, where the law hangs the duty on what we know rather than on what the requester can prove. Outside that case we will not delete an account, hand one over, or answer questions about one because someone quotes its id at us: an account id is a public thing, printed on a QR code you have shown people, and acting on a bare id would be a way of taking an account away from its owner. Section 13 says what that means for data requests.

The phone itself

Your conversation history is on your phone, in an ordinary app database. The app keeps that database — the decoy workspace too — inside a directory marked as excluded from an iPhone backup, iCloud or computer, so the database’s working files, including the journal that briefly holds copies of pages being rewritten, are skipped with it from the moment they exist; the notification extension’s spool of decrypted messages is marked the same way. So your message text and the photos in it should not exist inside a backup you make.

“Should not” rather than “cannot”: the exclusion is a flag our code sets on that directory and re-asserts every time the database is opened, and our tests check that it does, but we have not verified on a physical device that every backup pathway honours it — and a backup made before the version that moved the database into that directory first ran can still contain what the older design let through.

What a backup still can carry is the small shared files the notification part of the app uses: your own account id, the names you have for the people you talk to, your blocked list, your notification-preview level and its lease marker, and two badge counters. If you would rather Apple could not read even those, turn on Advanced Data Protection, or exclude Tacendum from iCloud Backup in iOS Settings. The How it works page and the Privacy Policy say the same thing; we would rather repeat it than let you infer an exposure — or a protection — that is not there.

So a restored backup restores neither the identity nor the reading: the keys and the message database were both left out of it. A new phone starts empty.

Keep the phone locked. Anyone holding your unlocked phone has your conversations. The app has its own passcode lock on top of the device’s — four to ten digits — with five attempts, then a wait that starts at thirty seconds and doubles up to fifteen minutes, and the wait survives relaunching the app. Nothing is erased after failed attempts. The lock delays a guesser; it does not destroy anything.

The lock also has a duress mode: a duress entry at the lock screen opens a separate, decoy workspace. There is no second secret to choose, to remember or to lose, and no separate duress code is stored anywhere. The decoy’s contents are fabricated when you set the passcode — generated from a bundled corpus and the phone’s random number generator, never from your real conversations — and a session opened that way sends no packet and changes no setting. It shows invented conversations and invented people. The one real thing in it is your own profile — your account id, display name, about line and picture — because a decoy that renamed you would give the act away. Whether using this is wise, or lawful, where you are is a judgement only you can make.

Machine accounts

Our server supports accounts that belong to a machine. One is created by the machine itself — the command-line client’s register --integration — and then bound, once, to the human account whose id its operator supplies: our server restricts who it may message, the owner can revoke it, and revoking or deleting it retires its key permanently — that key can never register again. A bare register makes an ordinary account with none of those bounds, and the class is fixed at creation: signing in later cannot change it either way. The Developers page says the same.

Eligibility, age, and children

You must be 18 or older to use Tacendum. That is higher than the law requires of us, and it is deliberate. Tacendum carries messages we cannot read, which means we cannot moderate them either — there is no filter, no scanning, and no way for us to see what anyone sends. A service built that way is not one we are willing to offer to a minor, and the App Store rating reflects the same judgement. You must also be legally able to enter into this agreement, must not use Tacendum if a law that applies to you forbids it, and must not use it if we have previously ended your account.

We do not verify age and we could not. The app never asks. What we hold — an account id and a set of public keys — says nothing about how old anyone is. The only age check anywhere in the chain is the one Apple applies at download; we add none.

If you are a parent or guardian

You have a right under United States children’s privacy law to direct us to delete the personal information we hold about a child, and we honour it on a parent’s good-faith word — the law hangs our duty on what we know once you have told us, not on what you can prove to us. This section says exactly what we remove and where our reach stops. Write to hello@tacendum.com.

What we would delete, by hand. There is no administrative screen, and the only deletion routes in our software are the one a signed-in device calls for itself and an owner’s revocation of a machine account bound to them (section 02). But our accounts table is an ordinary database table and a person with operator access can remove rows from it, so “we cannot” would be false. A correct hand deletion removes the account row; the claim row filed under the account’s public identity key; any messages still queued for it; its one-time prekeys; its live-connection row; every session it has; and its push-notification row — the same set the app’s own deletion removes. The claim row matters as much as the account row: leave it behind and the key is stranded — the next sign-in with it gets a conflict rather than an account. We would confirm in writing what we removed. The residues in section 12 apply here too: log lines carrying the account id are kept ninety days, and our database backups keep a deleted row restorable for up to thirty-five days.

What verification means, honestly. We cannot verify parentage — we hold nothing to check a claim against — and an account address proves nothing by itself: it is printed on a QR code the child has shown people. The children’s-privacy rule does not let that inability erase your right, so a good-faith request is acted on: tell us how you know the account is your child’s and what happened to the phone.

The stakes make that the right rule as well as the required one. Everything a hand deletion removes is an id, public keys, undelivered ciphertext and a push token, all of which one tap recreates — so a false request gains an impostor almost nothing, while refusing a true one would keep collecting from a child. We reserve refusal for a request showing affirmative signs of bad faith — this route being used to strip an account from someone the requester is targeting — and a refusal comes in writing, with the reason.

The best remedy is still the phone itself. If the child’s device is available to you, delete the account inside the app: that request is signed by the key that owns the account, it needs nothing from us, it is immediate, and it also wipes what is on the device — which is the part we can never reach. Where the device is not available, write to us and we do the deletion above by hand.

Where we stop. We cannot show you the child’s messages: they are encrypted, we hold no key, and we hold no copy. We cannot tell you who the child was talking to beyond the routing rows described in the Privacy Policy. We cannot reach the copies already delivered to the other person’s phone. And deletion does not prevent a new account: it frees the key, so whoever holds that phone can register again in seconds, and we would have no way of knowing. Everything on the device is on the device, and that is where a parent has the real remedy.

Once an account is deleted we hold nothing further for it, because there is nothing left to hold — no profile, no history, and no identifier row; the one trace is that a username the account held is kept from anyone else for thirty days before it is freed. We do not knowingly collect personal information from anyone under 18, and — this is the honest half — we have no mechanism that could recognise one. An account needs no phone number, no email, no name and no date of birth, and an email someone chose to link proves an inbox, not an age, so the minimum age above is a rule we state and cannot enforce. We would rather say that plainly than imply a check we do not perform.

What you may not do

Tacendum exists so that people can speak privately. Privacy is not cover for harming someone. You agree not to use Tacendum to:

• threaten, harass, stalk, intimidate or abuse another person, or keep contacting someone who has told you to stop;
• send anything that sexually exploits or endangers a child, in any form;
• send content that is unlawful where you or the recipient are, or that infringes someone else’s rights;
• impersonate another person, or misrepresent who you are in order to deceive someone;
• send malware, phishing, fraud, scams or unsolicited bulk messages;
• create accounts in bulk or automate account creation, other than a machine account used as described in section 02;
• attack, overload, probe or interfere with the service, evade its rate limits, or attempt to reach data that is not yours;
• use the service to break any law that applies to you.

If something here is being broken and you are part of the conversation, write to hello@tacendum.com. That address is the whole of our intake and a person reads it. Section 05 is honest about how little we can do with what you send.

Tacendum is not an emergency service. Do not rely on it — by message or by call — to reach emergency responders.

What we can and cannot do about it

Everything you send is encrypted on your phone before it reaches us, and we hold no key that would open it. That is the point of the product, and it has consequences a normal terms page would not admit.

• We cannot read, review, scan, filter or remove the content of a message or a call. Not on request, not on complaint, not under legal demand. The capability does not exist.
• A report shows us only what you choose to show us. The default report carries no message text at all.
• We cannot delete a message from someone else’s phone. Once a message is delivered it lives on their device, outside our reach, and deleting your own account does not reach into their conversation.

The Report flow is on a person’s profile. A report is that account’s id, a category, and — only if you pick them, one at a time — up to five message excerpts, which arrive readable by us; the screen says before you send that the text you attach will be readable by us. There is no scanning behind it, no block list on our servers and no server-side record of who blocked whom, and the reported person is never told. A report is kept 180 days, and the systems that write one cannot read one back — the Privacy Policy has the exact mechanics. The email address still works too, and either way a report, or a mail and whatever we decide because of it, is a record we hold. Saying we keep no moderation records at all would be a word game.

The tools that do work are in the app, on your phone. You can block a person: while they are blocked your phone shows you nothing from them and sends them nothing at all — no messages, reactions, edits, retractions, read receipts, screenshot notices, profile updates, vault items or call signalling. Blocked callers never ring.

Separately, “silence unknown callers” — a switch in Settings, on unless you turn it off — means someone you have never exchanged a message with cannot make your phone ring, whether they call you directly or add you to a room’s call; you get a missed-call row you can answer at your own pace, and they are told nothing.

One honest caveat, because the alternative would be a claim we cannot keep: Apple requires an app woken by a call to answer the system immediately, before it has decrypted anything or consulted any setting of yours, so a backgrounded phone can signal briefly before the call is identified. The moment it is identified the ring is dismissed. Removing even that would mean deciding on our server whether to send the call at all, which would require us to know who talks to whom — the record this whole service is built not to hold.

Our own enforcement is therefore narrow. We can act on what is visible from the outside — abuse of account creation, rate-limit evasion, flooding — or on what a participant reports to us, in the app or by mail, with whatever they chose to attach. We may end an account under section 12, and that is close to the whole of our power here. If you are in danger, your local authorities can do things we cannot, and keeping evidence on your own device is worth more than a report to us.

Your messages are yours

You keep every right you have in what you send. We claim no licence over your messages, photos or files, and could not exercise one if we did — we cannot read them. Nothing you send is used to train anything, because there is nothing legible to train on.

You are responsible for what you send, and for having the right to send it.

Screenshots

If you take a screenshot while a conversation is on screen, the app automatically tells the other person that you took one. There is no setting that turns that off: it is part of using Tacendum, not an option within it. That notice is a message like any other — it is encrypted, and it can raise a notification on their phone. It is not sent when the screen was already covered — the app-switcher cover, for instance — because nothing of the conversation was in the picture, and it is not sent to someone you have blocked. The app cannot stop a screenshot; iOS provides no way to, and any claim otherwise would be false. See How it works.

Photos carry their own metadata

A photo you send may still carry what your camera put in it, including the place it was taken. The app asks the photo picker to downscale before sending, which re-encodes some photos and leaves others untouched, and it does not strip metadata itself. So do not assume a photo has been cleaned. If the location matters, remove it before you attach the picture.

Disappearing messages

Either of you can set a timer on a conversation. The choices are one hour, one day and one week; a week is the longest the app offers. It is off unless one of you turns it on, and the newest setting wins on both phones — the setting itself travels between the two phones as an encrypted message, so we see a message went, not what it said. Your own messages start their clock when you send them; messages you receive start theirs when you read them. When the time is up the message goes, together with its attachments and reactions. The sweep runs when you open a conversation — it is not a background timer — so an expired message is removed the next time the app is used to read something, not at the instant the timer elapses.

The shared vault

An item in the vault is stored and sent exactly like a message: same encryption, same database, same lock on the phone. It is not a password manager. There is no separate password, nothing fills in for you, and there is no recovery key — if the phone is lost the vault goes with it. Vault items are deliberately exempt from the disappearing-message timer: an item stays until one of you removes it. Saving or removing one also leaves a short notice in the chat, and that notice still carries the value until it is removed there or a timer takes it.

Copying a vault item puts the value on the iPhone pasteboard, where every app on the phone — and every device signed into the same iCloud account — can read it. The app clears it about a minute later, which cannot un-read anything already read and does not happen at all if you force-quit first. The clear checks the pasteboard before wiping it so it never destroys something you copied in the meantime. That check is why iOS may ask “Tacendum wants to paste” a minute after a copy.

Calls, and your IP address

Voice and video calls between two people are end-to-end encrypted; the keys are on the two phones. A room can also carry a voice call — up to six people, voice only, never video — built as a separate encrypted connection between each pair of phones on it, so each leg’s keys live on the two phones at its ends and nowhere else. No call statistics leave your device. The app reads one number for the bars on screen — a call-quality level computed on the phone from packet loss and jitter, nothing more. A full statistics report would carry the other person’s network addresses, so the summary the native layer exposes was written with those addresses already stripped out of it, and nothing in the app calls it at all — the Privacy Policy has the detail.

A call still needs a path between two phones, and finding one starts with a question every call has to ask: what does my address look like from outside? The server that answers is ours, and it is the same machine as our relay — same hostname, same port, same process. So state it plainly: our relay machine sees the public IP address of every phone on a call that asks our server for candidates — both phones of a one-to-one call, every participant of a room’s voice call — and as the service is deployed that is every call — including the ones that then go direct. What differs between a relayed call and a direct one is not whether we see your address. It is whether we carry your media, and whether the other person’s phone learns your address.

Your first call with a particular person is relayed by default, so that a direct connection does not hand your home IP address to someone who has never had it. After that the app follows whatever was chosen for that person, and a direct call reveals each side’s IP address to the other. There is an app-wide always-relay switch that overrides every per-person memory; with it on, no address of yours is offered to the other phone at all.

When a call is relayed, the relay is ours, not a third party’s. It forwards encrypted media it cannot decrypt. It writes a session log to a file on its own disk, rotated daily and kept about seven days, and never shipped anywhere else — the verbose mode that would record peer addresses for every allocation is switched off. The credential your phone presents to the relay names you to it only as a salted hash, so the relay cannot join its own records to your account, and neither can anyone who takes those records without our salt. We hold the salt, so we could. The credential lasts twelve hours. The Privacy Policy gives the detail.

Availability

Tacendum is early software. We may change, suspend or discontinue any part of it, and we may add or remove features. We will try to give notice before a change that would lose your data, but we cannot promise it in every case. Section 14 covers shutting the service down.

Every message you send is written to our delivery queue as ciphertext before anything else happens, and removed when the other phone acknowledges it — normally within seconds. A message that is never acknowledged expires thirty days later, undelivered. Encrypted attachments expire from storage thirty days from upload, plus up to seven days as a superseded copy. If the other phone never comes online in that window the message is simply gone; there is no copy for either of you to ask us for. One honest detail about “expire”: our code refuses an expired row the moment it expires and never serves it to anyone, while the database reaps it on its own schedule, a day or two behind — unusable immediately, physically gone shortly afterwards.

The service depends on your network, on Apple’s push service, and on infrastructure we do not control. It will sometimes be unavailable. Nothing in the app limits where it can be used, and you are responsible for complying with the law where you are, including any law about encryption software.

Cost

Tacendum is free to use today. There is no payment processor anywhere in the app, the servers or this website, and no advertising of any kind. If that ever changes we will say so before it does, and you will be able to leave by deleting your account. Your mobile carrier may still charge you for the data the app uses.

The website, and the waitlist

This site is static pages. It loads no third-party fonts, scripts, analytics or embedded media, and it sets no cookie of its own. There is one exception, and it only appears if you use the waitlist form: when the silent bot check cannot clear you, your browser fetches a small script from awswaf.com, which belongs to our infrastructure provider, and that script sets a token cookie on tacendum.com. That is the only thing this site ever loads from elsewhere and the only cookie it can set.

One thing reading a page does leave: our infrastructure provider’s firewall samples a share of requests to this site, ordinary page reads included, and a sample carries the reader’s IP address for a few hours. We do not collect it, we cannot query it as a record of you, and it is not ours to keep or delete — but it exists, so we name it rather than claim a page read leaves no trace.

We do not respond to Do Not Track or Global Privacy Control signals, and the reason is that there is nothing for them to switch off: no analytics, no advertising, no profiling, and no third party collecting personal information across sites through this site.

The waitlist

If you give us an email address on the form, we store the address and the time you gave it. Nothing else — no IP address, no browser string, no name. It is used for one purpose: to tell you when Tacendum is available.

What is true today, plainly: those addresses are stored with no unsubscribe link and no automatic expiry, because neither has been built yet. Nothing has been sent to that list — not one message.

What we commit to, whether or not anything is ever sent:

• An expiry. Twenty-four months from the day you gave us the address, then it is deleted — automatic, configured by 31 December 2026, and not conditional on our sending anything. Until it is automatic we will apply the twenty-four-month rule by hand, and if we decide there will be no launch email at all, we delete the list instead of keeping it. Once the announcement has gone out, we delete the whole list within thirty days, because it has no remaining purpose.
• A one-click unsubscribe in any message we send, honoured in our records within ten business days. The mechanism will keep working for at least thirty days after the message goes out. Using it will cost you nothing and will not require anything from you beyond your email address — no account, no reason, no form.
• The sender’s valid physical postal address in the message itself, because United States law requires a commercial email to carry one.

That last point is a real constraint, not a formality, so read it as one. We do not publish a postal address on this site and we will not: there is no office, and the alternative would be somebody’s home. The obligation attaches to the message, not to this page, and the law counts a registered post-office box or a commercial mail receiving agency mailbox — so before any send we would obtain one and put it in the message. If we cannot satisfy the rule, we do not send. We would sooner delete the list than send a message that breaks it, and we are not promising you a launch email here.

You can have your address removed at any time, with no reason and no delay beyond the time it takes to read the mail: write to hello@tacendum.com from the address, or naming it, and we delete the row. Our database keeps continuous backups, so a deleted row stays restorable for up to thirty-five days before it is gone for good.

The software and its licence

Tacendum is licensed AGPL-3.0-only. That is not a marketing gesture: the app, the command-line client and the server’s authentication function all link libsignal, which is AGPL, and the honest response was to comply rather than to engineer around it.

The source is not published yet. It goes up at launch, under that licence, at no charge, tagged per release. Today github.com/MiranaTechs/Tacendum is a reserved and empty repository: it answers, and it serves nothing. Section 6(d) of the licence — the object code offered from a designated place, with the directions to the source next to it — is how this will work once the repository is up. Until then it is the written offer below that carries the obligation, and the app already names its own build: Settings → About links the source for the exact build you are holding, so you will never have to guess which source matches which binary.

The written offer is the route until the repository is up, and a voluntary supplement afterwards: write to hello@tacendum.com, name the version you have, and we send you its source — at no charge, for at least three years from the date we last conveyed that version, to anyone who possesses a copy. Nothing about your rights under the licence waits on the repository, and nothing in these terms conditions them on your using GitHub.

Source alone cannot prove that a running service or a phone binary was built from it. “We cannot read your messages” is worth exactly what your ability to check it is worth, and the source — sent on request today, served from the repository once it is up — is the part of that we can actually give you.

Nothing in these terms limits your rights under that licence. These terms govern the service we operate and the official builds we publish; they add no conditions to the code. Where a term here would conflict with the licence as it applies to the code, the licence governs. Third-party components keep their own licences and notices, and those notices travel with the source.

The source also carries an additional permission, under section 7 of the AGPL, for App Store distribution of the code whose copyright we hold. It cannot extend to third-party components, and it does not — libsignal in particular. Anyone redistributing a modified build should reach their own conclusion about that rather than inheriting ours. If you run a modified version as a service, what the licence asks is that the people using it can get its source too.

Ending it

By you

Delete your account in the app. That is the only exit the app offers, and it is deliberate: there is no sign-out button, because your conversations exist only on your device and “sign out and come back later” is a promise the design cannot keep. The service’s own interface does have routes that revoke a session, because sessions last thirty days and a leaked one should be killable. The iPhone app does not use them.

Deletion needs a working connection. It acts on our side first — it purges any ciphertext still queued for you, deletes your one-time prekeys, deletes your push-notification row, drops your live connection row, deletes the account row and the claim on your identity key, and ends every session for the account, not just the one on this phone. Only once that succeeds does it wipe the app’s local data, including your message history, your keys, your lock settings and the duress workspace. Offline, it fails and destroys nothing. It is irreversible.

What deletion does not reach is worth naming rather than burying, because it is longer than one line:

• Log lines carrying your account id. Ten kinds of event write one, including the line recording the deletion itself. They are kept ninety days, so they outlive the account.
• Messages you already sent to other people. Those rows are filed under the recipient, not under you, and they carry your account id. They go when that person’s phone acknowledges them, or thirty days later.
• Stored attachment blobs. Nothing links them back to an account; they expire on their own thirty-day schedule.
• The access log for the attachment store, which records which object was touched, from which address, and when. Uploads go straight from your phone to the store, so an upload records your phone’s address; downloads come through our content delivery network, so a download records that network rather than the recipient’s phone. That log expires after ninety days — the same ninety days as the log lines above, so neither record outlives the other. The expiry was configured on 4 August 2026, ahead of the date this page had committed to; the dated note is in the Privacy Policy, which says the same about the log itself.
• A report you filed, or one filed about you. Reports live in their own table for a hundred and eighty days, and deletion does not reach into it — deliberately, since an account that could erase the reports about itself by deleting and re-registering would defeat the one record that shows a repeat pattern.
• Rate-limit counters keyed by your account id. Each lasts its counting window plus an hour — up to about two hours for the slowest of them.
• Our databases keep continuous backups, so a deleted row stays restorable for up to thirty-five days after it is deleted.
• For a machine account, the retired identity key. That record is permanent by design and is never cleared.
• Anything already on the other person’s phone.

The Privacy Policy covers the same ground with the reasons attached, and it is the fuller of the two. If the two ever disagree, the Privacy Policy is the one to believe about data.

By us

We may end your account if we reasonably believe you have broken these terms or the law, or to protect the service or the people using it. That sentence sounds broader than the reality, so here is the reality. There is no suspension button, no ban list and no moderation console anywhere in the software, and no endpoint that acts on somebody else’s account. The only account-removal route in our interface is the one you call yourself, plus an owner’s power to revoke a machine account bound to them.

If we ended an account, we would do it the way we would delete a child’s account under section 03: by hand, removing the same set of rows a child-account deletion removes — a person with operator access doing it deliberately, one row at a time. It is not something a program does: no code we run on the internet is allowed to query or scan the accounts table, so there is no feature and no automated route that could work through our users. A person holding operator credentials is a different matter, and that is exactly the access a hand deletion uses. There is no automated moderation either, because there is nothing for it to read.

If we do that and you write to hello@tacendum.com, a person will read it, give you the reason, and consider the answer in the same thread. We do not have a formal appeals body. We have an inbox and an obligation to answer it.

If your account ends for any reason, the data on your phone stays there until you delete it, and anything you already sent stays on the recipient’s device.

Your data, and what we can answer

The Privacy Policy is part of this agreement and is the full account of what we hold. This section is about the requests you can make and what actually happens to them.

Timing

We acknowledge a privacy request within 10 business days of receiving it. We answer it substantively within 45 days. If we need longer we may take a further 45 days — 90 in total — and we will tell you the reason before the first 45 days are up.

Appeal

If we refuse a request, you can appeal it. Reply to the same address and say you are appealing. We will answer within 45 days, in writing, with the reason. If we refuse the appeal, we will give you the route to complain to your state Attorney General — in California, to the California Privacy Protection Agency as well. Virginia, Colorado and Connecticut require that route by name, and so now do a dozen or more other states; we offer it wherever you live rather than checking your state first.

No penalty for asking

We will not deny you the service, charge you a different price, give you a worse version of it, or treat you differently in any way because you exercised a privacy right. There is no price to change and no tier to demote you to, but the commitment is the same.

We do not sell personal information and we do not share it for advertising: there is no advertising anywhere in this, and no analytics, trackers or crash reporter in the app. You may use an authorised agent; we will ask them for the same thing we would ask you for. We operate entirely online and deal with you directly, which is why an email address is the whole of our intake.

What we actually hold for an account

An account is an anonymous key pair. For one we hold:

• a 26-character account id;
• public key material — your identity key, your signed and post-quantum prekeys, and a pool of one-time prekeys;
• a routing row for each message still queued for you, carrying sender, recipient, time and ciphertext;
• a session row while you are signed in;
• a connection row while you are connected;
• short-lived rate-limit counters — most keyed by your account id, and the sign-in one keyed by your phone’s public IP address, so a sign-in writes that address into a database row for roughly an hour;
• a push-notification row holding the device token Apple issued to your phone;
• and, for a machine account, which account it is bound to.

We hold no name for an account. For an email address you chose to link, and for a username you claimed, we hold a keyed scrambling — never the address or name itself — with the time it was verified and your findability switch; the Privacy Policy states what that scrambling does and does not buy. Separately, the accounts table still contains claim rows written by the phone-registration path we removed, account rows from before that change may carry a number as a leftover field, and none of that residue has ever been purged; those rows are unrelated to the linking described here. Two entries above are worth naming twice: an Apple device token is a device identifier, and Apple can match it to a person even though we cannot; and a claim row files your public identity key in the clear as its own key.

Now the limit, which is large

None of that can be matched to you by us. That is the design, and it has a cost you should understand before you write to us: we cannot verify that a request about an account comes from the person who holds it.

An account id is a public thing. It is on a QR code you have shown people. If we honoured an access, correction or deletion request on the strength of someone quoting an id, we would be handing accounts to whoever asked convincingly — which is the same failure as an account-recovery service, arriving through the legal door instead. So for account data we will not do it. California’s law says the same thing from the other side: a business is not required to re-identify data, to keep data it would not otherwise keep, or to collect more information about you in order to verify a request. Where we cannot verify, the answer the law expects is to refuse and explain, and that is what we will do.

What can be done, and it is the strongest of the lot:

• Delete the account in the app. That is a deletion request that needs no proof to us at all, because your phone proves it with a signature we can check. It removes the server-side rows. Section 12 sets out exactly what goes and what is left.
• Read the Privacy Policy as your access response. It lists every category we hold, for every account, with the retention period for each. For an account there is nothing individual to add — the categories are the answer, and there is no profile behind them.
• Correction has almost no surface. Almost nothing we hold about you is the kind of fact that can be wrong — your display name, your picture and the names you give your contacts never leave the two phones.
• The waitlist is different. An email address is something we can match. Write from the address, or name it, and we will confirm whether it is on the list, correct it, or delete it.

Two more admissions rather than reassurances. Everything we hold sits with our infrastructure provider in the United States. We have not put a transfer mechanism in place for people outside it — no standard contractual clauses, no adequacy decision we are relying on — and we have not appointed a representative in the European Union or the United Kingdom. We have not appointed a data protection officer. Those are gaps, stated as gaps.

If this changes hands, or shuts down

We may transfer this agreement, the service, and the data described in the Privacy Policy to someone else — on a merger, an acquisition, a reorganisation, a sale of assets, or in bankruptcy. The commitment we can actually keep is the one we control: in any transfer we negotiate, we will require the buyer to take the service subject to these terms and the Privacy Policy as they stand, until they publish a change under section 19, and we will post the transfer on this page. The Privacy Policy makes the matching commitment about the data itself: a buyer takes it subject to that policy as it stands, any material change is posted there first on the same thirty-day timetable, and those thirty days are your chance to delete the account before the change takes effect.

Where we would not control it, we will not pretend. In a bankruptcy or a receivership the estate can sell assets, and a promise written on this page is weaker than a term written into the sale. What protects you there is the court’s own process for consumer data, not this sentence — and we would rather you knew that now than discovered it then.

You cannot transfer your side of this agreement, and there is nothing to transfer: the key is the account, and it is on your phone.

If we shut Tacendum down, one fact matters more than the announcement. Our databases, storage buckets and logs are deliberately configured to survive the infrastructure being torn down, so that a mistake during a deployment cannot delete everyone’s queued messages. Shutting the service off therefore does not delete anything by itself. So the commitment is explicit: if we wind Tacendum down, we will say so on this page at least thirty days beforehand where circumstances let us, and we will delete the account table, the queued ciphertext, the attachment store and the logs rather than leave them sitting there. A transfer to a successor is the one case where they would move instead of being deleted, and we would say that here too.

No warranty

Tacendum is provided as it is, without warranties of any kind, whether express or implied, including any implied warranty of merchantability, fitness for a particular purpose, or non-infringement. To the extent the law lets us, we disclaim them.

We do not warrant that the service will be uninterrupted, that a message will arrive, that it will arrive quickly, or that data will not be lost. We take security seriously — see How it works and the Privacy Policy — but no software is free of defects, we have not published an independent security audit, and the source we send you under section 11 shows how the system is designed without proving that any particular build or running service was made from it.

Some jurisdictions do not allow these exclusions. Where that is true, they do not apply to you.

Limitation of liability

To the extent the law allows, we are not liable for indirect, incidental, special, consequential or punitive damages, or for lost data, lost profits or lost goodwill, arising from your use of Tacendum. Our total liability for any claim relating to the service is limited to US$100.

Nothing in these terms limits liability that cannot be limited by law, including liability for death or personal injury caused by negligence, or for fraud. Some jurisdictions do not allow some of these limits; where that is true, they do not apply to you.

Indemnity

If a third party brings a claim against us because of what you sent through Tacendum, or because you broke these terms or the law, you agree to defend and indemnify us against that claim, to the extent the law allows. We will tell you promptly if such a claim arrives, and you may not settle it in a way that imposes an obligation on us without our agreement.

The App Store

The Tacendum app is distributed through Apple. Apple is not a party to this agreement and is not responsible for the app or for supporting it. Apple’s own terms also apply to your use of the App Store, and Apple can see that you downloaded Tacendum. Apple also carries our push notifications: when your phone is offline, the encrypted message body and the sender’s account id pass through Apple’s push service so the message can arrive, and a call sends Apple the caller’s account id and a timestamp. The Privacy Policy says exactly what Apple receives.

The additional terms Apple requires for apps distributed through the App Store are these. This agreement is between you and us, not Apple, and we alone are responsible for Tacendum and its content. Apple has no obligation to furnish any maintenance or support for it. If the app fails to conform to any warranty we give, you may notify Apple and Apple will refund the purchase price, if any; to the maximum extent permitted by law Apple has no other warranty obligation. We, not Apple, are responsible for addressing any claim relating to the app, including product liability, any failure to conform to legal requirements, and any claim that it infringes intellectual-property rights. Apple and its subsidiaries are third-party beneficiaries of these terms and may enforce them against you. (We give no warranty at all under section 15, so the refund clause has nothing to bite on; it is Apple’s required wording and we carry it as written rather than edit it.)

Changes to these terms

We may update these terms. The “last updated” date at the top changes when we do, and a revised version carries the date it takes effect.

Now the part that decides what a change is worth. We still have no way to reach you. Even if you linked an email address, we hold only a scrambled form of it, and a code reaches you only because you typed the address into the app a moment before — there is no stored address to write to, and we will not build one for announcements. The push channel wakes your phone for a message or a call that another person sent — it has never carried anything written by us — and there is no screen in the app that shows you a notice from us. This page is the only channel there is, and we are not going to pretend it is a notification.

So we will not tell you that carrying on using Tacendum is how you agreed to something you were never shown. What is true is plainer and less flattering: a revised term takes effect on the effective date printed on the revised page, and from that date it governs the service. That is a determinate trigger, and it means a term can begin to apply before you have read it. We say so rather than dress it up, and the three commitments below are what we offer in exchange.

• A change that materially reduces your rights or widens ours is posted here at least thirty days before its effective date — so the page is different for a month before anything about it is.
• Nothing applies backwards. A change does not alter how we treat something that has already happened, and it does not change how data already collected is handled: that stays governed by the policy in force when it was collected, unless the new one is more protective of you. If we ever wanted to use something already collected in a way the policy in force did not permit, posting a new page would not be enough — that needs your agreement, there is no way to ask you for it today, and building one would have to come first.
• We keep the earlier versions. Ask at hello@tacendum.com for the version in force on a given date and we will send it to you.

If you disagree with a change, delete your account. That remedy is complete and immediate, because your conversations are on your phone and nothing here holds them.

If we ever build a way to show you a notice inside the app, we will use it for material changes. That is not a feature promise; it does not exist today.

Governing law and disputes

These terms are governed by the law of the State of Delaware, United States, without regard to its conflict-of-law rules. Where the law allows the parties to choose, disputes will be resolved in the state and federal courts located in Delaware, under ordinary court proceedings. There is no mandatory arbitration clause and no class-action waiver in these terms. If you are a consumer, the mandatory protections of the country where you live still apply, and nothing here removes your right to bring a claim in your local courts where the law gives you one.

If any part of these terms is unenforceable, the rest stays in force. Not enforcing a term on one occasion does not waive it.

These terms and the Privacy Policy are the whole agreement between us about the service we operate — alongside two things they do not replace: the licence in section 11, which governs the code, and Apple’s terms in section 18, which govern the App Store.

Contact

Write to hello@tacendum.com. That is the address for everything in this document: questions, privacy requests, appeals, an account we have ended, a source request, or a child’s account.

For a security problem, write to security@tacendum.com — hello@tacendum.com reaches the same people, and the reporting terms are on the How it works page. Either address gets to us.

Contact is by email; section 10 and section 13 say why there is no postal address and no data protection officer.

Tacendum is operated by Mirana Technologies Inc.

See also the Privacy Policy.