On Tue, 10 Mar 2026 10:04:40 -0500 Stephen Paul Weber &lt;singpolyma(a)singpolyma.net&gt; wrote: The original idea was to use references, but the required updates to that specification were never merged. I tried keeping this proposal as close to references as I could so it could be easily converted to use them in the future, but based on council discussion, it sounds like this might be unpopular. If so, I can clean up the proposal to stop working under the assumption of references being used later. I mainly added the JID method as a catch-all for any context now or in the future where occupant IDs might not be available. JID mentions might seem useless in 1:1 chats, but one possible use-case is to refer to an entirely different user while still getting mention pills. A client could use this to allow users to perform quick actions by clicking the pill, such as "Add contact" or "Message user". Nonetheless, I don't have a strong opinion either way. If the preference is to remove JID mentions, I'm fine with that. Good point, I was just lazy there :P I was under the impression that XEP-0224 was for 1:1 chats, but I'm also not convinced they necessarily cover the same use-case. For one, a message like "Hello, @room" or "Hello, @everyone" WOULD have a natural 'begin'/'end' range: "@room" and "@everyone". Even the example used in the proposal could use "all" for that. For two, it allows specifying a different room than the current one. Again, might seem odd, but one of the main goals is pillification within clients as mentioned earlier, so I could see it being useful for getting the attention of all members of a DIFFERENT room, or just referring to the room (using the <noping /> element). See above, but also notifications are client-side. It isn't really meant to notify ALL members of that MUC, but more to notify users in the current context who are also in that one. "Is anyone here also in <room>?" or "Guys, I think <room> is getting spammed T_T" might be potential examples. Same as before, if you receive a message with a mention to a space you're part of, then your client should notify you. Since XEP-0503 intentionally doesn't cover space membership, it would be up to the client to decide whether they consider themselves part of the space. I honestly forgot why I added this one. I could see it being useful for pillification using <noping /> as mentioned earlier. Maybe notifying users of S2S difficulties with their server or something. I could remove this and not miss it much, on further thought. I still think group mentions have a pretty obvious begin/end in most cases, though specifying one isn't required: "@room: Please review our new rules" -> "@room" "@moderators: We're under attack!" -> "@moderators" "@gamer-hat: Who's up for some gaming?" -> "@gamer-hat" "Anyone there?" -> none (probably a #channel + <active /> mention) I used a URI for the 'mentions' attribute predominantly to allow expansion either in specialised use-cases or future XEPs. It was also done to make implementing only a subset easier, such as if they don't care about MUCs or spaces, and thus don't need #channel, #space, or #associations. If split into two XEPs, would this one be solely for individuals and modifiers, while the second one is an extension for the group types? I certainly wouldn't mind that. Didn't know about that, but definitely adding it :D I'm not too familiar with XHTML use in XMPP, so I'll leave that stuff to others :P This was an artifact of intending to depend on references. Unsure why that used 'hreflang', though. I can change it if the dependency is going away. I wasn't sure if I was supposed to use that or define my own thing. If I am supposed to use it, then I'll gladly change that. I wrote that servers MAY filter prohibited mentions in Security Considerations. At the very least, I don't think clients should EXPECT that MUCs will do the work for them. Clients will need to check every mention anyways to verify it both applies to the user and complies with their client-side notification settings. Works for me. Indeed, I didn't want to do those sections until I'm reasonably sure the specification won't change too much. Based on feedback here and in council@, that seems to have been a good choice. I appreciate the feedback, thank you. I'll work on making some revisions. To submit them, I take it I just make another PR? Or should I wait to make edits until after the voting period?

On 24 Mar 2026, at 14:17, Goffi &lt;goffi(a)goffi.org&gt; wrote: My summary is roughly that there’s stuff in the mentions spec it makes sense to talk about, but it also makes sense to use the references format for the reference part. /K

On Tue, 10 Mar 2026 18:47:05 +0100 Philipp Hörist &lt;philipp(a)hoerist.com&gt; wrote: 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".

