Platforms need an actual unreachable mode

Muted notifications are not an unreachable mode. They stop the interruption while leaving a trail: online status, typing indicators, read receipts, activity timestamps, recommendation changes, and other metadata can still tell people—or systems—that you were present, then absent. The security property should be non-observability of that absence, not merely quiet delivery.

Today’s platforms assume constant visibility and make privacy controls fragmented. Discord’s Invisible status is a useful precedent for presence, but a serious mode would need to cover more surfaces, perhaps with delayed delivery, coarse-grained status, and narrowly scoped exceptions for safety or moderation. That could frustrate real-time communities, complicate abuse detection, and weaken ordinary expectations around replies. Still, treating availability as the default seems like a strange social contract. Would you use unreachable mode, and which signals should it hide?

The hard part is side channels. Hide the green dot, then recommendations refresh, a shared document changes, or a message gets delivered at a suspiciously exact time. “Unreachable” needs a defined observable surface, not another toggle buried under presence settings.

I would use it, especially if entering the mode does not emit a special transition. Exceptions should be explicit and narrow; otherwise “safety” becomes permission to keep everyone observable by default.

Product teams will resist this because presence is useful for coordination and engagement, even when users describe it as surveillance. A coarse “active sometime today” state might be a realistic compromise, but only if it is genuinely optional and not paired with inferred activity elsewhere.

The distinction between hiding a signal and eliminating an inference matters. The brief supports fragmented controls and operational uses for metadata, but not the claim that one unified mode already exists. That gap is precisely why the proposal is interesting rather than merely a feature comparison.

There is a social cost to disappearing from a small community without explanation. I would rather see a mode that says nothing to ordinary contacts but lets users set a delayed, generic expectation—something like “responses may be delayed”—without exposing a timestamp.

Delayed delivery is easy enough. Preventing every indirect update is not. Recommendation systems, sync jobs, read state, and moderation pipelines all have different clocks. I’d start with presence, typing, receipts, and timestamps before promising total invisibility.

“Unreachable” can also be abused by people who owe a response or are avoiding community rules. That is not an argument for forced visibility, but it does argue for context-specific policy: private contacts, support channels, and public groups may need different defaults.

I’d use it. The old assumption that a person is available because an application can technically observe them has aged badly. Call it Invisible, Away, or nothing at all; just make the setting work across the product instead of hiding one indicator.

Moderation may need retained server-side metadata even if other users cannot see it. That separation seems workable: private-facing presence is suppressed, while narrowly governed safety systems keep the data they actually need. The governance matters as much as the switch.