Most “anonymous Discord” tools solve privacy by breaking the conversation.
They ask members to use a slash command, open a submission form, or move into a dedicated anonymous room.
That may hide an identity, but it also changes the social behavior that made the Discord community useful in the first place.
I wanted to try a different constraint:
A member should keep talking where the conversation already exists, while the public message appears under a stable pseudonym.
That became Ulofi Alias.
The normal chat loop
In an immersive channel, a member types an ordinary Discord message.
Before the original account identity becomes public, Ulofi Alias publishes the content back into the same conversation under that member’s persistent alias and avatar.
There is no second compose page and no command-driven workflow for normal text chat.
Persistent aliases were important.
Randomizing the identity on every message would hide more information, but it would also destroy conversational continuity. A stable pseudonym allows members to recognize the same participant without learning which Discord account is behind it.
Why I call it pseudonymous
Ulofi Alias is not designed to promise untraceable anonymity.
The deployment retains a protected mapping between a pseudonym and its Discord account. When a concrete safety case requires investigation, an authorized administrator can reveal the sender.
The important boundary is that this access is neither silent nor invisible.
Privileged identity reveals and moderation actions are written to an audit trail that administrators can review.
AI-assisted review is also kept separate from identity access. An AI result cannot automatically reveal a member or apply an account-level punishment.
The difficult engineering boundaries
The most interesting problems were failure states rather than UI:
- Discord may receive a webhook request even when the local process never receives a successful response.
- Retention jobs must remove old identity links without pretending that copies outside the application never existed.
- A second process using the same Discord token could create duplicated or contradictory delivery.
- One bot deployment spanning multiple Discord servers could leak settings across communities.
- Moderation failures should not silently publish uncertain content.
The current design therefore uses explicit delivery states, bounded queues, retention windows, health checks, and a strict one-deployment-per-guild boundary.
Current stack
- Node.js
- SQLite
- Discord webhooks and interactions
- Docker Compose
- Cloudflare Tunnel
- Optional AI-assisted moderation and support
The project is MIT licensed and self-hosted:
https://github.com/ulofiai/ulofi-alias
I would particularly appreciate feedback on the threat model, retention defaults, and whether the moderator accountability boundary is understandable to someone installing the project for the first time.
