6 Feb
2026
6 Feb
'26
10: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.
6 Feb
6 Feb
11:39 a.m.
Hi Laura,
On Fri, 6 Feb 2026, 19:09 Laura G., <kx81tdl2t(a)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
12:21 p.m.
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(a)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 
12:26 p.m.
On Fri, Feb 6, 2026, at 21:21, Thilo Molitor wrote:
Maybe we should add another hint for urgent messages
as well
https://xmpp.org/extensions/xep-0224.html
12:37 p.m.
On Fri, 6 Feb 2026 at 20:21, Thilo Molitor <thilo(a)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
1:22 p.m.
On Fri, 6 Feb 2026 at 20:37, Matthew Wild <mwild1(a)gmail.com> wrote:
On Fri, 6 Feb 2026 at 20:21, Thilo Molitor
<thilo(a)eightysoft.de> wrote:
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.
Does this even need a namespace bump if it only adds a new element, but
does
not alter existing ones?
Technically, yes. 
22 Jun
22 Jun
4:38 a.m.
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(a)mozmail.com> wrote:
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.
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. Either way, we should definitely standardize this
feature.
Agree that the used case make total sense.
Regards,
Goffi
6 Feb
6 Feb
1:26 p.m.
On Fri, 6 Feb 2026 at 19:00, Laura G. <kx81tdl2t(a)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.
22 Jun
22 Jun
2:25 a.m.
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.
6
days inactive
142
days old
8 comments
6 participants
participants (6)
-
Dave Cridland -
Goffi -
Laura G. -
Matthew Wild -
Philipp Hörist -
Thilo Molitor