Privacy policy

Last updated: 23 September 2026.

1. Who is responsible for your data

You can write to us about any privacy matter at angel@engravitysigns.com.

The service is operated by that same entity from its own server, and the app is called T-kall (identifier com.bitali.tkall).

2. The essentials, in a table

End-to-end encryption means the content is encrypted on your device and is only decrypted on the other person's. We move sealed envelopes. The full guarantee is provided by the installed application; in the browser, the program that does the encrypting is downloaded from our server every time you open it (see Security). But not everything travels inside the envelope, and that is what almost no privacy policy tells you:

3. What data is collected, exactly

3.1. Account data

• Your primary email address (it is your login identifier).
• The name others see you by.
• An Argon2id hash of your password. The password in the clear is never stored.
• The organization you belong to and the account creation date.

3.2. Profile data requested at sign-up

• Date of birth and age (the app requires you to be at least 13).
• An approximate location of the "city, country" kind, optional.

These three fields are stored encrypted in the database (AES-256-GCM). It is worth understanding what that protects and what it does not: it protects against a leak of the database, because whoever takes it away will see opaque text. It does not protect against us: the key is on the server and we can decrypt them. This is different from the encryption of messages, where we do not have the key.

The location is not GPS. The app does not ask for the location permission. What it does is suggest a text to you from the time zone and language the phone already has configured; that calculation happens on your device and you can correct it or leave it empty.

3.3. Your extended identity

• Up to three email addresses and two phone numbers associated with the account.
• Whether each one is the primary, whether it is verified and which of your profiles it belongs to ("Personal", "Work"…).
• When you request to verify an email, a hash of the code we send you (you paste it into the app and it expires in 30 minutes) and its expiry date. The code itself is not stored.
• If you request a password reset, a hash of the token that goes in the link, its expiry (one hour) and the date on which it stopped being valid, whether because you used it or because you requested a new one (each request voids the previous ones). The token itself is not stored; and a voided token is not deleted, it is marked, so we can tell you "it no longer works" without revealing whether it existed.

Email addresses and phone numbers are not encrypted, and that is not an oversight: they are the way another person finds you. If they were encrypted, no one could search for you by them.

3.4. Your devices

• The name you give each one ("Pixel 10", "Chrome on Windows").
• Their public encryption and signing keys. The private ones never leave the device and we do not have them.
• The notification identifier (the Firebase "token"), if you enable notifications.
• Dates of registration, approval, revocation and last connection.

3.5. Your conversations

• The encrypted envelope of each message. It is an opaque block: we cannot read its content, nor search inside it, nor hand it over readable to anyone.
• The metadata of each message: which conversation it belongs to, who wrote it, when, whether it is a reply to another and whether it was edited or deleted.
• A random identifier that your own phone makes up for each message, so that a resend after a network drop does not duplicate it. It is different for each message and does not identify the device.
• The marker of how far you have read in each conversation.
• The videos and files you attach (documents, PDFs, archives…), which because of their size do not fit inside the message. They are encrypted on your device and uploaded to a file store on the same server, as a nameless block of bytes. The key to open it travels inside the encrypted message, so we cannot see it. Of the file we do not store who uploaded it, who it is for, what it was called or what type it is: only its size and the date. The only thing recorded per account is how many bytes you have uploaded in a 24-hour window, to curb abuse: a counter separate from the database (in Redis, which does write to disk), stored only with the account's internal identifier and which expires on its own 24 hours after that window's first upload.

The images and voice notes you send travel inside the encrypted message itself; those are not uploaded to any separate store. Videos and the other attached files are, for the reason above, and the file deletes itself in the daily sweep following its 30th day since being uploaded —between 30 and 31 days—, whether or not you deleted it earlier. The copy the other person has already downloaded to their phone is theirs and we do not touch it.

3.6. Your appointments

• The type (call, video call or scheduled message), the time in UTC and the duration.
• Whom you invited (the email or number) and whether they accepted.
• The title and notes, encrypted on your device (only the guests open them; we do not have the key), plus the wrapped keys for each invited device.
• A hash of the appointment's access link, never the link in the clear.
• If the appointment is a video call, the identifier of the video room that is created for it when it is scheduled (section 3.11). That video call goes through the rooms server (section 6.2) even if there are only two of you, and once the appointment is canceled no one else can join its room (anyone already inside is not removed). The title of the appointment is not sent to that server: it stays encrypted.

3.7. Your contact list

• The name you give each contact and the notes you write about them.
• The emails and phone numbers you note down for that person, who may not have a T-kall account.
• The contact requests sent and received, with their status and their dates.

