Proposal: Add <no-notify/> hint to XEP-0334 (Message Processing Hints)
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@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.
Hi Laura, On Fri, 6 Feb 2026, 19:09 Laura G., <kx81tdl2t@mozmail.com> wrote:
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.
I'm the author of XEP-0334. My initial reaction, when I saw an email mentioning adding a new hint to the XEP at this stage, was negative. However your email makes good points, and I do agree this is a use-case worth solving. The XEP is marked as "Stable", which means any updates would need to be approved by the technical council. Therefore I'd like to hear from council members whether they would accept such a hint in this XEP, or whether a new XEP would be preferred. I'm not sure where I stand currently. Adding a new element at this stage would require a namespace bump (unacceptable for something so widely deployed) or to put the new hint into a new namespace (similar to what was done in XEP-0313 a couple of years ago). I'd have liked it in this XEP because it potentially feeds into server processing (a server may want to alter the metadata on push notifications, or perform traffic optimization and hold the message from an inactive client), and it would help reduce the number of places server developers need to look for such things. Either way, we should definitely standardize this feature. Regards, Matthew
Does this even need a namespace bump if it only adds a new element, but does not alter existing ones? I'm +1 for adding this and allowing the server to process it and, for example, not flush the csi queue sounds sensible. At least on apple there is something called focus mode that automatically silences every notification, but allows apps to break through focus mode. Maybe we should add another hint for urgent messages as well, that can be used by clients to break focus mode, aka: <urgent xmlns='urn:xmpp:hints'/> -tmolitor Am Freitag, 6. Februar 2026, 20:39:24 CET schrieb Matthew Wild:
Hi Laura,
On Fri, 6 Feb 2026, 19:09 Laura G., <kx81tdl2t@mozmail.com> wrote:
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.
I'm the author of XEP-0334.
My initial reaction, when I saw an email mentioning adding a new hint to the XEP at this stage, was negative. However your email makes good points, and I do agree this is a use-case worth solving.
The XEP is marked as "Stable", which means any updates would need to be approved by the technical council. Therefore I'd like to hear from council members whether they would accept such a hint in this XEP, or whether a new XEP would be preferred.
I'm not sure where I stand currently. Adding a new element at this stage would require a namespace bump (unacceptable for something so widely deployed) or to put the new hint into a new namespace (similar to what was done in XEP-0313 a couple of years ago).
I'd have liked it in this XEP because it potentially feeds into server processing (a server may want to alter the metadata on push notifications, or perform traffic optimization and hold the message from an inactive client), and it would help reduce the number of places server developers need to look for such things.
Either way, we should definitely standardize this feature.
Regards, Matthew
On Fri, Feb 6, 2026, at 21:21, Thilo Molitor wrote:
Maybe we should add another hint for urgent messages as well
On Fri, 6 Feb 2026 at 20:21, Thilo Molitor <thilo@eightysoft.de> wrote:
Does this even need a namespace bump if it only adds a new element, but does not alter existing ones?
Technically, yes. *Personally*, I don't feel strongly about this because none of my implementations would break. However there are several implementations of XMPP which actually depend somewhat on the schema of a namespace remaining stable, and would reject elements that don't conform to the schema. That schemas don't change is something we reinforced as a community years ago when we adopted the practice of namespace versioning.
At least on apple there is something called focus mode that automatically silences every notification, but allows apps to break through focus mode. Maybe we should add another hint for urgent messages as well, that can be used by clients to break focus mode, aka: <urgent xmlns='urn:xmpp:hints'/>
As Philipp pointed out, this is definitely XEP-0224 which is already implemented in a number of clients. Interestingly this new proposal is essentially the opposite of XEP-0224 (a missed opportunity to include it in that spec, too - as some kind of urgency=high/low). Regards, Matthew
On Fri, 6 Feb 2026 at 20:37, Matthew Wild <mwild1@gmail.com> wrote:
On Fri, 6 Feb 2026 at 20:21, Thilo Molitor <thilo@eightysoft.de> wrote:
Does this even need a namespace bump if it only adds a new element, but
does
not alter existing ones?
Technically, yes.
As one of the progenitors of namespace versioning, technically yes is the worst kind of yes. :-) I think you could add this in without a bump, and all preexisting ones will still work. You'd then need to signal support for the new one in a feature (disco or stream; in this case I assume disco). Dave.
Hi Laura and others, Le vendredi 6 février 2026, 20:39:24 heure d’été d’Europe centrale Matthew Wild a écrit :
Hi Laura,
On Fri, 6 Feb 2026, 19:09 Laura G., <kx81tdl2t@mozmail.com> wrote:
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.
[SNIP]
I'd have liked it in this XEP because it potentially feeds into server processing (a server may want to alter the metadata on push notifications, or perform traffic optimization and hold the message from an inactive client), and it would help reduce the number of places server developers need to look for such things.
With my user/dev hat, I think that the logic should be inverted (silent by default, and flag for important messages), probably with XEP-0224 as mentioned elsewhere in this thread. A mechanism with backward compatible feedback would be interesting too: phone may be silenced during night, but if a roster contact send message/call in the middle in the night, it may be an emergency, and the device could send a message like "this phone is currently on silent mode, is your message an emergency? (y/n)". With my council hat, we must avoid namespace bump on a such widely adopted stable XEP. A separated XEP with its own namespace, even if the mecanism is close, would IMO be more appropriate.
Either way, we should definitely standardize this feature.
Agree that the used case make total sense. Regards, Goffi
On Fri, 6 Feb 2026 at 19:00, Laura G. <kx81tdl2t@mozmail.com> wrote:
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.
I support your conclusion but not your argument... So, I think a no-notify hint is a fine and good thing, and generally useful. There's lots of use-cases for that, for sure. But, I think your mother should be using DnD, and relying on people with genuine emergencies to use XEP-0224 to "break through" that. Dave.
Dear participants, If you think this feature is worth creating, which many of you seem to, and have the ability, please consider going ahead further. In spite what my original message may have suggested, I have no clue about XMPP standardization in general. You were divided on how this should be done with some of you saying, add it without a namespace bump, others are between adding it with a namespace bump and putting the new hint into a new namespace. Unfortunately I can't meaningfully comment. Best regards, L.G.
participants (6)
-
Dave Cridland -
Goffi -
Laura G. -
Matthew Wild -
Philipp Hörist -
Thilo Molitor