17 Mar
2026
17 Mar
'26
2:57 p.m.
So if I understand your concern correct, we can solve it by adding an
explicit recommendations that clients should make sure that users can
recognize which message caused the notification and if it's not
possible, should also not trigger a notification? Which is then of
course up to the client what that means.
I also would want to point out that the mere existence of begin/end
attributes don't guarantee that the user can see them. begin and end
might point outside the bounds of the body, or they point to a part of
the body that is not rendered (e.g. zero-width spaces), thus any
styling of that part would be invisible. Or because your client
displays the body of another language than the one that caused the
notification. Or because a later edit removed the mentioning part
again. You get the gist.
The easiest and safest way to indicate to the user that a message
caused a notification is some sort of indicator that cannot be
manipulated by the sender - which means, something that's not the body.
Marvin
On Tue, 2026-03-17 at 13:02 -0500, Stephen Paul Weber wrote:
recipient that
(a) is present for (b) to work, no matter if it's
the
same element conveying it or a different one.
I suppose that's true. The main thing is the problematic
<message>
<body>Some troll statement</body>
<mention occupantid="blah" />
<mention occupantid="blah2" />
<mention occupantid="blah3" />
</message>
Where these users get notified but don't know why. This was an early
complaint when I implemented
https://xmpp.org/extensions/xep-0224.html which
I solved by highlighting the message as "this one is to everyone" in
the UI.
But when it's not to everyone, and indeed if 99% of the time there
will be
your name in the message, it makes more sense to highlight a name
then to
add some other UI. At which point you have a dependency on whatever
does (a)
anyway and they might as well be together if you need them both...