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

--===============1311888374915887205==
Content-Type: multipart/signed; boundary="nextPartKJGuJ51-R0STz8rzKWoacw";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPartKJGuJ51-R0STz8rzKWoacw
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Goffi <[email protected]>
To: XMPP Standards <[email protected]>
Date: Mon, 22 Jun 2026 13:38:20 +0200
Message-ID: <[email protected]>
In-Reply-To: 
 <CAJt9-x54ewe29dpn8wY93siZoGF-GKunOKLf=QupYW97GZ5xjQ@mail.gmail.com>
MIME-Version: 1.0

Hi Laura and others,

Le vendredi 6 f=C3=A9vrier 2026, 20:39:24 heure d=E2=80=99=C3=A9t=C3=A9 d=
=E2=80=99Europe centrale Matthew=20
Wild a =C3=A9crit :
> Hi Laura,
>=20
> On Fri, 6 Feb 2026, 19:09 Laura G., <[email protected]> wrote:
>=20
> > 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.
> >
>=20
> [SNIP]
>=20
> 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=
=20
default, and flag for important messages), probably with XEP-0224 as mentio=
ned=20
elsewhere in this thread.

A mechanism with backward compatible feedback would be interesting too: pho=
ne=20
may be silenced during night, but if a roster contact send message/call in =
the=20
middle in the night, it may be an emergency, and the device could send a=20
message like "this phone is currently on silent mode, is your message an=20
emergency? (y/n)".

With my council hat, we must avoid namespace bump on a such widely adopted=
=20
stable XEP. A separated XEP with its own namespace, even if the mecanism is=
=20
close, would IMO be more appropriate.

=20
> Either way, we should definitely standardize this feature.

Agree that the used case make total sense.

Regards,
Goffi
--nextPartKJGuJ51-R0STz8rzKWoacw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmo5HqwACgkQKqmcu6xu
KwzFYwgAscPvrT5WaPz7ZhsuvNlo5SZajR2LD29gGHNHz2LxO2yTKte3UTAQ+F1h
s80W2WeBFZG7LNfIyuBt39d/y2ulIIEPgYVGnNwGTTvvR6N7qKTNUEzP44LkU8VS
5PnkL8id8JNnsLcq3miVK2ORCRypwrOKWwZVFNYib8V7z3o+VweZBFCQHWAL/djw
n9dD6dg75iNb7fb8FmKd754gsXNygY1TpWWVmqID1O5d7V1kVBTFJnlpotT/VIUA
HuCR6KINs8s40LVk8BE8N3RLvl32WQs4POmk0PfZs43GqV4oi+jcUj+x/JQRrM+z
QUxTOpey0BlHsg35ryz5CegUtftF/Q==
=Fg36
-----END PGP SIGNATURE-----

--nextPartKJGuJ51-R0STz8rzKWoacw--




--===============1311888374915887205==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1311888374915887205==--