Let's read XEP-0045!

Mediaclub
1

Continuing the discussion from Discover XEP-0045: Multi-User Chat:

I’ve started reading the XEPs (properly, I’ll admit I’ve read a bunch of these before! :nerd:).

XEP-0045 is available at XEP-0045: Multi-User Chat, no trackers. I’m gonna use this topic to comment. :slight_smile:

2

Abstract

This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc.

Author

Peter Saint-Andre

Copyright

© 1999 – 2019 XMPP Standards Foundation. SEE LEGAL NOTICES.

Status

Draft

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Type

Standards Track

Version

1.32.0 (2019-05-15)

Note: I want to know the differences of track status, presumably described in Discover XEP-0001: XMPP Extension Protocols.

1. Introduction

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously “groupchat” or “text conferencing”. Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That “groupchat 1.0” (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) is not compatible to the groupchat 1.0 protocol, but provides advanced features such as invitations, room moderation and administration, and specialized room types.

Cool background history. I tried searching for info on “groupchat 1.0” protocol, but can’t find many references not to this document.

3

2. Scope

This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are “common” in the sense that they have been widely discussed within the Jabber/XMPP community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in RFC 1459 [1] and its successors: RFC 2810 [2], RFC 2811 [3], RFC 2812 [4], RFC 2813 [5]).

This document explicitly does not address the following:

  • Relationships between rooms (e.g., hierarchies of rooms)
  • Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname); such use cases are specified in Service Administration (XEP-0133) [6]
  • Moderation of individual messages
  • Encryption of messages sent through a room
  • Advanced features such as attaching files to a room, integrating whiteboards, and using MUC rooms as a way to manage the signalling for multi-user audio or video conferencing (see Multiparty Jingle (XEP-0272) [7])
  • Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)
  • Mirroring or replication of rooms among multiple MUC deployments

This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by client and service developers alike. Future specifications might address the topics mentioned above.

Oh snap, got some RFCs in the mix! Those IRC RFC are… available for reading. :grimacing:

Discover XEP-0133: Service Administration is on my list. :slight_smile:

Okay, so we know what this isn’t about…

4

3. Requirements

This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. This design is based on the original groupchat 1.0 protocol, with the result that:

  • Each room is identified as a “room JID” room@service (e.g., jdev@conference.jabber.org), where “room” is the name of the room and “service” is the hostname at which the multi-user chat service is running.
  • Each occupant in a room is identified as an “occupant JID” <room@service/nick>, where “nick” is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant’s visit.
  • A user enters a room (i.e., becomes an occupant) by sending directed presence to <room@service/nick>.
  • An occupant can change his or her room nickname and availability status within the room by sending presence information to <room@service/newnick>.
  • Messages sent within multi-user chat rooms are of a special type “groupchat” and are addressed to the room itself (room@service), then reflected to all occupants.
  • An occupant exits a room by sending presence of type “unavailable” to its current <room@service/nick>.

The additional features and functionality addressed in MUC include the following:

  1. native conversation logging (no in-room bot required)
  2. enabling users to request membership in a room
  3. enabling occupants to view an occupant’s full JID in a non-anonymous room
  4. enabling moderators to view an occupant’s full JID in a semi-anonymous room
  5. allowing only moderators to change the room subject
  6. enabling moderators to kick participants and visitors from the room
  7. enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room, and to manage the voice list
  8. enabling admins to grant and revoke moderator status, and to manage the moderator list
  9. enabling admins to ban users from the room, and to manage the ban list
  10. enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room
  11. enabling owners to configure various room parameters (e.g., limiting the number of occupants)
  12. enabling owners to specify other owners
  13. enabling owners to grant and revoke admin status, and to manage the admin list
  14. enabling owners to destroy the room

In addition, this document provides protocol elements for supporting the following room types:

  1. public vs. hidden
  2. persistent vs. temporary
  3. password-protected vs. unsecured
  4. members-only vs. open
  5. moderated vs. unmoderated
  6. non-anonymous vs. semi-anonymous

The extensions needed to implement these requirements are qualified by the ‘http://jabber.org/protocol/muc’ namespace (and the #owner, #admin, and #user fragments on the main namespace URI).

Okay, tell me your not impressed by those features! It’s kind of amazing how flexible a MUC is, how many use cases it can accommodate.

On mage.party we have a main room and a moderator on a different server, because that is useful and dope. :slight_smile: