Re: Proposed XMPP Extension: Explicit Mentions

On Tue, 17 Mar 2026 15:28:35 +0800
"Marvin W. via Standards" <[email protected]> wrote:

> Hi,
> 
> There was already discussions on that matter during Summit and I made
> the point that I believe we have two entirely separate issues here
> that IMO should also be treated entirely independent (potentially
> using two XEPs):
> (a) Markup to the body, that has the purpose to indicate that a part
> of the body is referring to a user or a group of users
> (b) Some indication that the message should have some sort of priority
> to a user or a group of users
> 
> Here's why I believe they should be independent:
> - A client may decide to send both at the same time, but it doesn't
> need to. (a) can also happen in conversations that the referred user
> is not a part of and thus part (b) certainly can't apply. It is thus
> only logical that even if the referred user is in the same room, one
> should be able to send a message that does not indicate (b).
> - (a) is indicating to a specific instance of body, implying that in
> scenarios of multiple bodies (xml:lang, xhtml-im), there need to be
> multiple of such (a) indications, but the indication of (b) does not
> need to appear multiple times, as it is independent from the actual
> body.
> - The (b) indication might have some implication on servers (e.g.
> might receive priority for CSI when regular type=groupchat messages
> don't), (a) is entirely to be processed by clients.
> - When end-to-end encryption is used, it may be desirable to keep (b)
> unencrypted (so servers can process it), whereas (a) should always be
> encrypted when end-to-end encryption is used, as it may leak
> information about the message's plain text.
> 
> I think this gives a good idea of why I believe those are two separate
> things. The XEP proposal puts them into a single thing, but does
> acknowledge some of the things I mention:
> - A mention can happen without referring to a specific part of the
> body, effectively turning it into a (b) only indication
> - A mention can happen with <noping/>, effectively turning (b) off
> when (a) is used
> 
> Now here are problems I see with the proposed specification, directly
> stemming from trying to merge the two:
> - A mention can happen with <noping/> and without begin/end,
> indicating that a user/group is mentioned, which feels largely
> useless.
> - When multiple languages are used, there may be multiple <mention/>
> elements. What if they have conflicting <noping/> indications?
> 
> On top, there's another major issue somewhat caused by merging the
> two: The user's home server usually does not have an understanding of
> group membership details, hats and so on, meaning it can't give
> messages priority (e.g. for CSI) based on that in the proposed
> protocol.
> 
> So my proposal is to do two separate things for mention (which could
> reference each other):
> - A markup-only indication. This is meant to be processed by clients
> exclusively. I personally would prefer this being based on XEP-0394
> spans, as those already have some business logic that is relevant here
> (spans must not cross each other, spans cannot cross block level
> markup) that would need to somehow be codified if it was done
> indpendent of XEP-0394.
> - For notifications in MUCs, to solve the issue that the home server
> does not understand details like affiliation/hats, have a new protocol
> that allows a sender to indicate which group they want to notify and
> then have the MUC translate this into XEP-0224 attention elements when
> reflecting the message to applicable recipients.
> - For priority notifications in direct chats (if messages aren't
> notified by default), just use XEP-0224 directly.
> 
> This way we have a single standard for the receiving server/client to
> know that a message is important and should notify (XEP-0224). We have
> a single standard for markup related matters (XEP-0394). And we have a
> new standard to indicate to the MUC server they should notify specific
> recipients.

Hello, thanks for the feedback! I wasn't around for the Summit, and it
sounds like not many notes were taken on the topic, so its certainly
interesting hearing about the ideas proposed there.

I agree that the current published draft does try to cover two separate
use-cases in one go, but most of the feedback I've gotten now suggests
that people don't actually want (a) without (b), so my current working
draft [1] has been revised to focus solely on the core use-case of
mentioning users with intent to notify. I would definitely like to hear
from others if such a split is actually desired, though.

On the other hand, the points about the server-side handling in regards
to notifications and encryption/CSI still seem relevant. 
* How would you handle notifications in encrypted group chats? I feel
  like relying on the MUC to notify the relevant users would leak the
  most important part of the mention to the MUC.
* Also, XEP-0224 only tells me that I've been notified, but not why.
  How would my server know to surpress group notifications if I'm only
  interested in individual mentions, for example?

[1] https://github.com/xsf/xeps/pull/1511
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]