On 2026/03/10, Snit Guckfung via Standards wrote: 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.

On 2026/03/11, snit via Standards 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).

Hi, On 2026/03/11, snit via Standards wrote: I think the MAY is unnecessary here, i dont think the spec should make any recommendation how the plaintext of a mention should look like. The sentence is just an example of something that could happen on the wire and how to handle it. On Wed, Mar 11, 2026, at 02:43, Maxime Buquet wrote: 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". 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? Regards Philipp

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. And also, this is an IF. Any implementation that doesn't want to send extra characters can just... not. The recommendation isn't TO send them, but just the way to do it IF you send them. On 13 March 2026 10:51:04 am UTC, Maxime Buquet &lt;pep(a)bouah.net&gt; wrote:

On Fri, Mar 13, 2026, at 13:49, Maxime Buquet 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. 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? 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. Regards

On Fri, 13 Mar 2026 13:49:30 +0100 Maxime Buquet &lt;pep(a)bouah.net&gt; wrote: 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 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"

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? Regards Philipp

On Sat, 14 Mar 2026 12:05:05 +0100 Maxime Buquet &lt;pep(a)bouah.net&gt; wrote: For individual user mentions, I imagine any compelling reason would be pretty obscure, but for group mentions, I do think I would prefer to send things like "@everyone", "@room", or "@here". Including the '@' in those cases wouldn't interrupt implicit mentions AFAIK, while also making it clear to users of unsupporting clients that it _was_ a mention and not someone going "Here, check this out" normally. I'm not quite sure I understood this bit properly, sorry. What exactly do you mean by "eating" here? What would the note be, specifically?

On Wed, 11 Mar 2026 02:36:53 +0100 Maxime Buquet &lt;pep(a)bouah.net&gt; wrote: No problem, and thanks for letting me use your work as a base :D The feedback I've gotten thus far has made me realise that what I was really going for here was a way to explicitly reference various things (users, groups, rooms, etc), with the whole notification bit being an addition. I guess if I were to do this from scratch, I'd want to reframe the entire proposal around that, but I fear it might be a bit late for that... I went into more detail with my reply to singpolyma, but one of the reasons I left in the ability to mention by JID is to allow you to reference, not mention, other users, even in 1:1 chats and even if the referenced user isn't present. In such a case, the goal is less the notification, and more the ability to display a UI element (the pill), which could be interacted with to provide buttons such as "Add contact" and "Message user". For rooms, it could be "Go to room" or "Join room". The <noping /> element exists for similar reasons. If I were to reframe the XEP from scratch, I suppose it would've made more sense to make this the default, and then have a <ping /> or <notify /> element for actually notifying the referenced user(s). This seems to be a source of confusion; I've already updated my working draft to try to clarify the goals I was going for more clearly, but I can also just strip everything not directly meant to notify one or more users out if no one else cares. Such things could go in a later proposal, though I suspect the idea of referencing a user is largely redundant with mentioning them... Much to think about, but in any case, thank you for the feedback :D

In the direct mention case, I don't think we really wrnt to allow one without the other. I am also against noping though. It is not up to the sender if I want to be notified. 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. At which point we are maybe back to a minor update the references XEP rather than a nnw XEP for this, per jdev discussion the other day. Just need a URI for occupant IDs which we could define new or GC3 style (xmpp:muc/occupantid)

You mention people without any indication in the body that you mentioned them in Slack?? How? This email thread has already pretty much had everyone including the original author and the ProtoXEP author saying that will be removed. I forgot it was still in the published draft. 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)

Somebody claiming to be Marvin W. 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.

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.

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

A variation of this also happens a lot on Discord where you have the split notions of mentioning a person with ping and mentioning a person without ping. FWIW, 372 is used and deployed for things other than mentions, e.g. files and pubsub items. I do agree there’s a bunch in there that needs tidying up - there was a PR that tidied some things up, but did many things in one go, some of which I didn’t agree with. /K

