jdev - 2026-03-13

> i dont think you can put multiple <mention> elements in one message without putting them in an encapsulating <mentions> element chat is this true? is something like this allowed: https://xmpp.org/extensions/inbox/explicit-mentions.html#example-7

of course you can put multiple elements in a message. That is a normal and expected thing

Lots of other XEPs already do this and it's just fundamental to XML anyway

that's what i thought i just wanted to make sure lol

Please don't put in a wrapper element that's just more bytes and more code

Maybe whoever said this was thinking of iq. And iq may only have one child (or two if one is an error iirc)

my interpretation was that he was just thinking of whether a message can contain multiple of the same element directly, or whether they need a container, so i don't think it was confusion with iq

I mean if start and end attributes should reflect the nickname

It really does not make sense that multiple elements have the same range

I really think the initial draft wanted to mark text passages and notify specific users for these passages

Yes for sure it makes no sense to have the same begin/end for more than one

The whole yep should be scanned for this previous idea of what start/end should mark. And also I'm asking myself is there a use for this other functionality? How did pep get the idea of that feature

the linked example seems to be an informal, client-defined grouping of users. rather than going "Hi rosa, clara, karl", it just groups them into one

> I really think the initial draft wanted to mark text passages and notify specific users for these passages pep's original draft can be found here: https://bouah.net/specs/mentions.html the very first example makes it clear that the intention really was to mark the name, not the message addressed to them ↺

> the linked example seems to be an informal, client-defined grouping of users. rather than going "Hi rosa, clara, karl", it just groups them into one This immediately popped into my head reading this https://youtu.be/qyS9ZV3aUqs?t=19 ↺

But check example 6

This can only be realized if I let a user mark text then assign mentione to this text passage ✏

This can only be realized if I let a user mark text then assign mentions to this text passage ✏

i mean sure that's one way you could do it, but the range still applies to the name of the mentioned group, not the message to that group (which'd probably be the "hi" part)

another way you could do this is have a client interface to assign users to groups to make it easier to mention a group in one go (in which case the range would be automatically set to the name of the group in the mention), which might especially be useful in the absence of hats or if you can't control hats

But that opens a door, and needs consideration in the gui

Overlapping ranges are always gross

A client could offer the possibility to create custom mention groups, which could then be easily accessed by the user

Just not sure if this is really something somebody needs ..

Indeed. But that needn't affect the markup

i already sort of have this in my app without any markup at all

Hm how without markup?

i expand the group mention to the names of everyone in the group with commas. Works with existing clients

Yes... Ok

But yeah MUC hats basically serv the same purpose

This are also custom groups

> Just not sure if this is really something somebody needs .. needs? probably not, just like i don't _need_ mentions, but i'd certainly _want_ it, because i do frequently mention groups of users and can't always use hats to do it, so a shorthand to do so would be nice, especially if it doesn't fill half the message with usernames ↺

for a user defined group you can't really do better. But yes if we add hat mentions that's similar but server side

Well the usernames still need to show up I thenk

you can't just show your locally defined group name and have it mean to mention all these people that's very confusing

Depends on the group name if it's clear to the user that the name needs to mean something to other people it's fine

> Well the usernames still need to show up I thenk i mention in a later section that the user interface should be able to show all the mentions in a message, kind of like read receipts and such. this is important even without group mentions, since i can exclude the 'begin' and 'end' attributes altogether ↺

definitely don't mention anything abuser interface "should" do that's not up to a xep

You can, but thats very weird

mentions in the xml are there for me so that clients and servers can interpret the body and do something

its not there to leave out text from the body

it should be additional to the normal body, not instead of the body

i think we should consider making start/end mandatory ✏

For non groups certainly it has to be. I may rewrite the body to use whatever name my app sees for that user but knowing where do put that is important

i also can hardly imagine a UI that makes mentioning not part of typing the message in the text entry, at which part a client cannot leave out the text simply

groups are a whole other can of worms and that's why I suggested splitting the xep

"non group", why would i use a mention there?

I mean when mentioning a participant not eg "every mod" etc ✏

for example I already support "notify every participant" and this does not have associated body text

> it should be additional to the normal body, not instead of the body i don't think there's ever a case where its "instead" and not "in addition", though? even without begin/end, you'll still display the body as always and _in addition_ notify the relevant users ↺

but thats not a mention in my eyes

that should be handled with the Attention XEP

