Should attention protection belong to the desktop?

I’ve been testing a small, local-only attention firewall on my Linux desktop. When I’m in an editor or reading, it pauses notifications, recommendation feeds, and chat badges, then restores them afterward. The useful part is putting the policy above individual apps: Linux already has a central notification path, while app-by-app focus modes are inconsistent. Processing the active window and rules locally also feels substantially less invasive than sending “productivity” context to a service.

But “productive” is not a technical fact. An editor may be work, or it may be procrastination; a browser may be research, or a distraction. An opaque classifier would turn a convenience into behavioral tracking, even if it never leaves the machine. I’m leaning toward an OS-level firewall only when the user writes the rules and can see exactly what is being paused. Would you trust that user-controlled, offline policy, or prefer app-level freedom?

Local processing improves the privacy story, but it is not the whole trust model. The policy itself can reveal a lot if exported, synced, or made visible to an administrator. I’d want the rules and history to stay local, with no “focus score” generated at all.

The OS has a defensible coordination point: GNOME and KDE both document system-wide Do Not Disturb controls, alongside application overrides. That supports centralized suppression, not automatic knowledge of what is productive. The distinction matters.

I’m wary of promising one layer can pause everything. The desktop notification service can catch notifications, but an app’s internal feed or badge may never pass through it. You need cooperation or stronger controls, and stronger controls usually create new breakage.

The dangerous word is “productive.” If the interface labels some windows as virtuous, people will eventually treat that label as a moral score. A rule like “mute these sources while I’m coding” feels empowering; “the system detected focus” feels disciplinary.

I’d implement this as a user-authored policy engine, not a classifier. Active workspace, explicit toggle, calendar-free. The less ambition it has about understanding me, the more likely I am to leave it enabled.

App-level freedom sounds good until every app invents a different version of quiet mode. From a product perspective, the desktop is the only place that can offer a consistent mental model. The escape hatch should be obvious, though, or users will blame the OS when something gets missed.

“Offline” needs a precise boundary. If the firewall reads window titles, editor files, or chat metadata, that data still deserves a threat model. I’d start with explicit application identities and manual modes, then add context only with an opt-in audit trail.

My rule is already called Do Not Disturb. The clever part is remembering to turn it off. I’m not opposed to automation, but I don’t need my window manager to become a life coach.

Recovery matters more than classification for me. If a muted message is retained and can be reviewed later, that is manageable. If the system silently drops something or makes exceptions unpredictably, support becomes a mystery hunt.

There’s a paternalism risk, but app-level control is not neutral either: feeds and badges are designed by someone else’s incentives. A transparent OS rule at least gives the user one place to reject those defaults. Centralization is only bad when it becomes unaccountable.

I’d use it if the first version were boring: hotkey, allowlist, notification suppression, reversible queue. No machine-learning productivity meter, no dashboard, no streaks. Every extra measurement feature makes the tool resemble the distraction it claims to remove.

For managed machines, this becomes a governance issue immediately. A user-controlled local policy is acceptable; an employer-defined “focus” policy is surveillance with nicer typography. The boundary should be technically enforceable, not just promised in documentation.