The notes are stored encrypted in the database (AES-256-GCM), like the profile data in section 3.2 and with the same two faces: they protect against a leak of the database, but not against us, because the key is on the server and the server decrypts them each time you open your contact list. It is not the on-device encryption of messages, nor that of an appointment's notes.

The rest —the name you give each contact, their emails and phone numbers, and the requests— is stored in the clear on the server. And mind what that implies: by noting someone down in your contact list you are giving us their contact details. Only note down people who would reasonably expect to be there.

The app does not read the phone's contact list. It does not ask Android for that permission and does not upload any contact list: you type each contact in by hand.

3.8. Teams, channels and organizations

• The teams, channels and organizations you belong to and with what role.
• The invitation codes that are issued and how many times they have been used.

3.9. Moderation

• Whom you have blocked and who has blocked you.
• The reports you file or receive, with the reason you write. That reason is stored encrypted in the database with a key of ours, like the notes in your contact list (section 3.7): it protects against a leak, not against us, because it is a request addressed to us and an operator decrypts it to review it. Of each report we also store its status, whether it was flagged as priority, who resolved it, when and with what decision. If an account is sanctioned, it is recorded from when, until when, with what scope, with a reason code and which report it is due to. There is no panel inside the app: a person with access to the server reviews it. It does not include the content of the reported messages, which remains unreadable to us. And a precision that matters: these records are not deleted with the account (section 8), so that closing your account is not the way to escape a review.

3.10. Technical data

• Your IP address, while you are connected. It is used for rate limiting (to prevent brute-force attacks and abuse) and is recorded in the web server's logs.
• Your session: we store the hash of the refresh token (never the token) and, for each device with an open session, the public key with which that device signs its requests and its fingerprint, a label for the browser or system ("Chrome on Android"), what kind of store its private key lives in (device software or hardware), which device of your encryption identity and which refresh token it is bound to, and the dates of registration, last use, expiry (30 days from last use), closing and, if the key was rotated, when.
• Server operational logs. They are written so as not to contain full email addresses (they are obfuscated to j***@example.com) nor conversation identifiers.

Retention of those logs: they are not archived. Each service on the main server keeps at most 50 MB of log —five 10 MB files— and the oldest is discarded on its own as new entries come in. There is no backup or historical archive outside that rotation. How much time that window covers depends on traffic, so we do not give you a number of days: it would be made up. The rooms server, which is a different machine (section 6.2), keeps its own logs and is not part of this rotation: its retention period is in section 8.

3.11. Meetings by link and rooms for video appointments