Yes I agree and that is what I use

yeah ok, but now that "ALL" is out of the way, i would expect even for groups i have UI where someone types in the text entry, and the user can autocomplete groups like "Admin" and "Moderators"

and i would not remove this from the text i send on the wire

i see no case where i would need to attach a mention without start/end

also its problematic for backwards compat

I think I agree. If someone really wants to not show it when it is a prefix and use another UX it's pretty easy to detect that and snip it

However I also think hat etc mentions should move to their own xep and we can focus on the common case first

and also another design question, is it fine that we introduce another markup now here, would this not be better suited within 0394 ? or some new XHTML spec?

or is this bad, because servers would then need to understand the markup spec

Yeah I think it's that. You know I love some XHTML but there are arguments for the non styling part of this to be accessible

more easy

> that should be handled with the Attention XEP i'm not a fan of attention. that xep makes it pretty clear it only expects to be used with contacts in 1:1 chats, has no possibility of associating with the body, doesn't have any established permissions in mucs, is only be used to replicate @here and not @everyone, and overall seems like its meant to be an aggressive message that just got reapplied to room mentions because nothing better existed ↺

Obviously as the person who did it I disagree 🙂

> and also another design question, is it fine that we introduce another markup now here, would this not be better suited within 0394 ? or some new XHTML spec? once i learnt that references are considered dead, i considered using 0394, but i don't see a pressing need one way or the other ↺

Also I have no plan to ever implement 0394 so this sidesteps that heh

> i see no case where i would need to attach a mention without start/end if no one else sees a use-case for excluding begin/end, i'm fine with making it mandatory. i wouldn't personally need to exclude them ↺

> Also I have no plan to ever implement 0394 so this sidesteps that heh same but for XHTML-IM, so sounds like i'll be leaving it independent lol ↺

its easier to make them optional later than to make them mandatory later I think

true true

I’ve only been skimming the conversation, but I don’t see a reason for them not to be mandatory. “There’s a mention in here, somewhere, good luck!” doesn’t seem helpful :)

snit: You've been mentioning me a lot.

_something my XEP would fix..._

lol: kind of your choice

snit: maybe eventually. I don't expect any time soon

> I’ve only been skimming the conversation, but I don’t see a reason for them not to be mandatory. “There’s a mention in here, somewhere, good luck!” doesn’t seem helpful :) i'll change this bit then 👍 ↺

snit: exactly lol

neat i already edited all my examples to include begin/end pairs

so looks like i've already implicitly told myself excluding it is useless 🧌

also snit, https://xmpp.org/extensions/inbox/explicit-mentions.html#permissions

i dont think this is good, there is already a muc configuration form, and you can define in your XEP additional fields

i've already fixed that yeah

i would publish your changes asap

otherwise people read this and we talk about the same things again and again with different people

Will help at the council discussion also if feedback has been incorporated

we should treat this phase like a working group

it should be iterated fast on the XEP, and only if most agree that it is in a good state, then it should be brought before council

> i would publish your changes asap i asked the other day and was told i should wait until discussion dies down before submitting all the changes at once. however, i do have an unrendered copy of my working draft at https://git.isekai.rocks/snit/protoxeps/tree/explicit-mentions.xml i think its a lot better now that i'm not working under certain assumptions(i.e. future use of refs) and i've tried to incorporate most of the feedback so far. i can see about submitting what i have in a little bit if you guys would prefer that ↺

Other than that I’ve been slow in reviewing a PR for References, what _is_ the argument for not using References for … doing references?

One of the points of References in the first place was allowing one to do mentions (without further protocol).

but it kind of needs further protocol

we need various defined strings that identify groups which are mentioned, we need a attribute that has the occupant-id, there should somewhere a namespace with a version

i mean we could reuse the the "reference" element with start/end and type = mention, but then define additional attributes in the mentions XEP

should the type attribute in reference not point to a namespace?

so the reference element can be extended by other xeps?

or did you plan that the reference XEP is an ever growing all encompasing XEP that defines all types

snit, what i also find a bit weird is, that the MUC config form not really configures the MUC. Do i understand that correctly that the muc config form just is a place for an admin to tell clients what they *should* do?

References was somehow both too generic and also not fit for purpose. We could change it to be just about mentions but then the other uses go away and yeah I dunno. In the wild I've only seen it used for sims and only in a degenerate way

