Hi, Le mardi 10 mars 2026, 16:04:40 heure normale d’Europe centrale Stephen Paul Weber a écrit :

I guess the idea is to not update or base on references and instead make a whole new element for this? Given our move away from fastening and other generic base XEPs this is maybe a fine idea.

I think that I've missed the summit discussion on mention because I was sick and left early. Probably some discussions also happened on xsf@ room, but it's hard for me to follow there. So it seems that we are ditching XEP-0372: References, can somebody explain to me the rationale for that? XEP-0372 was already specifying a kind of mention, but not as powerful as the spec proposed here, however I want to understand why we would want to have 2 specs for the same thing. I would love also to have the thoughts of Kevin here, as he is the author of XEP-0372. Thanks, Goffi

Hi, Thats great to here that the intention is the same. I dont think the text conveys that though.

hint that the specified range of the content is being addressed to the specified occupant.

If i send "@admins please ban this user" and then mark "please ban this user" with begin/end, i would say i follow the XEP because i marked the content which is addressed to the admins. Regards Philipp On Tue, Mar 10, 2026, at 19:06, Snit Guckfung via Standards wrote:

On Tue, 10 Mar 2026 18:47:05 +0100 Philipp Hörist <philipp@hoerist.com> wrote:

...

Hi,

Im a bit confused about begin/end

The XEP says

...

If a mention element of type urn:xmpp:mentions:0 or its subtypes contains both begin and end attributes, the receiving entity MAY use this as a hint that the specified range of the content is being addressed to the specified occupant.

I dont think this is necessary, as its usual that the content that follows the mention is addressed to the mentioned user.

What was missing was that we can special format the nickname or the @admin @all etc in the GUI when we receive a message, without hardcoding some regex or scanning for nicknames.

The 'begin' and 'end' attributes specify the range of the specially-formatted text. It is meant to be used to, for example, pillify text like "@room" or "@romeo". Note that there can be multiple mentions, and the content addressed to them isn't always what follows: "@romeo, have you seen @juliet?" has two mentions, with ranges specified for "@romeo" and "@juliet". _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

This was something I'd meant to include in the original proposal, and have added to my current working draft. Special characters like '@' MAY be sent in the original message, perhaps to show unsupporting clients that this was a mention. But implementations SHOULD include such characters within the range covered by the mention, so that both "user" and "@user" mentions can be formatted the same way. I haven't special-cased any characters in particular, as maybe rooms will use '#', or a different client might format it as "user," to look similar to existing clients. I hope that makes sense. On 11 March 2026 1:07:50 am UTC, Maxime Buquet <pep@bouah.net> wrote:

On 2026/03/10, Snit Guckfung via Standards wrote:

...

On Tue, 10 Mar 2026 18:47:05 +0100 Philipp Hörist <philipp@hoerist.com> wrote:

...

Hi,

Im a bit confused about begin/end

The XEP says

...

If a mention element of type urn:xmpp:mentions:0 or its subtypes contains both begin and end attributes, the receiving entity MAY use this as a hint that the specified range of the content is being addressed to the specified occupant.

I dont think this is necessary, as its usual that the content that follows the mention is addressed to the mentioned user.

What was missing was that we can special format the nickname or the @admin @all etc in the GUI when we receive a message, without hardcoding some regex or scanning for nicknames.

The 'begin' and 'end' attributes specify the range of the specially-formatted text. It is meant to be used to, for example, pillify text like "@room" or "@romeo". Note that there can be multiple mentions, and the content addressed to them isn't always what follows: "@romeo, have you seen @juliet?" has two mentions, with ranges specified for "@romeo" and "@juliet".

Just to be extra sure, the spec doesn't mention any special-cased "@" character. This is just an artifact used in clients UI and should not be observed on the wire, right?

I'm confused by the examples here.

Parameters begin and end here should not be concerned with any special character not part of what is used to refer to the mentioned occupant(s).

Some clients may display "@channel" as a keyword or sth but we agree that's not what is being transmitted. It would look more like a mention tag addressed to the channel. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

On Wed, 11 Mar 2026 02:43:47 +0100 Maxime Buquet <pep@bouah.net> wrote:

Please don't. Really don't clutter XMPP with yet another special-cased character. We have XML for that already.

The "@", or any other character for that matter, can be used client-side and stripped when being sent. It's easy enough to come with UX to handle this.

Non-supporting clients won't support "@" any more than they support this specification. It actually hurts these clients more as they may not match on the special char and thus miss the mention entirely (for example matching on the nick as a lone word, not part of another word or the like).

Fair, fair. I figured it'd be more flexible to allow whatever extra characters, so long as they're within the mention's specified range. The main thing that I really want to avoid is a message sending "@user" but only specifying "user" as the mention, which could cause a user interface to display something akin to "@(@user)", where the "(@...)" bit is just UI stylisation. It doesn't technically matter whether the solution to that problem is including the '@' in the mention or stripping it from the message entirely, as long as its done consistently, so if the former method is likely to cause other problems instead, I'm more than happy to do the latter. :D