Hi, just to throw my opinion in: I'm in favor of everything Marvin wrote and for Monal I would like to implement things exactly like Marvin suggested (2 XEPs, usage of XEP-0394 and XEP-0224 etc.). -tmolitor Am Dienstag, 17. März 2026, 08:28:35 CET schrieb Marvin W. via Standards:

I'm definitely not 100% set on using XEP-0224, I just considered it a good potential reuse of our existing tech, but if you believe it is not, I'm happy to be convinced otherwise. That said, XEP-0224 is clearly not meant to be used in the way you described. It should not affect the display of the message itself, it should only draw the users attention to the chat session. The <attention/> tag can even appear without a body. The implementation notes list various ways to implement it, but none of them affect the display of the message itself after the attention was grabbed. Marvin On Tue, 2026-03-17 at 19:41 +0100, Philipp Hörist wrote:

On Tue, 24 Mar 2026 at 17:08, Daniel Gultsch &lt;daniel(a)gultsch.de&gt; wrote: Also, random thought - it'd be great if I could draw someone's attention to a particular message without having to simply send a message of my own mentioning them. I'd say a solid 10% of mentions in Slack, possibly more like 25%, are people just mentioning people in a thread. It'd be nice to have a protocol-level way of doing this, like a reactionish mention. Dave.

I think I agree with Goffi. /K

Thanks for your reply (and Kevin's one), yes it made it in time. Le mardi 31 mars 2026, 15:53:02 heure d’été d’Europe centrale Snit Guckfung via Standards a écrit : I'm a bit short in time to reply to this part in details, I'll need more time to check this. With Explicit Mention, you have to be in the room to see the notification (as it's sent to the room itself), right? My point is if you are in a huge room with lot of traffic, but not willing to see every single message: you are interested in going there from time to time, and being notified if somebody mentions you. In this case, you need to have the mention directly addressed to you, not to the room. Then you can join and retrieve messages of interest with MAM. Another use case is mentioning somebody who is not an occupant of a room. But we may or may not want to handle this. For now, the important part is to have a way to notify somebody that they are mentioned in a blog, forum, event or whatever. This is possible with XEP-0372, the pubsub item URI is used. Referencing with begin/end the content is not possible at the moment though (as we would need a way to specify which element is used). IIRC Markup has been done after XHTML-IM has been deprecated (or around this time at least). It shouldn't be taken into account anymore (except if it comes back to life as requested by some people, but that's another story). I'm not sure to understand your point here. Markup would need an (probably short) extension to explain that something is a mention. No worries, we're all busy after all. It made it in time, thanks. Best, Goffi

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? 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? XHTML-IM is deprecated, but it seems people still intend to continue using it for various purposes, so it seems off to disregard it entirely. Regardless, I was using XHTML-IM as a stand-in for any markup format that isn't XEP-0394, be it XHTML-IM, XEP-0393, or some future XEP or proprietary format. I do the same in the following section, as well. 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 :)

A partial implementation still lends "legitimacy" to the XEP and increases the odds it ends up at least partially entrenched in implementations, though. And this would hardly be the first time we've done this. Should fallbacks be part of 0394 too? Nevertheless when I look at the actual example given, maybe 0394 could be split in such a way that we get a XEP defining the <span/> element without the <markup/> parent on any defined children. Then it would of course make sense for mentions and fallbacks to use that. Instead of moving everything that uses a span concept into the same one XEP.

Somebody claiming to be Snit Guckfung via Standards wrote: 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.

Somebody claiming to be Snit Guckfung via Standards 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. I'm not sure I think the second case is the thing to do, but it would work fine?

Somebody signing messages as Thilo Molitor wrote: For 1:1 this is perfectly sensible, but do you want people in a MUC to be able to break through focus mode?

Somebody signing messages as Thilo Molitor wrote: Oh sure, if in a private group where you normally get notifications for messages then it becomes the same as 1:1 again that makes sense.

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. By room mentions you mean attention XEP?