Should urgency belong to the user, not the app?

I've started routing social-app notifications into a local quiet queue: nothing pops up immediately, and the queue releases batches at times I choose. It has made compulsive checking less automatic, though I can imagine becoming slower to answer and seeming absent when someone expects a quick reply.

Linux already has notification urgency concepts, but the sending application generally chooses the level. That feels backwards for social prompts, where a genuine direct message is not equivalent to “people are talking about you.” I’d rather have machine-readable metadata that my local policy can accept, downgrade, or ignore—not a platform declaring what deserves interruption. Still, batching is not a universal cure; immediacy is part of social connection. Would you trust local filtering, sender-declared urgency, or no urgency metadata at all?

Local policy, definitely. Sender-declared urgency is useful as an input, but treating it as authoritative just turns marketing copy into a systems primitive. I’d whitelist actual message channels and make everything else ordinary queue traffic.

The evidence for batching seems encouraging, but it supports reduced interruption, not a perfect classification scheme. The social cost is harder to measure: delayed replies can change expectations even when the user feels better. I’d treat urgency as a preference signal, not a promise.

The awkward part is social interpretation. If I answer in three scheduled windows, some friends will read that as disinterest rather than a notification policy. The interface may need to make availability legible without making everyone publish their attention schedule.

My threat model says “urgent” should never cross a trust boundary without local control. A sender can claim urgency; the receiver decides whether that claim has any authority. Otherwise an engagement system gets to negotiate directly with my nervous system.

I’d use sender metadata, but only as a hint. Direct messages, calls, and account-security events have different expectations from recommendation nudges. The product challenge is that platforms benefit from flattening those categories, while users benefit from separating them.

This is a good fit for local-first design: preserve the event locally, sync when needed, and let the client decide when attention is spent. I’d want the queue to support overrides, expiry, and a visible audit trail so filtering does not become silent disappearance.

No urgency metadata may be the cleanest answer. We survived email without every subject line being a machine-readable emergency. Give me messages, let me check them, and stop pretending every badge is a protocol.

I’m wary of making the sender irrelevant. If someone marks a message urgent and I routinely delay it, the relationship may suffer even if my local rules are philosophically tidy. User control matters, but so does choosing a responsiveness level other people can reasonably understand.