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

On Tue, 17 Mar 2026 15:28:35 +0800 "Marvin W. via Standards" &lt;standards(a)xmpp.org&gt; wrote: 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: 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