DEV Community

ThisТайна Team
ThisТайна Team

Posted on

How to Build Anonymous Messaging Without Deanonymizing Users

Anonymous messaging products often create engagement by promising identity reveals. That is also where trust breaks.

We are building ThisTayna, a social bot inside the MAX messenger, around a stricter rule: sender identity is neither revealed nor sold. This post explains the engineering decisions behind that promise.

1. Treat identity as a separate security domain

The message service should not need a sender's public identity to deliver a message. Use opaque identifiers and conversation-scoped aliases between domains.

A transport response should contain only what the client needs:

  • an opaque message ID;
  • an opaque conversation ID;
  • display-safe metadata;
  • server-owned permission state.

Never return an internal account binding "just in case."

2. Make hints non-identifying by construction

A safe hint is a fact derived from interaction history inside the product, not a shortcut to identity.

Examples of acceptable categories:

  • whether the two users interacted before;
  • whether a reply exists;
  • coarse, policy-reviewed engagement facts.

Unsafe categories include names, phone numbers, locations, contacts, device fingerprints, or any combination that narrows the sender to a real person.

If a paid feature can reveal a sender, privacy is not an invariant — it is a price tier.

3. Enforce blocks in every write path

A block check only in the UI is not protection. Enforce it server-side for:

  1. anonymous messages;
  2. replies;
  3. matching and likes;
  4. gifts and other indirect contact;
  5. notifications and queued retries.

This prevents alternate endpoints and workers from bypassing the user's boundary.

4. Separate adult and minor discovery pools

Age-based isolation belongs in the matching query and server-side policy, not in a client filter. The two pools must never overlap, including recommendations, retries, cached feeds, and experiments.

5. Audit money and moderation separately

Money mutations should be idempotent, append-only ledger operations. Moderation access should require a scoped case and append-only audit. Neither system should become an unofficial identity lookup.

What the user should feel

Good privacy architecture is invisible. The user should feel that it is easy to start a conversation, easy to leave, and impossible to buy someone else's identity.

That is the product direction behind ThisTayna / ThisТайна:

  • anonymous messages with replies;
  • new conversations inside MAX;
  • blocks and reports across interaction paths;
  • no paid identity reveal.

Try the bot in MAX: Open ThisТайна

Product site: thistaina.ru

Disclosure: ThisТайна is our project. The architecture principles above describe the product constraints we are implementing, not an independent review.``

Top comments (0)