On 2026/03/11, Philipp Hörist wrote:

On Wed, Mar 11, 2026, at 02:43, Maxime Buquet wrote:

...

Please don't. Really don't clutter XMPP with yet another special-cased character. We have XML for that already.

The "@", or any other character for that matter, can be used client-side and stripped when being sent. It's easy enough to come with UX to handle this.

Non-supporting clients won't support "@" any more than they support this specification. It actually hurts these clients more as they may not match on the special char and thus miss the mention entirely (for example matching on the nick as a lone word, not part of another word or the like).

Im not sure i understand your goal. A client needs to provide a plaintext representation of a mention. I bet many clients do different things. Gajim includes "nickname, ", but its configurable by the user, it could also be "nickname:" and another client could do "@nickname".

Clients will provide graphical (plaintext or not) representation of mentions and that's alright. I'm arguing against that representation becoming part of the wire protocol. Nothing fancy.

I agree that the XEP does not need to make a recommendation about how plaintext looks, thats what the range is for. But i dont understand your statement that a client can strip an @ for its plaintext representation. Can Gajim also strip ", " ? Or another client ":" after the nickname? And why should it? Is there a correct representation for a plaintext mention? Why is @ more wrong than a colon? Why would you care if you implement mention?

If a client were to use "@" to autocomplete nicknames, just like gajim does, the client could also not include it in the wire protocol. Just like gajim does. As for anything that qualifies as a natural language (punctuation?) like you showed, well I surely hope that also doesn't get specified as the wire format. It would be weird if it was mandated to include a comma (",") when communicating in languages that don't use them, or use something else (Japanese for example, and full-width chars). It's a good thing that gajim made this configurable. We can take natural languages into account to help shape the document but we probably don't want to reference every single use-case/language in it. We also don't want to ignore anything non-ascii/non-western like it's been done in other XEPs, by mandating a specific character.

On 2026/03/13, snit via Standards wrote:

Again, no characters are treated as special here. Everything that applies to '@' applies to anything else, as well. IF you decide to send extra characters with your mentions, you include them in the range. It doesn't matter what those characters are. The receiver shouldn't need to care either; that's kind of the entire point.

I guess that's where we disagree. As a receiving implementation, why would you have to display an "implementation detail" from another client? You can't actually remove that implementation detail if you feel it should not be displayed in your client, as you do not understand it.

On Fri, 13 Mar 2026 14:16:12 +0100 Philipp Hörist <philipp@hoerist.com> wrote:

Thats what the range is for, to remove the implementation detail or do something with it.

Its an implementation detail that Gajim mentions a user "Nickname, " and another client "@Nickname:".

Now Gajim will send you a range start/end and tell you which characters are a plaintext representation of the mention.

You can then choose to remove the text and replace it with something else, or format it in some color, or do nothing with it.

Usually you would replace the text with some clickable GUI elements which show the nickname (which you take from your database, not from the text) in some format you decide is fitting for your client.

This aligns with my thoughts, yeah.

But i read your draft again, and i think the confusion might really come from the place that in your draft you used the range to mark text to which other people should be notified?

...

the receiving entity MAY use this as a hint that the specified range of the content is being addressed to the specified occupant.

Thats from your draft. Thats not what i would need as a feature from this spec. For me start/end should mark the range of the nickname, so i can replace it with GUI and do not need to use regex and care about false positives.

As discussed, this was just poor wording on my part. It was always meant to be the range of the user's name itself, which the existing examples should reflect. My working draft makes this more clear I hope:

Any mention MAY contain both the 'begin' and 'end' attributes, which specify the range of text in the body corresponding to the mention (i.e. the mentioned user's name).

On 2026/03/13, Snit Guckfung via Standards wrote:

Only the last one expects any level of understanding of the mention's text, but it is unclear to me why one would do that. Nonetheless, the recommendation at least gives confidence that you need only parse within the range, and never without.

It also occurs to me that our ideas are not mutually opposed. I can just do like: 1. "Entities SHOULD strip processing characters before sending" 2. "If sent anyways, they SHOULD be included in the range"

Sorry this makes little sense to me. One should not break a SHOULD. There should be a compelling reason to do so. I'm trying to find a compelling reason for breaking this one (1.) but I'm out of ideas. I do agree it gets blurry when talking about natural languages (including commas and all), but I don't understand what's hard with "@" or any other character used especially for this purpose.

On Fri, 13 Mar 2026 13:49:30 +0100 Maxime Buquet <pep@bouah.net> wrote:

...

I guess that's where we disagree. As a receiving implementation, why would you have to display an "implementation detail" from another client? You can't actually remove that implementation detail if you feel it should not be displayed in your client, as you do not understand it.

As a receiving entity, I see three potential options upon receiving an arbitrary mention, regardless of its format: 1. Stylise mention with text as-is 2. Acquire user's name and replace the text with that 3. Attempt to parse the mention's text for post-processing

This looks reasonable (for supporting entities). With the possibility of eating any natural language feature that isn't part of the nickname included in the range for option 2. I guess that's alright if that's what the sending user meant. Sending clients should probably be careful in handling that, maybe a note there could help.

On Sat, 14 Mar 2026 13:14:34 +0100 Philipp Hörist <philipp@hoerist.com> wrote:

Hi,

This whole discussion about stripping characters is not relevant for interop. You can make a recommendation, but its clear that nobody will feel bound to it, as it is irrelevant for interop and this feature to work.

If the XEP makes a recommendation, it should have a sound rational. What would that be? Why is it important to you what different communities, clients or bridged networks choose as plaintext representation of a mention?

Well, my rationale for including the characters in the range is for consistency across clients. If I receive a mention, I want to be generally sure that all text related to the mention, including the user's name and any extra processing characters, are contained solely within the mention's range, and that I don't have to touch any other part of the body to work with the mention. It won't break anything at a protocol-level if ignored, sure, but making the receiver's life easier still sounds like interop to me. As for the recommendation to strip characters before sending, that's mainly for interop with clients which still rely on implicit mentions. Sending "@user" might interfere with a client which only expects "user", and thus not notify a user that otherwise should've been. Should I make these reasons more clear in the draft?

Hi, On Tue, 2026-03-17 at 12:31 +0000, Stephen Paul Weber wrote:

...

(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

In the direct mention case, I don't think we really wrnt to allow one without the other.

Who is "we"? I certainly want to do it and do so regularly in Slack.  Mentioning people that are not in the room is kind of normal in physical conversations, why shouldn't it work in digital rooms? And just like in a physical room if you mention a person that is not in the room, they won't get notified - except if someone explicitly forwards the message to them. Of course you don't need to support that in your client if you don't like it. It remains a useful feature for others though.

I am also against noping though. It is not up to the sender if I want to be notified.

How would the recipient client know if a person is mentioned because they're being referred to or if the mention happened to indicate to the recipient that this is relevant for them. Not every message that mentions a person is also relevant to them. For example when X writes to Y "The council consists of 5 individuals: [A,B,C,D] and [singpolyma]" (with the latter being a mention), that's not necessarily meant to be notifying you, that's really just mentioning you. Of course you don't need to comply with that in your client either if you don't like it. It remains a useful feature for others though.

And if we use occupant id the idea of cross-room mentions becomes not possible. I'm not sure what the use case for those is but if we wand that I suppose we should use URI.

The ProtoXEP also allows for mentioning people by JID. I'm very much open to also mention people by URI (allowing for mentioning of non-XMPP people, via e.g. tel:, mailto: and acct: URI). In all cases, the idea of a mention is that recipients can identify the person being mentioned. If you mention someone by occupant-id, that should only happen within the scope of the room, as otherwise the occupant-id might be unresolvable (if the message recipient isn't in the room that assigned the occupant-id). Marvin

On Tue, 2026-03-17 at 10:01 -0500, Stephen Paul Weber wrote:

You mention people without any indication in the body that you mentioned them in Slack?? How?

The other way round. I mention "@B" in a message to user A or a channel where B is not a member, and it will be a mention in markup without a notification of A. And with things like "@here" you are also notifying a lot of users without mentioning them in the traditional sense. (The @here also doesn't become clickable whereas a @B actually will be a link to the profile of B).

Right. Which is what the existing refrences XEP would already allow (with the small, previously-discussed edit to not restrict the URI on mentions to URIs of bare JIDs)

Except for all the other issues it has, like unclear interplay with XEP-0393/0394, lack of support for multi language messages, ... It also has the major downside of specifying a bunch of other things than mentions that are unfinished (have literal TODOs) and don't have any implementation experience and likely never will - meaning it can't be reasonably advanced to stable. The only way I see XEP-0372 advance is if everything except mention is removed - in which case we have to ask the question why it would still be called "references", if the only thing it does is "mentions". Marvin

On Tue, 2026-03-17 at 10:28 -0500, Stephen Paul Weber wrote:

Oh sure, that direction might be useful though seems out of scope for a mentions XEP and more like a styling thing. I means more that for mentions it should require that if there is a mention of a person it should have a body item with begin/end.

Oh, so I see we're approaching some agreement here: We see a usecase for a specification of how to mention a person in the terms of styling/markup (a way to link a person or group). That's the (a) I was talking about. Now that we agree on that, why should there be a specification for (a) and one that does (a)+(b)? Wouldn't it be both easier and cleaner if the specification that does (b) would not also have (a), if we have an independent specification for (a) anyway? Marvin

On Tue, 2026-03-17 at 11:36 -0500, Stephen Paul Weber wrote:

Well partly because I don't think we want b without a to be a thing you can do. But also because it's so cheap to have begin/end attributes. If the app also supports other ways of doing a it can consider them redundant.

Can you explain why you don't want to be able to do (b) without (a)? I fail to see a good reason why this shouldn't be possible. If you really don't want to support it in a client, you can easily require on the recipient that (a) is present for (b) to work, no matter if it's the same element conveying it or a different one. As I already mentioned, there is advantages of splitting the two in distinct elements (unrelated to them being in the same or different XEPs), because (b) can be useful for server-side processing (which will likely not look into the body or analyze begin/end attributes even if present), when (a) is directly tied to the body and thus should be encrypted when possible and has to take care of the multi-language shenanigans. The ProtoXEP's <noping/> actually has the issue that for multi language there are multiple occasions of the <mention>, so the <noping/> can be present on some languages and missing on others. Marvin

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...

On Tue, 17 Mar 2026 15:28:35 +0800 "Marvin W. via Standards" <standards@xmpp.org> 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

On Tue, Mar 17, 2026, at 08:28, Marvin W. via Standards wrote:

(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

- 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.

I cant really get on board on the idea that a server translates every message where i am pinged into a XEP-0224 attention. This XEP is very old and probably has decades of implementations. I plan to use it for what it was intended in my opinion and thats to style a message specially e.g. check how MS Teams does it, see screenshot in attachment. Now the idea that every time someone pings me, my client marks the message as !!! IMPORTANT !!! sounds wrong. Regards Philipp

Hi, On Tue, Mar 17, 2026 at 3:31 PM Marvin W. via Standards <standards@xmpp.org> wrote:

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

I just want to briefly mention that I agree with Marvin. Those should be two different things. The markup part should be made *compatible with* 0394. I don’t think it should it be in 0394 and I think people should be able to implement one without the other. But those two things should be aware of each other and for example prevent overlapping sections and stuff. And then <attention/> but not actually <attention/> should be it's own element that can but doesn’t have to be generated by the MUC service. cheers Daniel

On 24 Mar 2026, at 17:07, Daniel Gultsch <daniel@gultsch.de> wrote:

Hi,

On Tue, Mar 17, 2026 at 3:31 PM Marvin W. via Standards <standards@xmpp.org> wrote:

...

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

I just want to briefly mention that I agree with Marvin. Those should be two different things. The markup part should be made *compatible with* 0394. I don’t think it should it be in 0394 and I think people should be able to implement one without the other. But those two things should be aware of each other and for example prevent overlapping sections and stuff.

I think it makes sense to update References(372) to say that when used with 394 it shouldn’t have partially overlapping spans and references. /K

Le mardi 24 mars 2026, 15:55:41 heure d’été d’Europe centrale Goffi a écrit :

Hi,

Le mardi 10 mars 2026, 15:28:26 heure normale d’Europe centrale Daniel Gultsch a écrit :

...

The XMPP Extensions Editor has received a proposal for a new XEP. URL: https://xmpp.org/extensions/inbox/explicit-mentions.html

What bother me a bit here, is that everything happens for people already in the MUC.

One of the major thing I want to be able to do with mentions, is mentioning people outside of a room. So I can be in many rooms without being actively present there and receiving all messages, I may want just to check them when I'm mentioned.

Another thing, is that this specification is chat only. So what do we do for pubsub mentions? Do we need another spec?

Mentions from XEP-0372 handle both cases. So what is the plan? Replace XEP-0372 by this? Use both in parallel? Extend with other XEPs?

As a side note, I agree with Marvin that is should be at least 2 specs (one for Markup [XEP-0394] and one for message importance). And with the general complexity of the current version, maybe more.

I like the general idea of being able to mention by affiliation of hats.

Best, Goffi

Hi, I didn't get any feedback, but with my council hat, this is important to know the whole picture before casting my vote. To be clear: I'm sympathetic to specification, and grateful to the work done in this contribution. However, some parts are redundant with XEP-0372. I've thought a bit about it, and I actually think that both use cases are necessary: - explicit mentions are more efficient for people already in the MUC, as there is not extra message, and they can specify who is mentioned. - I think that it's necessary to be able to mention people not in the room, or sort of "registered" to a room, but not present at the time of the mention. In this case, the MUC service could use XEP-0372 to mention them. Not being physically present in a room and receiving mention can have huge benefits when following large room. - XEP-0372 can also be used with Pubsub, which is, with my client developer hat, a very important feature to me. So there is room for both. However, there should not be 2 different ways of marking the location of the mention, it should use XEP-0372 (maybe an updated version of it) and made compatible with XEP-0394 (without making XEP-0394 mandatory). All of that is not blocking to go to experimental and have an official number, but if time flies and people start to implement, it's important to have those concerns addressed as fast as possible. I would really appreciate to have some feedback here before our meeting this afternoon if possible (BTW, time has changed in many countries, so local meeting time may be different for anybody willing to attend). Thanks in advance. Best, Goffi

To be clear: I'm sympathetic to specification, and grateful to the work done in this contribution. However, some parts are redundant with XEP-0372.

Yes, there is a redundancy at the moment. The original idea here was that this would be submitted _after_ a PR that removes mentions from XEP-0372. The XEP always seemed to me like it was meant to be a generic baseline for others to build off of, similarly to XEP-0317, which is why it strikes me as incredibly odd that the base specification has its own built-in method of mentioning an individual (and exclusively via JID, at that!). As such, even if mentions were to continue using References, I'd still want it to be specified in its own document. It also isn't clear to me how mentions as specified there are supposed to be extended. The 'type' attribute isn't a URI, and it never says whether it should be or not. What 'type' do extensions to mentions use? The same one, or something different? If the former, it still needs a way to specify what type of mention it is on top of what type of reference; if the latter, then now we have two or more entirely separate namespaces for the same functionality, rendering it impossible to determine whether an unknown mention type is even actually a mention. The former could look like: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' kind='urn:xmpp:reference:mention:0#hats' uri='https://example.com/schema/hats/cool-people' begin='5' end='10 /> which feels incredibly verbose and clunky. Because room mentions don't even have a target URI, they're just impossible to specify with References as-is. You could waste bandwidth and throw in a dummy value, like the room JID. Or, because mentions need a URI in 'kind' anyways, you could completely ignore the intended purpose of the 'uri' and use it as 'kind', instead: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#room' begin='5' end='10 /> But then you'd need a new, non-standard way to specify targets: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#hats' target='https://example.com/schema/hats/cool-people' begin='5' end='10 /> And at that point you're ignoring the intended use of one field and then recreating its functionality as a non-standard optional field elsewhere, so why even bother with References anymore? Say you go the other route and just use a dummy value in the 'uri' attribute. Not all mention targets have obvious URI formats, and it makes little sense to me that you have to arbitrarily format them as URIs anyways. Consider the absurd case of roles and affiliations: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' kind='urn:xmpp:reference:mention:0#associations' uri='urn:xmpp:reference:mention:0#participants' begin='5' end='10 /> Or, again, you could just ignore half the specification: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#associations' target='participants' begin='5' end='10 /> But, again, none of these options are compatible with mentions as already specified in XEP-0372, anyways, as all of these example assume mentions were updated to be at all extensible.

I've thought a bit about it, and I actually think that both use cases are necessary:

- explicit mentions are more efficient for people already in the MUC, as there is not extra message, and they can specify who is mentioned.

- I think that it's necessary to be able to mention people not in the room, or sort of "registered" to a room, but not present at the time of the mention. In this case, the MUC service could use XEP-0372 to mention them. Not being physically present in a room and receiving mention can have huge benefits when following large room.

I still don't really understand what you're getting at, here. Does anything in the current draft suggest you can't do this? Nothing stops you from mentioning anyone with a known Occupant ID or JID, whether or not they're currently present.

- XEP-0372 can also be used with Pubsub, which is, with my client developer hat, a very important feature to me.

As I said before, I basically have no clue how PubSub works at the moment, so I didn't even consider it initially. I'm not sure I understand the use-case, but I would be more than happy for it to be added, preferably by someone who actually knows what they need from such a feature. Otherwise, I can look into it later down the line.

So there is room for both. However, there should not be 2 different ways of marking the location of the mention, it should use XEP-0372 (maybe an updated version of it) and made compatible with XEP-0394 (without making XEP-0394 mandatory).

I've seen several people advocate for splitting markup and notification format, which seems perfectly reasonable. One thing I don't get, though, is why a pure markup format wouldn't just use the XEP that is specifically designed for markup formats. I figured maybe it'd be an issue that XHTML-IM and Markup would both have their own ways of marking up mentions, but that's seemingly never been a problem for literally everything else they do redundantly, so I assume there's something else that I'm missing here. And regardless, if the markup and notification aspects are split, then even clients which don't support Markup would still get notified.

All of that is not blocking to go to experimental and have an official number, but if time flies and people start to implement, it's important to have those concerns addressed as fast as possible.

I would really appreciate to have some feedback here before our meeting this afternoon if possible (BTW, time has changed in many countries, so local meeting time may be different for anybody willing to attend).

Sorry about taking so long to respond. Hopefully this response makes it in time :)

Hi, On Tue, 2026-03-31 at 17:30 +0200, Goffi wrote:

I'm not sure to understand your point here. Markup would need an (probably short) extension to explain that something is a mention.

Comment from co-author and implementer of message markup: XEP-0394 specifies a <span/> element [1] that can be used to markup inline text (non-block elements) and would probably be a good fit for this. The design is intentionally extensible, with specific markups being sub- elements of such spans (e.g. <emphasis/> or <code/>). Equally a <mention> element (or a new kind of <reference/> element) could be defined with an extensible way to indicate what it mentions. I imagine an elegant solution could roughly be: For mentioning occupants: <markup xmlns="urn:xmpp:markup:0"> <span start="9" end="15"> <mention xmlns="urn:xmpp:tmp:mention"> <occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" /> </mention> </span> </markup> For mentioning hats: <markup xmlns="urn:xmpp:markup:0"> <span start="9" end="15"> <mention xmlns="urn:xmpp:tmp:mention"> <hat xmlns="urn:xmpp:hats:0" uri="http://schemas.example.com/hats#students" /> </mention> </span> </markup> For mentioning roles or affiliations: <markup xmlns="urn:xmpp:markup:0"> <span start="9" end="15"> <mention xmlns="urn:xmpp:tmp:mention"> <item xmlns="http://jabber.org/protocol/muc#user" role="moderator" /> </mention> </span> </markup> For XEP-0030 discoverable items like rooms, users, servers, spaces or anything on pubsub nodes: <markup xmlns="urn:xmpp:markup:0"> <span start="9" end="15"> <mention xmlns="urn:xmpp:tmp:mention"> <item xmlns="http://jabber.org/protocol/disco#items" jid="spaces.commons.example" node="space" /> </mention> </span> </markup> As you can see, extending this further is rather trivially. Everything that already has a syntax of how to refer to it can easily be referred to, it doesn't need a URI representation. Marvin [1] https://xmpp.org/extensions/xep-0394.html#usecases-inline

Le mardi 31 mars 2026, 21:21:59 heure d’été d’Europe centrale Snit Guckfung via Standards a écrit :

Ah, I see now. Yes, this would be useful functionality to have. I'm generally either always in a room or never in it, so I hadn't considered the case where someone only pops into rooms selectively.

Could this be achieved with the MUC service sending something like XEP-224 in a message to you, or does that also only work if you're currently in the room? Otherwise, what exactly would this look like?

A message sent by the room directly to the used, probably and "headline". With a link to the room and message ID. I don't know about XEP-0224, I've not implemented it so far and Philipp Hörist explicitly asked to not use it in a previous message in this thread. XEP-0372 could do the job, but it was discussed yesterday at the council meeting that maybe your specification and XEP-0372 could be merged somehow?

What exactly would the logistics of this be? Are the references / mentions attached to the blog post itself? How would the mentioned user get notified? Is it just on the things they're subscribed to?

The difficulty with Pubsub is that depending on the feature we can have any kind of payload. We could just says that mention are only for blogging (XEP-0277/XEP-0472) and work with some kind of Atom extension (don't know if there is already something we can use with Atom). But I also want to be able to mention people with other features, for instance with Pubsub File Sharing (XEP-0498) if somebody appears on a photo or is part of a team working on a PDF. I use Form Discovery and Publishing (XEP-0346) to make a tickets handling system (that you can see here: https://www.goffi.org/ forge/goffi/libervia-backend/tickets), I want to be able to mention somebody in the ticket description. It can be useful for Calendar Events (XEP-0471) too, etc. With XEP-0372 a message is sent independently of Pubsub with the Pubsub item linked in the `uri` parameter. That works. Practical note: In my AP <=> XMPP gateway, I've had troubles to map ActivityPub mention to XMPP XEP-0372 mentions because the former has the mentions inside the payload of the message, while with XEP-0372 it's separated (and thus is not received at the same time). I don't think that we can really do otherwise with pubsub if we want something generic, as we can't modify the payload. Even if we used Pubsub Attachments (XEP-0470), this would be separated. Having XEP-0372 like separated message + maybe something in the payload in some cases (like blogging) could help. So to sum-up: we need something that can send a <message type="headline"> to a JID with a link to the pubsub item. This is exactly what XEP-0372 is doing. I'll be happy to update my code if this feature is merged in explicit mention.

My point is that I don't get why we'd make a markup format which is compatible with, and honestly just reinvents, XEP-0394, rather than just using XEP-0394 itself.

The only explanation I could come up with is that some people don't want to implement XEP-0394, instead prefering some other markup format, such as XHTML-IM. However, the way mentions are currently marked up is an exact replica of XEP-0394, so I can't see an XHTML-IM user's objections to XEP-0394 not also applying to mentions.

Markup is meant to be purely aesthetic, which is why all of the actual functionality would be going in a separate proposal, no? If so, then there's no real loss in not supporting the markup format, and if that's the case, then why shouldn't we just use XEP-0394?

Since there's no real loss in not supporting XEP-0394 mention markup, there'd be no loss if an XHTML-IM enthusiast decided they wanted to specify a format which relies on XHTML-IM, instead. Both formats could coexist, because, again, all actual functionality is in a completely separate document that'd be supported regardless.

One of the first responses to the proposal on this list has an example of what XHTML-IM markup for mentions could look like, and Marvin's recent response shows possible XEP-0394 markup.

I can't seem to word this in a way I find satisfactory, so hopefully this explanation makes sense :)

Ah I understand it better. So you're wondering why people would have mention "marking" without implementing XEP-0394? I actually agree with you, I think that this was suggested (not by me initially) as you say because people don't want to implement the whole marking thing (with bold, italic, etc) just to get mention. However, people can do partial implementation if they want. So yes, we may have something simply depending on XEP-0394, because that's exactly what it is: marking the location of the mention in the payload. Now that Explicit Mention made it to experimental, I hope that will get good feedback from first implementations. It would be great if somebody could make a XEP-0394 update/new protoXEP for mentions (Marvin?). Best, Goffi

A message sent by the room directly to the used, probably and "headline". With a link to the room and message ID. I don't know about XEP-0224, I've not implemented it so far and Philipp Hörist explicitly asked to not use it in a previous message in this thread. XEP-0372 could do the job, but it was discussed yesterday at the council meeting that maybe your specification and XEP-0372 could be merged somehow?

I'm on the fence regarding XEP-0224 as well. It was suggested by someone else in the thread for notifications, but then it was also argued against. Its also been brought up to be used for room mentions, which is an entirely different use-case. Sounds like no one knows what XEP-0224 is supposed to be in the context of MUCs, which is worrying... Most of what I've said about XEP-0372 still stands, but I agree we need to figure out how this XEP relates to XEP-0372, and what to do about the redundancy. I'm also not sure how it would work if we're separating markup and notifications, considering References seems to be inexorably tied to both use-cases. Parts of it replicate what I'd rather use XEP-0394 for, while others seem more of a fit for the notification functionality.

The difficulty with Pubsub is that depending on the feature we can have any kind of payload.

We could just says that mention are only for blogging (XEP-0277/XEP-0472) and work with some kind of Atom extension (don't know if there is already something we can use with Atom).

But I also want to be able to mention people with other features, for instance with Pubsub File Sharing (XEP-0498) if somebody appears on a photo or is part of a team working on a PDF. I use Form Discovery and Publishing (XEP-0346) to make a tickets handling system (that you can see here: https://www.goffi.org/ forge/goffi/libervia-backend/tickets), I want to be able to mention somebody in the ticket description. It can be useful for Calendar Events (XEP-0471) too, etc.

With XEP-0372 a message is sent independently of Pubsub with the Pubsub item linked in the `uri` parameter. That works.

Practical note: In my AP <=> XMPP gateway, I've had troubles to map ActivityPub mention to XMPP XEP-0372 mentions because the former has the mentions inside the payload of the message, while with XEP-0372 it's separated (and thus is not received at the same time). I don't think that we can really do otherwise with pubsub if we want something generic, as we can't modify the payload. Even if we used Pubsub Attachments (XEP-0470), this would be separated. Having XEP-0372 like separated message + maybe something in the payload in some cases (like blogging) could help.

So to sum-up: we need something that can send a <message type="headline"> to a JID with a link to the pubsub item. This is exactly what XEP-0372 is doing. I'll be happy to update my code if this feature is merged in explicit mention.

I see, this is all good information. I'll have to read through some of the relevant XEPs to better understand the factors at play here. It should definitely be possible to allow separating a mention from the thing containing the mention. This kind of contradicts what I said earlier, but if we're duplicating all of the functionality of XEP-0372 anyways, I do wonder if there's a way to make them play nice. Perhaps the mention could point to a reference containing the URI the mention occured in, though that's a lot of indirection...

Now that Explicit Mention made it to experimental, I hope that will get good feedback from first implementations. It would be great if somebody could make a XEP-0394 update/new protoXEP for mentions (Marvin?).

Considering XEP-0513(:D) already focuses predominantly on the client-side aspect, and already replicates much of XEP-0394, I think it'd make sense to have this one be the markup XEP, and submit a second one for the notifications.

XEP-0224 is pretty clear that the purpose is to send a message which cases more of an attention-grabbing alert than the same message would otherwise have received, and that how to get the user's attention is up to the implementation. So if a client gets a message with this tag it should alert the user in some way. In a MUC usually a message does not notify the user at all, so any notification at all would be more than usual. That is why it is appropriate for "room mentions", since those don't mention anything but rather indicate that a messge should alert users.

Sure, I do think people at least agree that its meant to get the user's attention more than a message otherwise would, but its use beyond that isn't agreed upon even if we only consider what's been discussed in this thread. The use-case you've proposed is seemingly to BE the room mention, which users send directly. Another use-case is for the MUC service to use when a message contains a mention. When forwarding the stanza to a user that's been mentioned, it attaches the element. There was also the use-case where its meant to mark a message as important or urgent, entirely independently from mentions/notifications. All three of these fill the niche of "grab the user's attention somehow", but do it for completely different purposes in different ways. I'm not sure it makes sense to depend on a XEP with no consensus, but if I were to use it, I'd most likely go with the second option.

These all seem like the same case. A room "mention" notifies the user. A message containing a mention notifies the user. An urgent message notifies the user.

Not exactly: on iOS for example, you can turn on something called "focus mode", which will mute/hide all notifications. Apps can break through focus mode for individual notifications if needed. For me, XEP-0224 is the exact right XEP to let the sender break through focus mode. Using it for mentions instead would mean I'd have to reinvent XEP-0224 for the focus mode usecase. I'd rather like a new XEP for the various types of mentions rather than having to reinvent XEP-0224 to be able to implement the focus mode usecase.

I'm not sure I think the second case is the thing to do, but it would work fine? Imho it is. TLDR; I'd like there to be a new XEP standardizing exactly this:

Another use-case is for the MUC service to use when a message contains a mention. When forwarding the stanza to a user that's been mentioned, it attaches the element.

-tmolitor

Am Donnerstag, 2. April 2026, 02:16:55 CEST schrieb Stephen Paul Weber:

Somebody signing messages as Thilo Molitor wrote:

...

...

These all seem like the same case. A room "mention" notifies the user. A message containing a mention notifies the user. An urgent message notifies the user.

Not exactly: on iOS for example, you can turn on something called "focus mode", which will mute/hide all notifications. Apps can break through focus mode for individual notifications if needed. For me, XEP-0224 is the exact right XEP to let the sender break through focus mode. Using it for mentions instead would mean I'd have to reinvent XEP-0224 for the focus mode usecase. I'd rather like a new XEP for the various types of mentions rather than having to reinvent XEP-0224 to be able to implement the focus mode usecase.

For 1:1 this is perfectly sensible, but do you want people in a MUC to be able to break through focus mode?

Yes, depending on the MUC (private group, configurable in my client, differentiating between participants of that MUC). So the XEP should at least allow this and leave it up to the client implementation on what configuration level gets exposed to the user. -tmolitor

These all seem like the same case. A room "mention" notifies the user. A message containing a mention notifies the user. An urgent message notifies the user.

Yes, but its the specific semantics that differ. In the first, the Attention element _is_ the room mention. My understanding is that Explicit Mentions isn't even used for room mentions in this scenario. The user sends the element itself, and the MUC just leaves it intact when forwarding to every member. In the second case, the MUC, not the user, is attaching the element. The user sends the mention, then the MUC attaches the notification _only_ on the stanza being sent to the users being mentioned. It works ALONGSIDE mentions, and is being sent by a different entity for more purposes than just room mentions. In the third case, it was less about notification and more about making the message look different as the attention-grabbing mechanism. It was likened to "important" messages in MS Teams. In this case, the element has nothing to do with mentions, as its used for something entirely different. Then there's the use-case Thilo just mentioned, where they go into "focus mode", which I assume might turn off normal mention notifications as specified here. In that case, it seems like they want Attention to be a way to forcefully notify someone regardless. This kind of aggressive message is what I had interpreted the XEP as, as well, when I first read it. The former two mainly differ in whether they expect a mention alongside the element, or whether it _is_ the mention. Meanwhile, the latter two actively require mentions _not_ to use XEP-0224, so that they can use it for some other purpose.

Why would there be both type and kind? These seem redundant. A "mention" of a group/hat is a fundamentally different thing than a mention, belongs in its own XEP, and certainly deserves it's own type or possibly own syntax.

For one, I'm of the opinion that its fundamentally the same thing to a user regardless of if I'm mentioning one or many people. It _could_ get away with just having whole new namespaces for every mention type in the 'type' attribute, but I'm not a fan of that. I'd prefer if an implementation is able to receive unknown mention types and actually know that they're mentions, which I can't do if we forego the 'kind' attribute and use new namespaces in 'type' for any extensions. Even if my client doesn't understand who the mention targets, it can still show it in the UI like any other mention, and messages might come with a button to show all of the attached mentions, which can just fall back to showing the target URI if it doesn't know what it is. Servers can also have more flexible mention-related rules if its able to tell when something is a mention, even if it doesn't know who got mentioned.

...

Because room mentions don't even have a target URI

By room mentions you mean attention XEP?

No, it seems clear to me that Attention isn't the right tool for room mentions. It'd be inconsistent with every other mention type defined, and actively goes against what people want for mentions. For example, everyone agreed that there's no use-case for invisible mentions, and that 'begin'/'end' should be required. Yet, Attention is literally only capable of invisible mentions. Not to say there isn't a place for it, just that this isn't it. Its been suggested that the MUC service could attach Attention elements when sending a message stanza to a user that has been mentioned. This would be the same for all mention types, whether its room, or individual, role/affiliation, hats, or anything else the MUC understands. But even then, I've also gotten feedback that people think Attention is the wrong tool for this use-case as well. It'd depend on what we want to go for when the notification stuff splits off into its own XEP, I guess.