This page describes M-Link's support for Multi-User Chat, a key capability of XMPP systems. Isode's M-Link additionally supports Federated Multi-User Chat, essential for efficient and resilient operation over slow and unreliable networks, and use of Security Labal based controls for both multi-user chat and federated multi-user chat.
On other pages in this section, you’ll find information on M-Link’s use of Directory for configuration/authentication, security features, support for wide and local area clustering, operation over constrained/unreliable networks, Archive & Search, and support for Military Forms using FDP.
M-Link provides Multi-User Chat (MUC) as part of the M-Link server and also support Federated Multi-User Chat (FMUC) for distributed deployments with poor links between participants. Security Label based controls can be used with both MUC and FMUC.
M-Link supports capabilities as set out in XEP-0045: Multi-User Chat, including:
- Temporary and Permanent MUC Groups.
- Specification of Group Members
- Option for Member Only groups
- Invitation only groups
- Administrator and Moderator roles
- Ban Lists
- Password control (secured rooms)
- Moderation of Floor
- Kicking out Participants
- Membership access control which can be specified with AD or LDAP Groups
- Control of who can create MUC rooms (operator only, all, or specific list of domains and users)
- Clear History
- Ability to share NickNames in a MUC, so that users can connect with multiple clients using the same NickName.
- Record last activity, which enables removal of idle MUC rooms.
Federated Multi-User Chat (FMUC)
Multi-User Chat rooms reside on a single server. When operating in a distributed environment with poor links between servers, this leads to poor performance. M-Link supports XEP-0289: Federated MUC for Constrained Networks which allows MUC provision to be federated across multiple servers, addressing the performance problem and allowing for disconnected operation.
MUC rooms are independently configured on each MUC server in the federation, and then the rooms configured so that they subscribe to each other. Each of the MUC rooms on each server acts as a standard MUC rooms so, if a server is temporarily separated from other servers in the federation, it can continue to serve the local users with local traffic.
Further information is given in our whitepaper [Federated Multi-User Chat: Efficient and Resilient Operation over Slow and Unreliable Networks].
Security Label Based Controls
Isode's M-Link XMPP server and Swift XMPP client both support XEP-0258: Using Security Labels in XMPP. The core model is to associate a security label with each XMPP message with access to the message controlled by security clearance. The relationship between security labels and clearances is determined by a security policy.
In a MUC or FMUC environment the user is sending a message to a room in the same way as it is sent to an individual user. Security controls can be applied to the room itself:
- A room can have a security label ensuring that only users with an appropriate security clearance can join the room.
- A room can be given a security clearance ensuring that only messages with apropriate security labels are accepted for publishing in the room.
A room can work securely without having it's own security controls.
Within the room itself, labelled messages submitted to the room will only be passed on to room members who have an appropriate clearance. This approach to room security can be used independently of or in conjunction with the two room controls mentioned above.
Further information on using Suecurity Labels with M-Link can be found in the whitepaper [Using Security Labels to Control Message Flow in XMPP Services].
Setup and management of MUC rooms is covered in the Isode "XMPP Instant Messaging" Evaluation Guide. A further guide "XMPP Instant Messaging for Constrained Link Environments" shows setup of Federated Multi-User Chat rooms. Both are available, in PDF format, from the Documentation page of this website.