6 Feb
2026
6 Feb
'26
11:59 a.m.
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='recipient(a)example.com' 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.