MUC Mention Notifications

%ents; ]>

MUC Mention Notifications This specification documents how a user may be informed when they're mentioned in a MUC which they're not currently joined to. &LEGALNOTICE; 0452 Experimental Standards Track Standards Council XMPP Core XEP-0001 Etc. NOT_YET_ASSIGNED &jcbrand; Severino Ferrer de la Peñita soul@blastersklan.com soul@blastersklan.com &mwild; 0.2.2 2022-01-11 gh/@xnamed Fix addresses in example 0.2.1 2021-02-12 ps Fix reference to XEP-0297: Stanza Forwarding 0.2.0 2021-02-09 jcb Require nickname registration for notifications to work 0.1.0 2021-01-26 XEP Editor (jsc) Accepted by vote of Council on 2021-01-06. 0.0.1 2020-12-17 jcb

First draft.

The &xep0045; specification does not provide for a mechanism whereby an user might be informed of being mentioned in a Multi-User Chat (MUC) without being present as an occupant of that MUC.

This XEP aims to provide a standardized way in which this might be achieved.

Concerning "being mentioned" in a MUC, we will rely on &xep0372; as the means whereby someone is explicitly mentioned in a MUC message.

A user's client must be able to receive forwarded groupchat messages from a MUC in which that user is mentioned, while not having an active session in that MUC (i.e. without joining it).

For this to be possible, the MUC needs to know the user's JID and MUC nickname even when that user is not currently present in the MUC. &xep0045; section 7.10 ("Registering with a Room") describes a mechanism whereby a user can register a nickname with a MUC and it is recommended that this is the mechanism used to keep track of users across sessions.

Whether or not mesages are forwarded will be determined by a configuration setting on the MUC.

The MUC owner(s) will therefore determine whether notifications are sent out, and if activated, users may opt in or out (or have that done for them by a privileged user) by having their nicknames registered or not with the MUC.

When an owner creates or configures a MUC, the service offers the option to send out mention notifications to non-present, but still affiliated users:

http://jabber.org/protocol/muc#roomconfig ... 0 ... ]]>

The owner specifies a value of "1" or "true" &BOOLEANNOTE; if the feature is desired:

http://jabber.org/protocol/muc#roomconfig ... true ... ]]>

When an affiliated user in a given MUC is referenced in a 'groupchat' message via &xep0372;, and the MUC is configured to forward mentions, then the MUC will forward the message stanza to the user.

secondwitch: Thrice the brinded cat hath mew'd.

]]>

Notice that in the example above, the entire original 'groupchat' message (including elements added server-side, like the &xep0359; stanza-id) is encapsulated inside a &xep0297; element.

Similarly to &xep0280;, the security model assumed by this document is that all of the resources for a single user are in the same trust boundary.

Forwarded groupchat messages leak information of who is currently present in a MUC without requiring the user to join the MUC first to find out.

Any forwarded copies received by a client MUST be from a valid MUC JID which matches the MUC JID of the encapsulated, forwarded mesages;
any copies that do not meet this requirement MUST be ignored.

None.

The ®ISTRAR; includes 'urn:xmpp:mmn:0' in its registry of protocol namespaces (see &NAMESPACES;).

urn:xmpp:mmn:0

&NSVER;