Privacy Policy
Last updated: August 12, 2026
In short. AlphaMessage is an end-to-end encrypted messenger. Your messages, media and one-to-one/group calls are encrypted on your device; our servers only relay ciphertext and cannot decrypt it. There is one exception: voice rooms inside a channel, where audio and video are decrypted on the server that distributes the stream (the SFU) — section 5 explains why, and what it means for you. We show no ads, do not track you, and never sell your data.
1. Data controller & contact
This app and the service at “alphamessage.net” are operated by AlphaMessage. AlphaMessage is the data controller for the purposes of this policy. For any privacy matter you can reach us at [email protected] .
2. How end-to-end encryption works
Encryption happens entirely on the client (the app), using the Signal Protocol (X3DH key agreement + Double Ratchet). Your private keys are stored only on your device, in the operating system’s secure key store (Android Keystore), and never leave it. Only public key material is uploaded to the server. When you send a message, it is encrypted separately for each of the recipient’s devices; the server is only a relay that forwards these encrypted packets.
By design the server cannot decrypt message content: there is no decryption path, key escrow, or “backdoor”. This is a hard, structural invariant of the app.
What is end-to-end encrypted, stated plainly.
- End-to-end encrypted: one-to-one and group messages, text rooms inside a channel, photo/file/voice attachments, location and contact cards, your backups, and one-to-one/group voice and video calls.
- NOT end-to-end encrypted: the audio and video streams of voice rooms inside a channel. That traffic is still encrypted between your device and the server (WebRTC/DTLS-SRTP), so a third party watching the network cannot listen to your conversation; but the server that distributes the stream does decrypt it.
3. Data processed on our server
To run the service, our servers process only the following minimal data:
- Account: your username (your identity), display name and a verified email address. Sign-in is always by username; the address is used only to activate the account, reset a password and send security notices. We never ask for a phone number.
- Public key material: identity key, signed prekey and one-time prekeys (public parts only).
- Device metadata: device name, platform, last-seen time and last connecting IP address (for abuse prevention and session security).
- Transient encrypted envelopes: encrypted messages queued until delivery. They are deleted from the server as soon as they are delivered.
- Encrypted media blobs: photo/file/audio attachments are stored as client-encrypted raw data in object storage (S3-compatible); the server cannot decrypt them.
- Presence: online / last-seen state, subject to your privacy settings.
- Abuse reports: who reported whom under which category, plus an optional description the reporter wrote themselves. Contains NO message content — the server can never see your messages and therefore cannot attach one to a report. Reports are visible only to administrators; the reported person is not notified.
- Block list: which account has blocked which (kept solely for routing decisions; nothing is ever revealed to the blocked side).
- Channel metadata: channel and room names, categories, memberships, roles and permissions, invitations and bans. See section 4 below for details.
- Contact relationships: which account has accepted which, and pending message requests. This is required for the message-request feature to work at all — limiting what a stranger can reach you with until you accept them means the server has to know who has accepted whom. The server sees the relationship; never what you say to each other.
- Your per-contact nicknames: stored ENCRYPTED only. The key lives on your devices; the server cannot read, search or sort these names — it only carries them so they sync between your own devices.
The server does not see or store your message content, your location, or the decrypted form of your media. Those exist only on your device. For your contact list the picture is more detailed, and we state it plainly: the names you give your contacts are stored encrypted and cannot be read, but WHO you have a relationship with — whom you accepted, whose request is pending — is known to the server; the message-request feature cannot work without it.
4. Channels (servers) and voice rooms
Channels are team spaces made of text and voice rooms, governed by roles and permissions. Messages inside a channel are end-to-end encrypted exactly like one-to-one chats — the server cannot read room content.
To make a channel work, some data is necessarily stored in the clear on the server: the channel name, description and rules, room and category names, who is a member of which channel, their roles and permissions, invitations, bans and moderation decisions (mute, remove). These are authorization decisions the server has to enforce, so they cannot be encrypted.
In channel voice and video rooms the audio/video streams are distributed by an SFU server (LiveKit), and that stream is NOT end-to-end encrypted. The connection between your device and the server is encrypted (WebRTC/DTLS-SRTP), so somebody watching your network, your ISP or a shared Wi-Fi cannot listen to your conversation. But in order to forward the stream to the other participants, the server decrypts the frames. Unlike the rest of the app, here you are trusting the server.
Why: people join and leave a voice room constantly, and end-to-end encryption required the room key to be renewed on every join and leave. Each renewal briefly cut everybody’s stream and, on some computers, disabled the microphone entirely — the result was a voice room nobody could use. Rather than hide that, we removed the layer and state it plainly here.
What we do not do: we do not record, listen to, analyse, or transcribe voice rooms. The audio stream is not stored on the server; it is processed only to be forwarded to the participants connected at that moment. Even so, we want you to know that anyone with access to the server could technically access that stream. For a sensitive conversation, use a one-to-one or group call — those are end-to-end encrypted.
In every case connection metadata — who joined which room, when and for how long, plus microphone/camera/screen-share state — is visible to the service so it can operate. Screen sharing runs only while you start it.
When you join a channel, your username, display name and roles become visible to the other members of that channel. Channel administrators can see membership and moderation data; no administrator and no role can decrypt message content.
5. Data that stays on your device
The plaintext of your message history, your private keys and the contacts you pick are kept only on your device. Local history is stored in an SQLCipher-encrypted database whose key lives in your device’s secure store. Uninstalling the app or wiping device data removes this local data.
6. Permissions and why we ask
The app requests device permissions only for features you use, and mostly at the moment you actively trigger an action. Data accessed through these permissions is end-to-end encrypted before it leaves the device; it is never sent to the server in the clear.
| Permission | Purpose |
|---|---|
| Camera | Video calls. Video frames are encrypted on the device. |
| Microphone | Voice notes and voice/video calls. Audio is encrypted on the device. |
| Location | Only when you choose “share my location”. The coordinate travels inside the encrypted message; there is no continuous tracking. |
| Contacts | On-device pick to send a contact as a message. Your contact list is not uploaded to the server. |
| Notifications | New-message notifications (Android 13+ runtime permission). |
| Biometric | To unlock the app lock; stays on the device. A PIN is always the fallback. |
| Bluetooth | To route call audio to an already-paired headset. |
| Storage (write) | To save a received image to the gallery (Android 9 and below only). |
| Screen sharing | A foreground service that runs while you share your screen in a call. Frames are encrypted. |
7. Desktop app and updates
The Windows and Linux desktop builds are downloaded from this site and can update themselves after installation. When the app checks for updates it sends only the platform, CPU architecture and release channel; the request is unauthenticated and is not tied to your account. As with any web request, your IP address and client/user-agent are carried with each download or update check.
Update packages are distributed through an Ed25519-signed manifest, and the SHA-256 digest of the downloaded file is verified before installation; you can compare that digest yourself from the download section.
8. Third-party services
We do not share your data with any third party for marketing. The infrastructure providers we use to run the service are:
- Push notifications (Firebase Cloud Messaging, Google): to wake your device when the app is in the background we send “data-only” pushes carrying only ciphertext and routing metadata; Google cannot read your message text. The notification text is produced on your device after decryption.
- Object storage (S3-compatible): to store encrypted media blobs. The stored data is client-encrypted and cannot be decrypted by the provider.
- Voice/video room server (LiveKit SFU): distributes streams inside channel voice rooms. That stream is not end-to-end encrypted; the server decrypts the frames, forwards them to the participants, and stores nothing (see section 5). It runs on infrastructure we operate and is not handed to a third party.
- Hosting / CDN: the server and domain are served through a hosting provider and Cloudflare. These providers carry only encrypted traffic.
We use no advertising network, analytics, or tracking SDKs.
9. Retention
- Encrypted message envelopes: deleted on delivery; if undeliverable, they wait in the queue for a limited period.
- Account data (username, display name, email address, public keys, devices): kept until your account is deleted.
- Channel metadata: kept for as long as the channel exists. When you leave a channel your membership and role records are removed; ban records, by their nature, remain until channel management lifts them.
- Admin action logs: for security and integrity we keep an immutable, hash-chained audit log. It contains no message content; it records administrative actions only.
- Contact relationships: accepted relationships are kept until you remove the contact or delete your account. UNANSWERED message requests are deleted automatically after a period — there is no purpose in keeping a record of a request that is never going to be answered.
10. Your rights
Depending on where you live (e.g. KVKK in Türkiye, GDPR in the EU) you may have the right to access, correct, delete and object to the processing of your data. To exercise these rights contact [email protected]. Please note that because of end-to-end encryption we cannot access your message content; such data exists only on your device.
11. Account & data deletion
You can request deletion of your account and associated server data at any time. For the process and what gets deleted see the Data Deletion page .
12. Children
AlphaMessage is not directed at children. It is not knowingly made available to anyone under the age of 18.
13. Security
We use TLS in transit (with certificate pinning support) and end-to-end encryption for content (the audio/video stream of channel voice rooms is excluded — see section 5). A new account becomes active only after the link mailed to its address is opened (a deployment may additionally require admin approval), optional two-factor authentication (TOTP) is supported, and the admin panel sits behind an IP-restricted, separate session-security layer.
14. Changes to this policy
We may update this policy from time to time. For material changes we will update the “last updated” date on this page and, where appropriate, notify you in the app.
15. Contact
Questions: [email protected]