• Every time you create a meeting with "Meet now" or schedule a video appointment, a record of that room is stored with: who created it (your account's internal identifier); a hash of the link, never the link in the clear (for an appointment the link is not even used: a random one is generated and discarded); when it was created; when it expires —after 30 days for "Meet now"; for an appointment, two hours after the time it ends—; and, if it was closed earlier, when: because the host revoked the link or because the appointment was canceled.
• The database does not store who joined or when (the rooms server's logs may have it: section 8), nor the name you give the meeting: that name only passes through the rooms server (section 6.2). Who is waiting in the waiting room is kept in the server's memory while they wait, and whom the host has removed, until the link is revoked, the appointment is canceled or the server restarts; none of it is written to the database.

These records are not deleted today, not even when the account is deleted: the retention period is in section 8.

4. What we do NOT collect

• There is no advertising or ad profiling.
• There is no analytics: no Google Analytics, no Firebase Analytics, no Crashlytics, no measurement SDK of any kind inside the app.
• We do not use the Android advertising identifier.
• We do not read your phone's contact list.
• We do not ask for the location permission or collect your GPS position.
• We do not sell, rent or hand over data to third parties for commercial purposes.
• This website has no cookies and no analytics. The homepage loads its fonts from Google Fonts, so when you open it your browser requests those files from Google, which sees your IP address; this page, Security and Delete account load nothing from other domains.

5. What they are used for

• Providing the service: delivering messages, setting up calls, notifying about appointments, managing teams.
• Identifying you: signing in and letting those who have your email or number find you.
• Security: rate limits, session-theft detection, approval of new devices.
• Moderation: handling reports and blocks.
• Legal obligations, where they exist.

We do not use your data to train models, nor for advertising, nor for any purpose other than operating the app.

6. Who they are shared with

These are all the third parties involved today. If one day there is one more, it will appear on this list before being activated.

6.1. Google — push notifications (Firebase Cloud Messaging)

It is what lets the app notify you with the screen off. Firebase is not a sealed envelope: Google sees what is sent to it. That is why the notification we hand it comes from a closed, short list of fixed texts, none of which names anyone.

Google receives:

• your device's notification identifier (the envelope's address);
• the moment it was sent;
• the class of notification, from a closed list of six values (message, appointment, appointment invitation, appointment reply, contact registration, call);
• the text that will be shown to you, which is one of seven fixed ones with nothing interpolated inside: "You have a new message", "You have an appointment invitation", "Someone has replied to your appointment invitation", "Someone from your contacts is now on T-kall" and, for an appointment reminder, "Your appointment starts shortly", "… in under 10 min" or "… soon". The title is always "T-kall". For a call no text travels: Google only receives "it's a call" and the notice "Incoming call" is written by your own phone;
• whether the notification is urgent or not (calls are marked urgent so they ring even if the phone is at rest);
• the IP address your phone uses to talk to Google's servers.

Google does not receive:

• the content of any message (we do not have it either);
• the name or the identifier of whoever writes to you or calls you;
• the identifier of the conversation, the call or the appointment;
• the title of the appointment;
• the exact time of the appointment: the reminder gives the rough band and not the minutes remaining, precisely so that two notifications in the same minute do not betray that two people are going to the same appointment.

On the lock screen you see one of those seven texts —or "Incoming call", which your phone composes—; who wrote to you appears only when you open the app, already decrypted.

If you do not want notifications, Google does not find out you exist. As long as you do not accept notifications, the app does not register your phone with Firebase: Google's component comes inside the app and loads with it, but it starts off switched off and never gets to request any identifier or connect. It only switches on —and only then does Google receive an app installation identifier and the IP address it connects from— at the exact moment you accept receiving notifications.

If you decline them and later change your mind, it switches on then. And if you sign out, it switches off again and the identifier is deleted on Google's servers, not just on ours.

An honest precision, because the difference matters: if you had already accepted notifications before this version, your phone is already registered and will stay so —it is precisely what keeps the notifications reaching you without having to accept anything again—. To undo it, sign out of the app: almost always that is enough. We say "almost" because there is a real gap: if you sign out without the app having managed to start up notifications after updating —for example, if you opened it offline—, the deregistration at Google may end up not happening. Signing in again with notifications working and signing out once more fixes it.

6.2. Call servers (STUN, TURN and rooms), our own

To connect a call, each device needs to find out its own public address on the internet, and for that it asks a STUN server. That server is ours. Until July 2026 Google's public server was used, which saw your device's IP address on every call; it was changed precisely so that would stop happening.

When the two networks do not allow a direct connection, the call also passes through a relay server (TURN), also ours, which forwards the already-encrypted traffic: it moves packets it cannot decrypt. It sees the IP addresses of both ends and the duration of the relay.

What this change does not solve, and it is worth knowing: your device has to resolve our call server's name by DNS, so whoever provides your DNS —your carrier, usually— can deduce that you are about to make a call, though not with whom. And notifications still betray the moment of a call through the other door (section 6.1).

The rooms server. When a call does not go from one device to the other, a rooms server gathers and distributes it; it is also ours (the software is LiveKit, which is open source). Group calls in a channel, a chat's group call button, "Meet now" meetings and video appointments go through it; the last two always, even if there are only two of you in the meeting. One-to-one calls made with a chat's call and video call buttons do not go through it. And a difference that matters: the rooms server is a different machine from the one running the rest of the service, and it is in the United States (sections 6.3 and 7).

What that server sees of each call that goes through it:

• who you are inside the room: your account's internal identifier and your display name;
• your IP address and that of each participant;
• which room you join, by its technical name: the identifier of the channel or of the meeting, not the channel's name;
• when each person joins and when they leave;
• what each person publishes —microphone, camera or screen share— and whether it is muted (when a meeting's host mutes someone, it is done through that server);
• technical data about your connection: the version of the calling software the app uses, the browser or system you connect from —what your browser tells any web server— and, if the device reports it, the type of network (Wi-Fi or mobile data);
• whether each device's version of the app can encrypt the call on the device (each device announces it so the room knows whether it can be encrypted), and the technical "I can't decrypt you" notices that the devices send each other;
• the meeting's name, if the host gives it one when creating it with "Meet now". That name is shared with the others over the room's data channel, which is not encrypted on your device —only the audio and video are—, so the rooms server can read it. We do not store it in the database. If the name is sensitive, leave it out.

What it does not see is the audio and video, which are encrypted on your device (SFrame) as long as everyone present is on a version that supports it. If someone joins with an old version, that call drops to encryption that reaches only as far as the server for as long as that person is present —the app says so inside the room—, and during that time the rooms server could see and hear it. No call is recorded: neither the app nor our server ever asks for a recording —they have no such feature—, and the permission used to join a room does not include one.

Our main server has a notice from the rooms server ready so that it can kick out again, from a meeting by link, anyone the host has removed, but today that notice is not switched on. If it is switched on, it will be written here first. And it is worth knowing now how it would work: the rooms server would report what happens in every room —who joins and leaves, and which room, including a channel's rooms—, and our server would use it only to kick a removed person out again; it would discard the rest without storing it.

A correction that has to be stated as-is: until 23 September 2026 this page named the rooms server, but did not say that it is a different machine, nor that it is in the United States, nor what it sees; and section 7 claimed that everything was on a single machine, which was not true.

6.3. Hosting

• This website is hosted on Hostinger. It serves static files; its access logs include IP addresses, like any web server.
• The app's server runs on a private server (VPS) contracted from Hostinger, in a data center in Frankfurt (Germany). That is where the database and the encrypted envelopes live. There are no third-party cloud services in between: no analytics, no external storage, no intermediaries that see the traffic.
• The rooms server for group calls, meetings and video appointments (section 6.2) runs on another VPS, also contracted from Hostinger, in a data center in Boston (United States).

6.4. Email — Resend

Since 26 August 2026 T-kall sends email through Resend (resend.com), from no-responder@send.t-kall.com. Resend receives the address written to and the content of the message, which can only be one of three: the code to verify an email (you paste it into the app; it expires in 30 minutes), the link to reset the password (it expires in one hour) or a notice that someone tried to add your address to another account. None carries conversation content, and we will never ask you for a password by email. The main domain t-kall.com still neither sends nor receives email —it declares that no server is authorized to do so on its behalf—; sending goes out from that dedicated subdomain.

A correction that has to be stated as-is: this section announced Resend as "pending to be hired" until 8 September 2026, when it had been active since 26 August. The rule in section 6 —appearing here before being activated— was not met this time.

6.5. Google Play

If you install the app from Google Play, Google knows you have installed it, under its own terms and not ours. If you prefer to avoid that, you will be able to download the APK directly from this site as soon as the download is available.

6.6. Authorities

If we receive a valid legal request, we can only hand over what we have: account data and metadata. We cannot hand over the content of messages or calls: no call is recorded, and we do not have the keys to what is encrypted on your device. The exception is the one in section 6.2: while a group call has dropped down a level, the rooms server could see and hear it, and it can always read the name given to a meeting. And let it be clear that not being able to hand over the content does not prevent us from handing over the metadata, which in many cases is just as revealing.

7. Where they are stored

On two machines, both contracted from Hostinger (section 6.3):

• The main server, in Germany (a data center in Frankfurt). It holds the database, the file store where videos and the other attachments go (section 3.5) and the STUN and TURN servers for one-to-one calls (section 6.2).
• The rooms server, in the United States (a data center in Boston). Group calls, "Meet now" meetings and video appointments go through it. It does not store messages or files, but what it sees of each of those calls (section 6.2) —your account's identifier and your display name, your IP address, which room you join, when you join and leave, what you publish and whether it is muted, the technical data about your connection, and the meeting's name, if it has one— leaves the European Economic Area and is processed in the United States. One-to-one calls made with a chat's call and video call buttons do not go through it.

Push notifications cross Google's infrastructure, which is global —what travels there is the notification, not the message content, which is encrypted—.

8. How long they are kept

• Messages, 90 days on the server. After that period the server deletes them on its own, whether you have read them or not. And a precision we used to state the wrong way round: since 28 August 2026 the app does store on each device the messages it has already decrypted —it decrypts them the first time it shows them and from then on reads them from that store, as Signal or WhatsApp do—, wrapped with a local key that the app itself cannot export (a flaw in the web part does not carry it off, though it could use it from inside the app; whoever dumps the device's storage, yes: see Security, sections 2 and 6), and it prunes them on its own at startup when they have been kept on that device for more than 400 days or exceed 20,000 messages. Consequence: a message the server has already deleted may remain on the devices that displayed it until that pruning; it is not visible in the app, but it is in that store. If something matters to you, save it outside T-kall: today the app does not allow exporting the history.
• What remains on your own device. Signing out does not delete that store or the encryption keys: they stay on purpose, so that when you sign in again you recover your messages. Deleting the account does delete it —keys, decrypted messages, settings— on the device you delete it from and as soon as the server confirms the deletion; the detail and its limits are in Delete your account. On a shared computer, the difference matters.
• Videos and attached files, 30 days from when they are uploaded (section 3.5), deleted in the following daily sweep —between 30 and 31 days—. They are encrypted files that only whoever has the key can open, and the key goes inside the message. Whoever received it and opened it already has their copy; once the period is up, what is deleted is the file on the server.
• What you no longer see, much less. A message you delete stops being shown at once and its content is removed from the server within 7 days; the same with the appointments you cancel. What the device of whoever received it had already decrypted remains in their local store until the pruning above: deleting a message removes it from view and from the server, not from other people's devices. For a closed or expired session, the refresh token is deleted after 7 days; its record (public key, label and dates, section 3.10) is left with the closing date —or, if it simply expired, with the lapsed expiry date— and is kept until you delete the account. Same with a used, voided or expired password-recovery token: it is marked, not deleted, until you delete the account.
• Past appointments, 90 days, like messages: your calendar lets you consult them until then.
• When you delete the account, the removal is immediate and in a single operation. The videos and files you may have uploaded are separate files and disappear from the server within 31 days at the latest; since the keys to open them were inside messages that no longer exist, in the meantime they are not readable by anyone, not by us either. The reports you appear in (section 3.9) are kept without your account: today they have no automatic deletion period, and a legal obligation may require keeping them for at least a year. The records of the meetings and video rooms you may have created (section 3.11) also remain, and the rooms server's logs follow their own path; both are explained just below. More detail on what is deleted and what is not in Delete your account.
• The records of meetings by link and of video appointment rooms (section 3.11): not deleted today. They stop working when they expire, when they are revoked or when the appointment is canceled, but the record —who created it, the hash of the link and its dates— stays in the database, even if you delete the account, because it is not tied to it: it is left with the identifier of an account that no longer exists. What does go with the appointment is its room's identifier (after 90 days, or after 7 if it was canceled).
• The rooms server's logs. That machine keeps its own logs, which may include what it sees of each call (section 6.2): your account's identifier, which room you join, your IP address and the times. Today there is no retention period set by configuration for those logs, so we cannot give you one, and they are not deleted when you delete your account. When a period is set, it will be written here. There are no call recordings: no call is recorded.
• Backups: a daily copy of the database, encrypted before it touches the disk —a copy in the clear is never written, not even a temporary one— and automatically deleted after 14 days. It is one of the places where your data can survive an account deletion —along with what Delete your account lists: the reports, the key transparency log, the attached files for up to 30 days, some internal notes that expire in 24 hours at most and the main server's technical logs until they rotate; and with what is explained above: the records of meetings and video rooms and the rooms server's logs—, and that is why it is stated here.
• Technical logs of the main server: they are not archived; they rotate by size, as explained in section 3.10. Those of the rooms server, above.

9. How they are protected

• On-device encryption of message content and appointment details: the server does not have the keys.
• Mandatory TLS across all traffic; the app cannot connect without encryption.
• Passwords hashed with Argon2id.
• Profile data (date of birth, age, location) and contact-list notes, encrypted in the database.
• Sessions with rotating tokens: if one is reused, the whole family is revoked.
• A new device needs approval from an already-authorized one before receiving anything.
• Android backup is disabled so that neither the keys nor the already-decrypted messages leave the device.

The limits of all this are explained plainly in Security. Read it: it is as much a part of this policy as what is above.

10. Minors

T-kall is not directed at children under 13, and sign-up rejects dates of birth that give a lower age. If we detect an account belonging to someone under that age, it is deleted.

11. Your rights

Depending on where you live, you may have the right to access your data, rectify it, port it, delete it, restrict its processing or object to it.

• Access and rectification: most of your data you see and change in the app itself (profile, emails, phone numbers, devices, contact list).
• Deletion: see Delete your account, which includes the way to request it without installing the app.
• The rest: write to us at angel@engravitysigns.com.

You can also complain to the data protection authority that corresponds to your country of residence. If you write to us first, we tell you which it is and do not make you look for it.

12. Changes to this policy

If we change anything important —a new third party, a new piece of data, something the app starts to store—, the date at the top is updated. The app does not have a second policy: its privacy screen is a summary that points to this same page and that, if it disagrees in anything, gives way to this text. The internal rule we follow is the opposite of the usual one: first it is written here, then it is activated. When that fails —the local store of 28 August 2026 spent ten days undeclared here, and the rooms server in the United States was not declared as such until 23 September 2026 (section 6.2)— we correct it and we tell you, instead of pretending it did not happen.

13. Contact

angel@engravitysigns.com