The two kinds of anonymous

There are two settings with "anonymous" in the name. They are different features, for different people, and they never meet in the same decision. Being clear about which one you want saves an afternoon.

Space allowAnonymous — letting strangers join in

This governs whether a logged-out reader can take part. They supply an authorName with their post and that is all the identity there is.

PATCH /orgs/{orgId}/spaces/{spaceId}/forum/settings
  { "allowAnonymous": true }

Also on PATCH …/blog/settings, read back with the matching GET. It is stored in the space's settings under community.allowAnonymous.

It covers:

• a reader commenting or replying

• a reader reacting (any reaction except 👍/👎, which are votes and need an account)

• comments and reactions on blog posts and changelog releases

• anonymous voting on a roadmap

It defaults to off, and turning it on needs a captcha connected (PUT /orgs/{orgId}/captcha) or an explicit "anonymousCaptcha": "off" in the same request. Send { "allowAnonymous": null } to clear the choice entirely and go back to following your organization's default.

Refusal with no session is a 401 auth.unauthenticated, and the message names this setting and the door that takes it — there is a way in and it is signing in. Refusal for a reader who is signed in and still may not take part is a 403 rbac.forbidden.

Three things about it that surprise people

It does not decide who may start a piece. That is whoCanPost (the shape's whoCreates) on its own. allowAnonymous governs joining a piece somebody else started — replying, commenting, reacting, voting.

It used to promote whoCreates to anyone, which meant every forum and roadmap on the platform accepted unauthenticated topics out of the box, and the whoCreates setting people had chosen was read by nothing. It no longer does. If you want strangers to be able to open a topic, set whoCanPost to anyone.

whoCanPost: "anyone" is enough on its own. A space that lets anyone start a piece lets anyone join one, whether or not allowAnonymous is set: saying strangers may open a topic here says something stronger than "strangers may comment". So you do not have to set both, and allowAnonymous: false does not close a space you have explicitly opened — if you want replies closed, that is whoCanPost: "members" or the per-post comment switch.

This was a bug for a while, and the shape of it is worth knowing if you read the old behaviour anywhere: a forum set to whoCanPost: "anyone" accepted a stranger's new topic and answered 401 to that same stranger's reply, because the reply door required allowAnonymous as well.

whoCanPost: "members" beats it. A space set to members-only does not take anonymous replies, even with allowAnonymous: true. This was also a bug for a while: a forum that said "members only" accepted unauthenticated replies from anybody who sent an authorName, because the default-on switch was being ORed rather than ANDed. It is now the narrow reading — members-only means members only.

Org community.allow_anonymous_posting — letting members hide their name

This is for a signed-in member who wants to post without their name on it.

PUT /orgs/{orgId}/settings/community.allow_anonymous_posting
  { "value": true }

With it on, a member may pass "anonymous": true when creating a topic or a reply. Their post is attributed to a persistent shadow identity — a real user record with a handle like anonymous-a1b2c3d4e5. The same member always gets the same shadow identity, so a conversation holds together across their posts, and the map from the real account to the shadow is server-side only.

Refusal is a 403 — "Anonymous posting is not available to you here."

Its three companions

All four are advanced settings in the community category.

It is not an escape hatch

Rate limits, trust level and every other abuse governor key to the real account, not the shadow. A low-trust member who switches on anonymous mode is still a low-trust member. Eligibility itself reads the real account's trust level.

The flag is also ignored on a whisper — a whisper is already restricted, and stacking the two would make a message nobody can attribute in a thread nobody can see.

How the two combine: they don't

The decision branches on whether a session resolved, and only one of the two settings is ever read:

Not an AND. Not an override. Two disjoint paths.

The consequence worth knowing: a signed-in reader is exempt from the space switch. A space that has switched anonymous comments off still accepts a signed-in reader's comment, because that reader is not anonymous — they have an account, they are just not staff. A reader who is nobody is still allowed where the space allows it; that is what anonymous means.

Which one do you want?

• "Let anyone ask a question without signing up." → whoCanPost: "anyone", which covers starting a topic and replying to one. Or space allowAnonymous alone if you want replies from strangers but topics from members only.

• "Let my team discuss salaries without their names on it." → org community.allow_anonymous_posting.

• "Let people vote on the roadmap without an account." → space allowAnonymous on the roadmap space.

• "Stop drive-by spam." → space allowAnonymous: false. The org setting has no effect on strangers.