Blocking takes effect client-side instantly, not after review

What it is

Blocking (mute/block) differs from reporting in purpose: reporting seeks action against the disruptor (backend review required), blocking seeks immediate self-protection (stop seeing/hearing this person now). Blocking must take effect instantly and client-side—the instant the block is pressed, that player's text, voice, and interactions vanish locally, with no review pipeline in between. Making blocking a backend-processed feature is a category error: protection delayed is protection denied for the delay's duration.

Why it happens

Instant blocking's technical nature is client-side filtering, not server-side ban: the blocked player's messages still arrive at the client but are not displayed (filtering at the presentation layer). This architecture makes blocking's activation speed equal to one local operation (zero network latency), and makes blocking a purely personal choice (it doesn't affect that player's interactions with anyone else—no server adjudication of "should they be blocked"). Instantness matters directly in harassment scenarios: under sustained abuse, every extra minute endured is real harm, and instant blocking truncates the harm's duration at the victim's button press. Blocking's completeness decides protection quality: text, voice, DMs, party invites, friend requests—all channels covered; one leaked channel is a hole (text blocked but voice still shouting). Blocking's persistence and release rights sit with the victim: persistent across matches by default (auto-blocked on next encounter), reversible only by the victim's action (survives avatar and name changes—account-level blocking, not display-level).

Where it stops holding

Client-side blocking's boundary is that it changes "what I see," not "what happens": the blocked player's behaviour stays visible to everyone else—blocking is self-protection, not punishment, and expectation management matters (after blocking, the victim should not expect the offender to be punished; that is reporting's job). Blocking's interaction with competitive information has a special case: blocking a teammate's voice removes team communication (see the silence-misreading card); blocking is a personal protection right, but in team contexts it may carry team costs, so competitive modes can show a standing reminder ("teammate voice blocked") rather than forbid blocking. Blocking's capacity and sync: account-level block lists need cloud sync (surviving device changes), with capacity limits (hundreds) sufficient for most players but with clear over-limit behaviour. Accidental blocks (mis-blocking a teammate) need instant reversibility (manage the block list immediately, no appeal flow).

Applying it

• Make blocking client-instant, covering text, voice, DMs, and invites; bind at account level and sync across devices.
• Offer one-press blocking in matches (a block button beside report in the roster), with an instantly manageable block list including immediate unblocking.
• Verification: test blocking's latency (the window where a blocked player's messages still appear must be zero) and per-channel coverage (verify each channel individually); track block-feature usage and repeat-block rates (repeatedly blocking the same person signals account-binding or sync holes).

Related

• Same group: W9.05.1 Reporting must be simple enough to use mid-match · W9.05.3 Report outcomes need feedback the reporter can perceive · W9.05.4 Punishment must scale with severity and repeat offences
• Nearby: O1.03 Harassment and safety design · W9.05 Reporting, blocking, and punishment · W9.03 Voice and text communication
• Search terms: block and mute · client side filtering · player blocking · harassment protection