The latest articles on DEV Community by ulofi (@ulofi). https://dev.to/ulofi https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4073174%2Fb82c531d-db6a-4777-aa2c-23468d28be9f.jpg https://dev.to/ulofi en ulofi Tue, 11 Aug 2026 13:29:25 +0000 https://dev.to/ulofi/i-built-pseudonymous-discord-chat-and-the-hard-part-was-not-hiding-usernames-5bol https://dev.to/ulofi/i-built-pseudonymous-discord-chat-and-the-hard-part-was-not-hiding-usernames-5bol <p>Most “anonymous Discord” tools solve privacy by breaking the conversation.</p> <p>They ask members to use a slash command, open a submission form, or move into a dedicated anonymous room.</p> <p>That may hide an identity, but it also changes the social behavior that made the Discord community useful in the first place.</p> <p>I wanted to try a different constraint:</p> <blockquote> <p>A member should keep talking where the conversation already exists, while the public message appears under a stable pseudonym.</p> </blockquote> <p>That became <strong>Ulofi Alias</strong>.</p> <h2> The normal chat loop </h2> <p>In an immersive channel, a member types an ordinary Discord message.</p> <p>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.</p> <p>There is no second compose page and no command-driven workflow for normal text chat.</p> <p>Persistent aliases were important.</p> <p>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.</p> <h2> Why I call it pseudonymous </h2> <p>Ulofi Alias is not designed to promise untraceable anonymity.</p> <p>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.</p> <p>The important boundary is that this access is neither silent nor invisible.</p> <p>Privileged identity reveals and moderation actions are written to an audit trail that administrators can review.</p> <p>AI-assisted review is also kept separate from identity access. An AI result cannot automatically reveal a member or apply an account-level punishment.</p> <h2> The difficult engineering boundaries </h2> <p>The most interesting problems were failure states rather than UI:</p> <ul> <li>Discord may receive a webhook request even when the local process never receives a successful response.</li> <li>Retention jobs must remove old identity links without pretending that copies outside the application never existed.</li> <li>A second process using the same Discord token could create duplicated or contradictory delivery.</li> <li>One bot deployment spanning multiple Discord servers could leak settings across communities.</li> <li>Moderation failures should not silently publish uncertain content.</li> </ul> <p>The current design therefore uses explicit delivery states, bounded queues, retention windows, health checks, and a strict one-deployment-per-guild boundary.</p> <h2> Current stack </h2> <ul> <li>Node.js</li> <li>SQLite</li> <li>Discord webhooks and interactions</li> <li>Docker Compose</li> <li>Cloudflare Tunnel</li> <li>Optional AI-assisted moderation and support</li> </ul> <p>The project is MIT licensed and self-hosted:</p> <p><a href="https://github.com/ulofiai/ulofi-alias" rel="noopener noreferrer">https://github.com/ulofiai/ulofi-alias</a></p> <p>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.</p> showdev discord opensource privacy