Standards
MUC and MIX: two answers to group chat
Group chat was bolted on twice, twenty years apart, and the second attempt starts from a different idea of who a member is.
Group chat is the harder half of instant messaging, and XMPP has answered it twice. A minimal groupchat protocol was running in the Jabber community as early as 1999; from 2002, Multi-User Chat, or MUC, rebuilt the idea with invitations, moderation and specialised room types, incompatible with what came before. Two decades later came Mediated Information eXchange, MIX, which keeps the familiar channel and changes what lies underneath.
The two part ways on questions a user meets: what a room calls you, whether your place in it survives your client going offline, and how finished each document is.
An address that knows your nickname
MUC borrows the addressing scheme the rest of XMPP uses. The room is room@service, an occupant room@service/nick. Joining is directed presence to that address, a changed nickname is presence to the new one, and leaving is presence of type unavailable. Messages carry the special type groupchat: each is addressed to the room itself, then reflected to every occupant. The resource slot, normally a device, becomes a person’s chosen name inside the room.
The worked examples are the witches of Act IV, Scene I of Macbeth, three occupants of [email protected] with affiliations running from owner to none. Where that nickname sits in the larger scheme is covered by the anatomy of a JID.
Who is allowed to do what?
MUC could grant every action individually; instead it bundles privileges under names a person can hold in their head. A moderator kicks participants and visitors, grants and revokes voice, the privilege to speak in a moderated room, and may alone change the subject. An admin bans users and manages the member list of a members-only room. An owner configures the room, names other owners, and can destroy it outright.
Two clocks run alongside the names. An affiliation lasts across visits; a role lasts only for a visit, and the two are not mapped onto each other: a visitor with no affiliation at all can hold the moderator role for a single session.
What a room can be
The same protocol serves a public support channel and a private committee. A room takes a side in six paired settings: public or hidden, persistent or temporary, password-protected or unsecured, members-only or open, moderated or unmoderated, non-anonymous or semi-anonymous. Anonymity is the pair with teeth: in a non-anonymous room every occupant sees every other occupant’s full JID, while in a semi-anonymous room that sight belongs to moderators alone. Logging is native, no in-room bot required, and users can request membership rather than wait for an invitation.
All of it travels under the http://jabber.org/protocol/muc namespace, with #owner, #admin and #user fragments carved off. What each bundle may do fills the Multi-User Chat specification itself, longer than any summary suggests.
What MUC leaves out, on purpose
The scope section is as informative as the features. MUC addresses one room at a time and refuses the rest: relationships between rooms, administration across a whole service, moderation of individual messages, and encryption of the messages that pass through a room. Files, whiteboards and signalling for multi-user audio or video conferences are left to other specifications, as are IRC gateways and mirroring rooms between deployments. The refusal is deliberate, meant to leave a protocol that client and service developers alike can implement.
One omission reaches users directly: encryption through a room is out of scope here, so what end to end encryption covers is a question this document never answers.
The same shape on new ground
MIX describes itself as a replacement for MUC. The core chatroom features people know are still there, topics and invitations among them, along with a strong access control model: bans, named administrators, controls on who may participate. What changes is the machinery. Where MUC defined its own methods, MIX builds on Publish-Subscribe for access and publication, and on Message Archive Management for storage and archiving, reusing building blocks that arrived after MUC was designed, MAM among them for history.
The stated reasons are blunt: new use cases emerged, some applications, multimedia conferencing among them, fit MUC badly, and several requirements cannot be met by MUC or by extensions to it.
Why should membership survive the client?
The requirement that separates the two designs most cleanly is persistence. In MIX, participation in a channel persists and is not modified by the user’s client going online and offline. Multiple devices on one account share the same nick, with rules that keep each client individually addressable. Presence stops being load-bearing: channels need not reflect it, messages can be shared without it, presence without messages, and a reconnecting client resyncs quickly.
Other requirements answer problems the older protocol was never asked to solve: messages received as an invisible observer, configuration read from outside, mechanisms to prevent JID harvesting, and federation across servers.
One family, two statuses
MIX is not one document but a family: MIX-CORE, the central mandatory specification; MIX-PRESENCE; MIX-PAM, for the server holding a user’s account; MIX-ADMIN; MIX-ANON, which hides real JIDs; MIX-MISC; and MIX-MUC, which defines co-existence with MUC. Only two are mandatory to run a service, and more parts are expected.
Co-existence is designed in rather than hoped for: a server can implement MIX and still present a MUC interface for clients that only speak MUC, and a client can implement both so the two feel like one experience.
| MUC | MIX | |
|---|---|---|
| Number | XEP-0045 | XEP-0369 |
| Status | Stable, Standards Track | Experimental |
| Version | 1.35.5 (2026-05-03) | the page does not publish one |
| Authors | Peter Saint-Andre | Kevin Smith and Steve Kille |
| Built on | its own muc namespace | Publish-Subscribe and MAM |
MUC carries its Stable label with a published caution attached: implementations are encouraged, deployment in production is appropriate, and changes are still possible before it becomes a Final Standard. MIX sits at Experimental, the first of four lifecycle stages. Before joining a room, read the address your client builds: a nickname appended to the room name is MUC’s occupant model, and a channel that still holds your place after your client has been away is MIX, doing what it was written to do.
xmpp.org is where the numbered extensions are published: each page carries the abstract, the author names, the status, the copyright line and the document lifecycle, followed by the specification.