Types of chat¶
There are two kinds of multi-user chat. Private group chats, and public channels1.
To detect if a multi-user chat is a group chat or a channel
|MUC Configuration variable (1)||Group chat||Disco Feature (2)||Channel||Disco Feature (2)|
|MAM enabled||Prosody muc#roomconfig_enablearchiving
ejabberd community: mam
ejabberd saas muc#roomconfig_mam
|Subject editable||muc#roomconfig_changesubject||No||muc#roomconfig_changesubject to
|JIDs revealed||muc#roomconfig_whois||Yes (3)||muc_nonanonymous||No||muc_semianonymous|
|Publicly listed||muc#roomconfig_publicroom||No (3)||muc_hidden||Yes||muc_public|
|PMs||muc#roomconfig_allowpm||No (3)||muc#roomconfig_allowpm to
(1) As defined in XEP-0045: Multi-User Chat - 16.5.3
(2) As defined in XEP-0045: Multi-User Chat - 16.3
(3) Immutable for group chats.
(3) Immutable should be used when creating group chats, and also as a means of detection. These options may be hidden or greyed out in a configuration dialog. The other options are recommendations.
While it is possible to entirely prevent PMs from being sent with
clients should prefer using JIDs when
muc#roomconfig_whois is set to
In channels, if the initiating client has access to revealed JIDs (with
muc#roomconfig_whois set to
moderators), clients may want to refrain from
using them to prevent disclosing the JID of the user initiating the chat,
unless the recipient already knows them from another venue (e.g., the
recipient is in their roster).
People in the group chat / channel: Participants
Roles are not displayed and cannot be modified through the UI.
|Affiliations||In group chats||In channels|
(*) A group chat will display an existing admin as such but it will not encourage/allow someone to be promoted to admin. UI options in group chats only allow a member to become an owner but not admin. So admins are discouraged by the UI but will be displayed as such if they end up being one for some reason.
(**) Everybody is a member in group chats
Clients MAY create an 'advanced view' that displays roles as well.
When joining a group chat, a client needs to select a nickname to use. There are multiple sources from which this name may be selected. The client should use the following sources in order:
- If the chat is present in the user's bookmarks and has a nickname present (as the resource).
- Reserved name
- A chat may be queried to fetch the name that is registered by the user for that chat.
- User nickname (PEP)
- The name stored in the user's account according to XEP-0172.
- User nickname (vCard)
- The name stored in the user's vCard as
- Local nickname
- (Optional, not recommended2) A nickname previously configured by the user in this client instance.
- JID username
- The username portion of the user's JID (i.e. before the '@').
Other user's names¶
The display of other user's names is covered in the general UI recommendations.
Figuring out which group chats to join is the client’s job. For that it should store the list of group chats to rejoin automatically on the server, named bookmarks. Three possible protocols exist for this:
- XEP-0402 which is the current preferred method
- XEP-0048 1.1, recently deprecated but still in use by some clients
- XEP-0048 1.0, in wide use, based on XEP-0049
In order to see the same set of bookmarks as every other client the user might be using, it is recommended to implement XEP-0048 1.0 first and foremost when the user's account may be shared with other clients.
This legacy protocol however doesn’t support notifications when the bookmarks change due to another client or the server. To avoid this issue, a modern client should also implement XEP-0402 ("PEP Native Bookmarks"), but use it only if the account advertises 'urn:xmpp:bookmarks:1#compat' (as defined in XEP-0402 paragraph 5.3 Compatibility).
Implementing XEP-0048 1.1 is not recommended in modern clients.
The following table summarizes the implementation recommendations described in this section:
(Private XML storage)
(for backwards compatibility)
(PEP storage, single-item)
(deprecated in favour of XEP-0402)
(PEP storage, multi-item)
Clients must always use real JIDs for messaging privately within a group chat if (and only if) JIDs are publicly visible to all participants.3
To avoid requiring the user to configure a nickname manually on each device, shared cross-device stores such as PEP and vCard should be preferred. ↩
If real JIDs are known to all participants, it is preferable to use that for private communication to avoid confusion. Through-MUC PMs have the following disadvantages:
- Only work while connected to the group chat
- Do not interact well with multiple devices (e.g. not all of a recipient's devices may be in a group chat)
- Can cause confusion if talking to the same person through different views (e.g. if the person is already a contact in your roster, and you already have a chat open with them)
However if the sending user is an admin of a room where JIDs are hidden, using a real JID will reveal the admin's private JID to the recipient. Either warn the sender that their JID will be revealed, or always use the in-room JID in such channels. ↩