I'd like to propose adding a new processing hint to XEP-0334 to support 
silent/whisper messages - messages that are delivered normally but don't 
trigger notifications on the recipient's device.

Use Case:
My mother and I communicate via XMPP throughout the day. She frequently 
participates in screen recordings and video calls (about 1 hour daily) where 
notification sounds and popups would be disruptive. However, she doesn't want 
to use DND mode because she needs to remain reachable for genuine emergencies.
The solution we need: the ability to send non-urgent messages silently so she 
can read them when she next checks her client, without interrupting her work.

User Demand:
This feature is heavily requested across messaging platforms. A quick search 
shows thousands of users asking "how to send silent messages" or "send without 
notification" for Facebook Messenger, WhatsApp, Telegram, and other platforms. 
Telegram already implements this as "send without sound." The demand is clear 
and widespread.

Proposed Addition to XEP-0334:
A <no-notify/> processing hint with the following semantics:
<message to='[email protected]' type='chat'>
        <body>Please look at the following when you have time: ...</body>
        <no-notify xmlns='urn:xmpp:hints'/>
</message>

Behavior:
- The receiving client SHOULD NOT trigger audio/visual notifications
- The message SHOULD still be delivered and stored normally
- The message SHOULD appear in the chat history
- The message MAY still update unread counts (implementation-dependent)
- Clients MAY provide UI indication that a message was sent silently

Benefits:
- Allows nuanced communication without forcing binary DND states
- Respects recipient's focus/workflow while maintaining async communication
- Reduces notification fatigue
- Provides sender control over message urgency
- Simple to implement - clients already have notification suppression logic

Backwards Compatibility:
Clients that don't recognize <no-notify/> will simply deliver the message 
normally, which is acceptable fallback behavior.
This would be a natural extension to the existing hint types in XEP-0334 
(no-store, no-copy, store, no-permanent-store) and addresses a genuine gap in 
XMPP's messaging capabilities.
Thoughts? Is this something the community would support adding to XEP-0334, or 
would it be better suited as a separate XEP?

Best regards,
L.G.
I'm using an email mask just because I don't want recruiters to get a view of 
my personal life, please consider the proposal objectively.
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to