Re: Proposed XMPP Extension: Explicit Mentions

On Tue, 10 Mar 2026 10:04:40 -0500
Stephen Paul Weber <[email protected]> wrote:

> >URL: https://xmpp.org/extensions/inbox/explicit-mentions.html  
> 
> 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.

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.

> Do we want to bother supporting both cases in this day and age? While 
> occupant IDs are redundant an unnecessary in a non-anonymous MUC,
> more and more XEPs and app features are moving towards requiring them
> anyway. It reduces complexity at the expense of a (small) extra
> payload which MUCs increasingly include anyway.

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.
 
> Besides this, the example then goes on to show an occupantid
> attribute with something shaped more like a JID in it, which may be
> confusing.

Good point, I was just lazy there :P

> > urn:xmpp:mentions:0#channel  
> 
> This is already covered in practise by 
> https://xmpp.org/extensions/xep-0224.html -- it also doesn't fit the
> data model of this mention XEP well since there is no natural
> "begin/end" for this?

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

> How is this meant to work in practise? How will you notify users of a 
> different MUC?

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.

> > urn:xmpp:mentions:0#space  
> 
> How is this meant to work in practise? How will you notify all the
> users who hapen to be participants or members (which is it?) in MUCs
> listed in a pubsub node?

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.

> > urn:xmpp:mentions:0#server  
> 
> What is even the use case for this? I thought at first it meant MUC 
> component, which is something that could be useful and I could see
> maybe how to implement, but it actually seems to mean "home" server.

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.

> > Mentions via Roles and Affiliations  
> 
> I think I would suggest moving all the group mention stuff to a
> second XEP. It makes this one quite large while obscuring the main
> use case (direct mentions) and in general has a different data model
> (often no being/end vs direct which should probably require a
> begin/end).  I might also suggest unifying roles/affiliations/hats
> something like this:
> 
> <mention mentions="role" />
> <mention mentions="affiliation" />
> <mention mentions="hat uri" />
> 
> That is to say, if it is one of the strings on the defined list it
> mentions that thing, and otherwise is a hat URI.  There is no reason
> for all of these role/affiliation strings to be URIs they are a
> well-defined historical list already used in other protocols.

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.

> > Begin and End Attributes  
> 
> Needs to mention https://xmpp.org/extensions/xep-0426.html

Didn't know about that, but definitely adding it :D

> I appreciate the XHTML-IM mention. Might be nice to even define a
> markup for that (eg <span class="h-card"><data class="u-uid"
> value="OCCUPANTID"/><span class="p-name">name</span></span>)

I'm not too familiar with XHTML use in XMPP, so I'll leave that stuff
to others :P

> > Hreflang Attribute  
> 
> Why invent this attribute rather than using xml:lang ?

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.

> > This section provides a mechanism for administrators to set
> > permissions in a MUC, which receiving entities SHOULD refer to when
> > deciding whether to notify the user.  
> 
> We have a way to configure settings on a MUC already. Why not use
> that?

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.

> Also I believe this should specify that any mention not allowed to be
> used should be stripped by the component, rather than requiring
> clients to fetch the permissions and enforce locally on receiving.

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.

> > If the user is not an owner, a <forbidden /> error MUST be
> > returned.  
> 
> I think it should be up to implementation who is allowed to change
> things. Nevertheless I think the normal MUC configuration form should
> be used and then this doesn't need to be specified separately at all.

Works for me.

> As a last note there are several TODO sections still in the draft as 
> submitted.

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?
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]