the proposal i originally picked up depended on a PR that never got merged. i submitted without the dependency so we could get the feature at all, but i'd planned on adding it back in the future. the council discussion the other day suggested most people don't care about refs at all, so my current draft stopped working under the assumption of using it at all. if i recall, some issues included not being clear how to extend refs, the uri attribute being required, and a single mention type being baked in already

> snit, what i also find a bit weird is, that the MUC config form not really configures the MUC. Do i understand that correctly that the muc config form just is a place for an admin to tell clients what they *should* do? I assumed the MUC config changed what mentions the MUC would strip or return errors for ↺

> snit, what i also find a bit weird is, that the MUC config form not really configures the MUC. Do i understand that correctly that the muc config form just is a place for an admin to tell clients what they *should* do? the muc config form at a minimum tells clients what they should do, but MAY also be used by the muc service itself to filter out invalid mentions. up to the muc whether it does anything itself though ↺

yes, its weird that an admin tells a client what to do

I think clients will do what they want and should not be affected by the MUC config ✏

if the MUC permissions are supported, the MUC must strip stuff, otherwise its not a "configuration"

Yes

hm fair enough

strip or return error. Dealer's choice

to be fair it wasn't originally muc configuration until i was told to put it there 🧌

it was a configuration form in a MUC even if it originally was a different iq 🙂

> References was somehow both too generic and also not fit for purpose. We could change it to be just about mentions but then the other uses go away and yeah I dunno. In the wild I've only seen it used for sims and only in a degenerate way I worked on https://modules.prosody.im/mod_muc_inject_mentions.html and have been using quite successfully Haven't read about this new XEP but References worked great so far. You can't mention a group of people though, so that seems like an improvement. So many XEPs :) ↺

what configs are there we imagine for participant mention? Mostly a max count one? (Of course rate limits etc are possible but this is up to the implementation of it wants all kinds of things)

> I worked on https://modules.prosody.im/mod_muc_inject_mentions.html and have been using quite successfully > Haven't read about this new XEP but References worked great so far. You can't mention a group of people though, so that seems like an improvement. > > So many XEPs :) saw that the other day, thought it was really cool :D ↺

The configform options need also work, Participants/Moderators/None, is a weird list ✏

>> References was somehow both too generic and also not fit for purpose. We could change it to be just about mentions but then the other uses go away and yeah I dunno. In the wild I've only seen it used for sims and only in a degenerate way > > I worked on https://modules.prosody.im/mod_muc_inject_mentions.html and have been using quite successfully > Haven't read about this new XEP but References worked great so far. You can't mention a group of people though, so that seems like an improvement. > > So many XEPs :) How does it even work? What uri does it use for a participant? ↺

that reminds me another problem with refs is that it only specifies jid

> what configs are there we imagine for participant mention? Mostly a max count one? (Of course rate limits etc are possible but this is up to the implementation of it wants all kinds of things) not sure i understand the question ↺

> that reminds me another problem with refs is that it only specifies jid That was, for mentions, basically the only problem. But it's a big one ↺

unless we wait for GC3 and use fulljid haha

Disallowing mentioning users is also a bit questionable, what use case would that be?

if a user does not want to be notified, then every user can configure their client to do that per chat

For unaffiliated participant in public MUC maybe

why would a admin make that decision for all the users

though I'd probably just make it a count and optionally set it to zero for unaffiliated

but why, this can be easily configured client side or not?

like most config stuff the implementation can do what it wants and add any new config it wants. Some people like to have examples included

why would an admin care and make that decision for all users

i mostly assumed if you want to limit one type of mention, there's probably a use-case for limiting the rest

should i even bother to specify permissions, or just let implementations do their own thing?

you mean a client option to ignore mentions from unaffiliated in all MUCs? I guess so

> should i even bother to specify permissions, or just let implementations do their own thing? I always lean towards the latter but I think it's important to at least mention it's possible to do because sometimes people forget ↺

but this should have a discovery mechanism

> should the type attribute in reference not point to a namespace? That’s a reasonable point. The intention was not that References be exhaustive, so namespacing (Clark?) makes sense.

or will say the xep doesn't mention it so "didn't intend" it or other such arguments. So mentioning and providing at least one example is sane

if a MUC strips stuff, i want to know before sending the message

true it'd be nice if the client can see beforehand whether to even offer the option

am i the only one getting insane lag when sending messages here

