Privacy Policy
Last updated September 4, 2026
What S.M.A stores, what it cannot read, and who else is involved. Written to match how the software actually works.
In short
- Message text and voice notes are encrypted in your browser. We cannot read them.
- Attached images are not encrypted. Treat an image you send as something we can see.
- You do not need an account. Signing in is optional and adds nothing we require.
- No money passes through S.M.A, and we never see or store card or bank credentials.
- We do not sell your data, and we run no advertising.
- Anyone holding a room link can see message timing and superchat amounts, but not content.
Who we are
S.M.A ("Send Messages Anonymously") is an independent project run by the developer behind robi.work, reachable at robelmezemir@gmail.com. The service is operated from Ethiopia and runs on servers we manage ourselves rather than a managed cloud database. If you use S.M.A from another country, your data is processed on those servers.
What we cannot read
When someone sends you a message, their browser encrypts the text using your room's public key before anything is transmitted. The matching private key is generated in your browser and never leaves it. We store the encrypted result. We cannot decrypt it, and neither can anyone who obtains a copy of our database.
Voice notes are encrypted the same way. Replies you write back to a sender are encrypted too.
If you sync a backup of your identities to your account, it is encrypted in your browser first with a passphrase you choose and we never receive. The server refuses to store a backup that is not encrypted this way. If you forget that passphrase, nobody can recover the backup, including us.
What we can read
Some things are deliberately not encrypted, because the service could not work if they were:
- Attached images. Images are stored as plain data alongside a blurred placeholder. Text and voice notes are encrypted; images are not. Please send accordingly.
- Timing and change markers. When a message arrived, and whether it was later edited or replied to.
- Superchat details. Whether a message was paid, its tier and its amount. This is stored in readable form because your inbox has to sort and style by it without decrypting anything first.
- A revealed sender name. Only on a message where a signed-in sender explicitly chose "send as" before sending. It is off by default and decided per message.
- Room settings. The room title, your abuse limits, any payout details you publish, the cosmetics your room wears, and any webhook address you configure.
- Room identifiers. Every identity has a public room id, which appears in share links and is attached to messages so signatures can be checked.
What anyone with your room link can see
A room link is meant to be shared, so treat everything reachable from it as public. Someone holding your link can see when messages arrived, that a message was edited or replied to, the tier and amount of any superchat, the cosmetics your room is wearing, your payout details if superchats are on, and your name and photo if you turned on the verified owner display. The contents of messages stay encrypted throughout.
One consequence worth stating plainly: because timing is visible, someone with your link can tell how often your room receives messages, even though they cannot read any of them.
Optional Google sign-in
Signing in is optional and nothing in S.M.A requires it. A room belongs to whoever holds its private key, with or without an account. Everything you could do anonymously before accounts existed, you can still do anonymously.
When you sign in with Google we receive your name, profile photo and email address, and store an identifier for your account. We ask Google for nothing beyond that: no contacts, no files, no calendar, no access to anything else in your account.
Your email address is never shown to anyone else, and it is excluded from every public response by design. Your name and photo become visible only after two separate, deliberate choices: linking a room to your account, and then turning on the display. Linking on its own reveals nothing to anyone.
A sender revealing their name works the same way: it is a per-message tick box, off by default, available only while signed in. The name and photo attached to that message are a snapshot taken at the time, so renaming your Google account later does not rewrite what an old message said.
Payments
No money passes through S.M.A. You transfer funds in your own banking or wallet app and then paste the receipt. We send that receipt reference to links.et, a verification service operated by Odit, which checks with the bank whether the transfer happened, to which account, and for how much.
We never store the receipt link, the receipt number, or the name of the person who paid. What we keep is a one way hash, used only to stop the same receipt being spent twice, together with the amount and the tier. We do not receive, request or store card numbers, account passwords or banking credentials at any point, because the payment never happens here.
During verification our server briefly sees the details the bank returns, including the payer name. That is not written to our database and not attached to your message. If you want your name on a message, there is exactly one way to do it, and it is the per-message choice described above.
Other services involved
- Google, only if you choose to sign in.
- links.et (Odit), only while a receipt is being checked.
- vector.profanity.dev. When a room has the profanity filter switched on, your browser sends the text you typed to that service to be scored, before the message is encrypted. If that matters to you, do not type it into a room with the filter on. Voice notes and images are never sent there.
- Umami, a self hosted, cookieless analytics tool, which records page views along with general information such as referring page, browser, device type and country. It does not profile individuals across sites.
- Any webhook address you configure yourself. If you set one, it receives the encrypted message, its timestamp and the sender's room id. Where that goes is your choice and your responsibility.
Cookies and local storage
We set one cookie, and only while you are signed in, to keep you signed in. There are no advertising or cross site tracking cookies.
Your identities, including your private keys, are kept in your browser's local storage. That is not a cookie and is never sent to us. Clearing site data in your browser deletes them.
How we protect this, and where the limits are
What is genuinely protected:
- Message text and voice notes never exist in readable form on our servers.
- Changing a room's settings requires a cryptographic signature from that room's private key. Knowing a room link is not enough to change anything.
- Every message is signature checked, so one identity cannot post as another.
- Synced key backups are encrypted before upload with a passphrase we never see.
- Rate limits sit in front of sending, registration and payment checks.
Where the limits are, stated plainly rather than buried:
- Images are stored unencrypted.
- Message timing and superchat amounts are readable metadata, not secrets.
- The profanity filter is a courtesy, applied in the sender's browser to typed text only. A modified client can skip it, and it never sees voice notes or images.
- The "redact" tool in your inbox blacks out words in an image you export. It does not remove anything from our servers.
- No online service can promise it will never be breached, and we do not.
Keeping and deleting data
Messages are kept until they are deleted. There is currently no self service way to delete a room or its messages, which we would rather say than imply otherwise. If you want something removed, email us and say which room it concerns, and we will remove it.
What you can do yourself today:
- Unlink a Google account from a room, at any time, in that room's settings.
- Turn off the verified owner display without unlinking.
- Delete a synced key backup from the identities page.
- Pause a room so it stops accepting anything new.
- Stop sharing a link, which is often the most effective option.
Because private keys exist only in your browser, clearing your browser data or losing your device means losing access to those rooms. We cannot restore them, and no support request can change that. It is the trade the encryption makes, and it is why the backup and sync features exist.
Your rights and requests
You can ask what we hold about you, ask for it to be corrected, or ask for it to be deleted, by emailing robelmezemir@gmail.com. Two honest caveats about what we can actually do:
- We cannot hand you the contents of your messages, because we cannot read them. Only your browser can.
- For anonymous use there is usually nothing tying a request to a person, so please tell us which room you mean and prove you hold it, or we have no way to know the request is yours.
If something goes wrong at our end and affects data we hold, we will say so publicly here and contact signed-in users where we can. For anonymous users we have no contact route, which is the flip side of not collecting one.
Children
S.M.A is not intended for children under 13, and we do not knowingly collect their information. If you believe a child has used the service, email us and we will remove what we can.
Changes to this policy
This policy may change as the service does. The date at the top shows when it last changed. If a change materially reduces your privacy, we will make that clear rather than quietly editing the text.
Contact
Questions, corrections, or a request to remove something: robelmezemir@gmail.com