Re: Proposal: Add <no-notify/> hint to XEP-0334 (Message Processing Hints)

Thilo Molitor <[email protected]> Fri, 06 Feb 2026 21:21:33 +0100

Newsgroups	gmane.network.jabber.standards-jig
Message-ID	<8028091.uXWc14spt3@laptop>

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., <[email protected]> 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

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 488 B)