Re: Proposed XMPP Extension: Explicit Mentions
"Marvin W. via Standards" <[email protected]> Wed, 18 Mar 2026 02:57:05 +0800
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
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... _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]