Set who a conversation is private to

Makes a thread a private room, moves it between rooms, or opens it back up. Needs content: write, and audience: read as well whenever the body names a segment, and is a write.

audience_tag_ids replaces whatever the thread was private to. Each id has to be a live tag of this newsletter with is_room set; anything else is refused 422 naming the ids that are not rooms, and nothing is written. null or [] clears the audience.

Why two permissions. The thread is content and the segments are audience, and this call is both acts at once: it writes the thread's row and it reads a segment to name it. The contract prices "which segments does this newsletter keep" at audience: read wherever a credential can ask (GET /newsletters/{newsletter}/tags, GET /tags/{tag}), so a credential that cannot list the rooms has no legitimate way to hold a room's id, and a request that named one anyway would be told whether its guess was a real segment. Refusing on the family instead answers the guess with 403 and names what is missing. read rather than write, because this moves nobody between segments and creates no tag: it reads one and writes a thread. audience: read is not in the OAuth scopes below for the reason ?expand=subscriber on GET /newsletters/{newsletter}/insights is not in that operation's either: the scopes say what the operation always spends, an authorization request built from a wider list would ask a person to grant access most callers of this never use, and clearing an audience spends nothing beyond content: write. A credential that sends segments without it is refused 403 insufficient_scope with param set to audience_tag_ids, and nothing is written.

Widening asks first. Clearing the audience, or adding a segment that was not already there, lets more people read every reply that was written while the room was smaller. That is refused 422 with param set to confirm_widening the first time, and applies when you retry with confirm_widening: true. Narrowing (scoping an open thread, or dropping one segment of several) applies straight away and needs nothing. Commune's own chat puts a confirmation dialog on the same rule and from the same code, so the two cannot disagree about which direction a change moves.

Scoping a public thread pulls it off the global feed in the same write, because a private conversation on a public feed is the one combination this feature exists to make impossible. The response carries the thread with visibility already subscribers. The opposite order is refused instead: POST /threads/{thread}/publish answers 422 for a thread that has an audience, because there the caller asked for the unsafe direction outright.

Replies have no audience of their own. A reply is exactly as readable as the conversation it is in, so an id that names one answers 422 rather than writing a column no reader consults.

Publishes no event. There is no topic for a conversation changing hands between rooms, and thread.created already reports whether a thread was born private; adding one would change the delivery service's own topic list, which is a deployment rather than a code change.