Answers to the questions people actually arrive with. Where we do not have an answer, it says so — a FAQ in which everything is fine is as useless as no FAQ at all.
For the technical side see the API documentation; for what is and is not built, the technical work page.
A messenger: conversations, groups and channels, files, calls, bots. It runs on our own MVSy 1.0 protocol — the server, the transport and the storage are written here, not assembled from someone else's.
One account across every device: your conversations sync between phone, computer and browser.
Three things, each of which can be checked rather than merely read:
The core works: messaging, groups and channels, forums, files, stickers, stories, reactions, payments and gifts, secret chats, one-to-one calls.
What is missing: group calls (the methods are in the schema, but the media side needs an SFU and it is not up), a native macOS client, and public builds for Linux and iOS. Some published builds are debug builds. The full list is on the technical work page.
Not decided yet — and that is an honest answer, not an evasion.
How the project will earn, whether there will be advertising, who owns it, under whose law it answers requests from authorities and how it meets requirements such as the GDPR — those are decisions for the owners, not the developers. Until they are made and signed, writing them on a web page would be dishonest: a promise that changes tomorrow is worse than a plain "not decided".
What can already be said is in the manifesto. Moderation has its own page.
Not as a separate legal document yet — it will appear together with the answers to the question above. Technically, though, what the server sees and does not see is described without varnish: in the manifesto and in the "Security" section below.
Anyone with an account: by phone number if they are in your contacts, or by username. You do not need to know their number.
By default anyone who knows your number or username. Privacy settings narrow that: you can allow messages from contacts only, and block individuals.
One: the message reached the server and was delivered. Two: the recipient has read it.
Yes, in the privacy settings. Hiding yours also hides other people's from you — deliberately symmetric, otherwise the setting would be a one-sided advantage.
Yes — for yourself or for both sides at once, with no time limit. Deleted for both means it disappears from the other person's chat too.
Secret chat messages are deleted on both devices, and the server never held them in readable form anyway.
One-to-one, yes, end-to-end encrypted: the devices derive the key themselves and the server only forwards packets.
Group calls, not yet. The methods are in the schema and the handlers are written, but the media side needs a separate streaming server (an SFU) and it is not up. We are not going to promise a date.
With a link like ansible.su/name, if you have a username. It
opens in a browser and offers to continue in the app — nobody has to install
anything just to see who is writing to them.
In a group everyone writes; in a channel only admins do and everyone else reads. A channel can have a linked discussion group, which turns every post into a comment thread.
From the new-chat menu. A basic group becomes a supergroup automatically once it grows; a supergroup can be switched into forum mode, with separate topics instead of one stream.
An admin creates the link. It can be limited by time and by number of uses, it can require join requests — so every new member has to be approved — and it can be revoked at any moment.
A revoked link stops opening, and the page answers it exactly as it answers one that never existed. That is deliberate: otherwise the difference between the two answers would let someone enumerate other people's links.
A short name instead of a number: it is how people find you in search and
what makes the link ansible.su/name work. Set it in your profile
settings, if it is free.
No. By default the number is visible only to people who already have it in their contacts; privacy settings can narrow that further.
We do not take usernames away and do not resell them. If someone is deliberately impersonating you under one, that is grounds for a report — how those are handled is on the moderation page.
The connection to the server is always encrypted — not "can be enabled in
settings", but from the first packet. Client and server agree on a key over
Diffie — Hellman, then it is AES IGE, and every message's integrity is
checked against msg_key.
We tried reading our own traffic from the outside: the payload does not come out. What an observer does see is packet lengths and a key identifier. That is metadata, and we know about it.
Cloud chats: it can read them. That is how any system works where a conversation opens on a new device without moving keys: to hand you your history on a freshly installed client, the server has to be able to read it. It is a deliberate trade of privacy for convenience, and we prefer to name it out loud rather than hide it behind the word "encryption".
Secret chats: it cannot. There the devices derive the key and the server works as a blind relay: it passes bytes with no way to read them. That is not a promise not to look — it is the absence of the ability.
Turned on in settings: besides the code from the message, logging in asks for a password. An email can be attached to it, and then the password can be recovered with a code sent there.
If no email is attached and the password is forgotten, it cannot be recovered: the only reset available deletes the account with it.
Yes. A passkey is created on the device and login happens by PIN or
biometrics instead of a code from a message. Not every client supports it — where
it is unavailable the server answers PASSKEY_NOT_SUPPORTED.
Because then conversations would stop opening on a new device. A secret chat's key lives on two devices only, and the server would have nothing to restore the history from — it does not hold it in readable form.
That is not an excuse but a direct consequence: either syncing across devices, or a server that can read nothing. The choice is left to you, per chat.
The right answer is "don't — check". The client source is open, the protocol is described, the schema is published in full, and the errors the server returns are collected on the method pages out of the server's own source.
The claim "your data is safe" is worth exactly as much as the ability to verify it.
A conversation between two specific devices with end-to-end encryption. The devices derive the key themselves; the server takes no part in the exchange and cannot read the messages.
Hence the properties: such a chat does not appear on your other devices, its history cannot be restored after a reinstall, and forwarding out of it is limited.
Set per chat: after being read, a message disappears on both sides after the chosen delay. The countdown starts when the recipient opens it.
A fingerprint of the shared key. If yours and your correspondent's pictures match, you agreed on the same key and nobody stepped in between. Compare it over a different channel — by voice, or in person.
Settings hold a list of active sessions showing the device, the app and the address, and any session can be terminated. If the device is out of reach, terminate its session from any other one.
In the account settings. Conversations, groups and contacts stay: the account is tied to an internal identifier rather than to the number.
From the app, in the account settings.
The button on my.ansible.su currently answers with an error, and that is deliberate. Removal touches messages, dialogs, channel ownership and storage across two databases; a button wired to a half-built teardown would lose some data irreversibly and leave the rest. An honest error beats half a deletion.
Self-destruction on inactivity works separately: the period is set in settings, and once it passes the account is removed on its own.
From another device, terminate its session in the active list — that is enough to cut access off. If two-factor protection was not on, turn it on immediately: without a password, holding the number is enough to log in.
Secret chats on that device cannot be decrypted without it — but you cannot get them back either: the key was only there.
Through the manager bot inside the messenger: it issues the token the bot connects with. A bot needs no separate phone number.
Yes — that is what everything is published for. api_id and
api_hash are issued automatically at
my.ansible.su, with no application and no
explaining what your client is for.
Then: the API overview, the schema and the method list.
No: the server code is closed. The clients and the protocol are open — enough to verify what actually leaves your device, but not enough to run your own network.
Bugs and holes are the most useful thing — both in the clients, whose source is open, and in the protocol, which is documented. We have no bounty programme yet, and we are not going to promise one before it exists.
If you have already signed in on another device, the code arrives inside the messenger rather than by SMS — check the service chat there.
On a first sign-in the code is sent to the number. It is short-lived: an expired
one has to be requested again, and the server answers
PHONE_CODE_EXPIRED.
Check that they are not muted for that chat and that the system is not restricting the app in the background.
Honestly: delivery through third-party push services is not wired up yet, and on some Android builds notifications only arrive while the app is alive in the background. It is on the list of what is missing.
About the clients — in their repositories, listed on the apps page. About abuse and content reports — the moderation page.