XEP-Remarks/XEP-0045: Multi-User Chat

This is a page for information about XEP-Remarks/XEP-0045: Multi-User Chat, including errata, comments, questions, and implementation experience.

Ban time period

As of 2020, there is no the specification of the ban time period. It is needed to add the feature in the XEP-0045.

- https://logs.xmpp.org/xsf/2020-05-25#2020-05-25-7e5712f062e33e68

- https://logs.xmpp.org/xsf/2020-05-26#2020-05-26-26d63c58841f2085

Stable Message IDs

As of 2018, server implementations are required to keep the message ID when reflecting client messages. This can be determined by the presence of the 'http://jabber.org/protocol/muc#stable_id' feature on the MUC JID or MUC domain.

Ambiguities

http://mail.jabber.org/pipermail/standards/2014-April/028805.html

Introduces 'ofrom' Extended Stanza Addressing (XEP-33) type

in http://xmpp.org/extensions/xep-0045.html#enter-history, which is not found in XEP-33 (nor XEP-33s schema).

Matching Your Reflected Message

So you sent a message to a MUC and want to immediately display it as "on the way" (good UX). Some time later (usually within some seconds) you receive a message from the MUC which might or might not be your sent message.

Find out if a relfection is your actual message, in six easy steps! The message is your reflection if:

1. you recently sent a message to the MUC, AND
2. the received message is from your participant JID, AND
   1. the XEP-0359 origin ID matches (probably not a transport) OR
   2. the message ID matches (a nice MUC, but not required by the XEP) OR
   3. the message body matches (not conclusive, some MUCs auto-pastebin) OR
   4. the received message is the first line of the sent message (transports like IRC split multi-line messages into one-liners) OR
   5. the sent message is very long (>400 bytes) and the received message is a prefix of it (IRC transpors split very long one-liners too!)

(this mechanism doesn't cover MUCs which don't reflect the message ID and do autopastebin. Screw them!)

Mediated MUC Invitations

The default mechanism to invite somebody into a MUC is §7.8.2 Mediated Invitation, where the MUC service will invite your friend on your behalf.

• Some MUC services will not invite a JID that is already a MUC member, thus breaking the invitation UX.
• With Mediated Invites, a malicious MUC can send an invite in the name of a user's contact, tricking the user's client into auto-joining.
• XEP-0249: Direct MUC Invitations is a potential solution to those issues.

Am I still there?

Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely, only seeing silence.

There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined. Sending a "silent" message or presence update to the MUC will lead to O(N²) complexity (if every client does so), killing all our batteries.

This is solved by XEP-0410: MUC Self-Ping

MUC double join

This has been fixed in revision 1.29 of XEP-0045:

It's not specified what should happen if an entity sends an initial presence when it's already joined. Server implementations should behave towards the joining entity like it successfully joined. That means, if a presence update containing an <x> element is received from a participant, the server should send back the full presence list, the requested amount of history and the room subject.

MUC PM messages are not distinguishable from other MUC messages

http://mail.jabber.org/pipermail/standards/2015-May/029819.html

Why do I need to host my MUC component on subdomain.domain.tld?

You don't. You don't even need to host it on "domain.tld", you can host it on any bare JID you want (without a resource, with or without a node). Not all clients will be able to join, because this isn't how it's always been done but technically nothing prevents it.

You also can have a room directly on subdomain.domain.tld, or domain.tld.

Clients will generally expect to be able to create rooms on the address that is given to them in disco#items on the host (the "MUC component").

disco#items on a component will get you a list of rooms hosted on it, while disco#items on a room should get you a list of occupants, even though servers generally don't disclose the occupant list this way. It is possible to get the occupant list (presences) by joining the room. This seems to be the only possibly conflicting feature, if a room and a component were to be used on the same address.

Maybe a more explicit disco feature should be added to say "You can create rooms off here". Without this, it isn't possible to say whether room creation is actually possible other than trying and reading the error. It would also probably look very awkward for a client to try to create a room off a "component"/"room" hosted at "foo@domain", trying to create "bar@foo@domain" which isn't a valid JID.

Joining Cisco Jabber Rooms

Cisco Jabber will not set `<status code='110'/>` on the joining occupant's self-presence. Therefore, clients will probably not detect the completion of a join.

A possible workaround (looks like all Cisco Jabber rooms are non-anonymous): match on the JID inside the provided `<item role="participant" jid="full-JID" affiliation="none"/>`