> that reminds me another problem with refs is that it only specifies jid In what sense? It allows URIs, no?

is an occupant id a uri?

you can make it into a uri

It easily could be, yeah.

oh i didn't know that

xmpp:chat@conf.server.com?occupan-id=123123

That’s a one line addition to occupant-id definitions in their XEP, yeah.

(I think it’s not there yet, unless I misremember, but it easily could be)

> Mentions are a reference to a user's bare JID, and have a type of 'mention'. refs still specifically states that its a jid though so in my eyes using anything else is nonstandard or should at least be expected to be treated as such

at least as-is

but if it needs to be updated either way i think it makes more sense not to include mentions at all in refs, personally ✏

> is an occupant id a uri? It will be ↺

Yes it would constitute enough of a change to refs that some people suggest a namespace bump. Once you're bumping namespace the benefits of reusing the same xep basically dissapear

> > Mentions are a reference to a user's bare JID, and have a type of 'mention'. > refs still specifically states that its a jid though so in my eyes using anything else is nonstandard or should at least be expected to be treated as such Fair. It allows URIs, but not for the mention case.

Kev, see now this is a situation where one could craft a plan that has a more holistic view on how to use multiple XEPs in combination. But we would need a authority who has this view and wants to make such decisions.

And the common mistake is to publish the XEP in experimental and then give recommendations. But the problem is, once the XEP is in experimental there is no real incentive for anyone to even work further on it, as its accepted on the xmpp homepage and every client can start to implement it.

I thought we had that holistic view when we did References in the first place, which I think was summit of 2016 - people were happy enough with the direction at the time, at least. Nothing much could change in a decade, right?

because you cannot expect from authors of single XEPs, to feel responsible for some holistic plan someone recommended

Im sure someone has a view and a plan, but this person needs to have the authority to reject XEPs as long as they dont fit the plan

this is the point that is not happening :)

I’ve finally re-reviewed the References PR that I think you were waiting for merge, and I don’t see why it’s necessary. It does a namespace bump, and the only change is changing ‘data’ to a URI, and what we’ve done in XEPs in the past is that things defined within the XEP tended not to be namespaced like this, while things defined outside the XEP tended to be namespaced to avoid collisions.

Or am I missing something?

(Well, plus the hreflang, which seems like it should be encoded in the anchor)

Or use xml:lang like normal

How would that work?

Or do you mean putting an xml:lang on the reference element? xml:lang usually refers to the language of text within an element, AFAIK, rather than that sort of indirection.

> I’ve finally re-reviewed the References PR that I think you were waiting for merge, and I don’t see why it’s necessary. It does a namespace bump, and the only change is changing ‘data’ to a URI, and what we’ve done in XEPs in the past is that things defined within the XEP tended not to be namespaced like this, while things defined outside the XEP tended to be namespaced to avoid collisions. its been a few weeks so i don't recall all the details, but i think the main things i saw were: * the uri is currently required, even though not all mention types need a uri or could necessarily be specified as one * the obvious redundancy of a baked-in and external mentions implementation (imo odd to bake it in when refs is otherwise so generic) * overall the update is more clear on how to extend refs in new ways ↺

> * the uri is currently required, even though not all mention types need a uri or could necessarily be specified as one Anything should be representable as a URI, though.

> * overall the update is more clear on how to extend refs in new ways I don’t think we need a namespace bump to document how to extend.

> > * the uri is currently required, even though not all mention types need a uri or could necessarily be specified as one > > Anything should be representable as a URI, though. i'm sure you can, but also like... why should i have to? it feels very arbitrary to me, personally ↺

If we need a uniform resource identifier, it would seem odd to invent something that wasn’t a URI, wouldn’t it? :)

I’m afraid I’m vanishing AFK now.

but we don't always need one... :(

>> > * the uri is currently required, even though not all mention types need a uri or could necessarily be specified as one >> >> Anything should be representable as a URI, though. > i'm sure you can, but also like... why should i have to? it feels very arbitrary to me, personally I mean... Your new xep defines URIs for the groups to mention. I was against it in this context, but obviously it's possible if there was a reason to ↺

And if we were reusing a generic thing it would best sensible and could use exactly the URIs you already made up

so... Maybe all we need to do is remove the line from references that says a mention has to be a bare jid.

And define the xmpp:muc@component/occupantid syntax from gc3 formally