XEP-0500: MUC Slow Mode

1. Introduction¶

There are some contexts in which you want to be able to rate limit Multi-User Chat (XEP-0045) [1] messages. This could have multiple motivations: avoid flooding, garantee a better readability of the room when there are hundreds of active users, …

This specification propose a new option to MUC rooms, allowing room owners to fix a duration that users MUST wait between two messages. We will also specify how the server MUST reject messages send too quickly, and how clients SHOULD handle this feature (by preventing users to send messages without waiting the delay to be over, and displaying some information to them).

2. Requirements¶

This document addresses the following requirements:

• How to allow room owners to enable and configure the feature by editing the MUC room discovery information.
• How to enable and configure the feature without allowing room owners to change the configuration.
• How the server MUST reject messages that does not respect the parameters.
• How clients SHOULD handle rooms with such feature enabled.

3. Glossary¶

Many terms used in this XEP are defined in Multi-User Chat (XEP-0045) [1] and Service Discovery Extensions (XEP-0128) [2]. Please refer to these XEP for more informations.

4. Use Cases¶

The MUC Slow Mode can for example be used when a MUC room is associated to a live video stream. In such case, there are often hundreds of people writing at the same time. To avoid flooding, and encourage participants to post relevant messages, slow mode can be usefull.

5. MUC configuration¶

<iq from='coven@chat.shakespeare.lit'
  id='config1'
  to='crone1@shakespeare.lit/desktop'
  type='result'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Configuration for "coven" Room</title>
      <instructions>
        Complete this form to modify the
        configuration of your room.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#roomconfig</value>
      </field>
      <field
        var='muc#roomconfig_slow_mode_duration'
        type='text-single'
        label='Slow Mode'
      >
        <desc>0=disabled, any positive integer= users can send a message every X seconds.</desc>
        <validate xmlns='http://jabber.org/protocol/xdata-validate' datatype='xs:integer'>
          <range min='0'/>
        </validate>
        <value>20</value>
      </field>
      <!-- and any other field... -->
    </x>
  </query>
</iq>

<iq from='coven@chat.shakespeare.lit'
    id='ik3vs715'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='The place to be'
        type='text'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#roominfo</value>
      </field>
      <field var='muc#roominfo_slow_mode_duration' type='text-single'>
        <value>20</value>
      </field>

      <!-- and any other field... -->
    </x>
  </query>
</iq>

6. Server-side rate limiting¶

When the Slow Mode is enabled, server MUST NOT accept two consecutive messages from the same user, to the same room, until the slow mode duration has elapsed.

Only messages containing at least one '<body/>' element must be taking into account (to avoid counting 'chatstate' messages for example).

Room administrators and owners MUST NOT be rate limited.

If a user bypass the limit, the server MUST reply an error stanza, that respects RFC 6120 [4] stanza erors (see RFC6120 - stanza errors), to reject the message. Especially:

• 'error_type' MUST be 'wait', as described in RFC6120 - Stanzas error - Syntax .
• 'error_condition' MUST be 'policy-violation', as described in RFC 6120 - Stanzas error - Defined Stream Error Conditions,
• the stanza SHOULD contain a <text>' element explaining why the message was rejected, and this message SHOULD mention the slow mode duration so that users can understand why they can't post their message.

Here is an example or error stanza:

<message
  xmlns="jabber:client"
  type="error"
  to="crone1@shakespeare.lit/desktop"
  id="528df978-aa6b-422a-b987-056a810c4733"
  from="coven@chat.shakespeare.lit"
>
  <error type="wait">
    <policy-violation xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      You have exceeded the limit imposed by the slow mode in this room.
      You have to wait 20 seconds between messages. Please try again later.
    </text>
  </error>
</message>

The rejected message MUST NOT be forwarded to other room occupants.

7. Client handling¶

When a participant joins a room, the client SHOULD request room information as described in section "Client discovering", and look for the 'muc#roominfo_slow_mode_duration' field.

If this field is present, and contains a valid strictly positive integer value, the client SHOULD display an information somewhere, to tell users that there is a slow mode limitation that applies to this room. This information MAY also be displayed to users for which the rate limit does not apply (administrators, owners, ...).

Moreover, each time a participant sends a text message, the client SHOULD prevent the user to send another message before the timeout is passed. This MAY be done either by disabling the input field, or the submit button. If the user has at least the administrator acces level, the client SHOULD NOT disable the input field or the submit button.

To avoid some frustrating behaviour, in case there is some lag on the server for example, the client MAY start counting time after receiving the message echo. Indeed, if the first message is processed with some delay by the server, it could consider that the duration is not passed yet when receiving the next one.

8. Security Considerations¶

As a same user can join a room with multiple sessions and/or nicknames, the server MUST use the appropriate criteria to identify the account, and apply the same limits to all user's sessions.

The slow mode duration parameter is a positive integer. When parsing its value, clients and servers MUST ignore invalid value. They MUST also check that this value is not to big to store in memory (this depends on the data type used by the implementation).

9. IANA Considerations¶

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

10. XMPP Registrar Considerations¶

<form_type>
  <name>http://jabber.org/protocol/muc#roomconfig</name>
  <doc>XEP-XXXX</doc>
  <desc>
    Forms extension for slow mode support in a MUC room.
  </desc>
  <field
    var='muc#roomconfig_slow_mode_duration'
    type='text-single'
    label='Slow Mode'
  />  
</form_type>

<form_type>
  <name>http://jabber.org/protocol/muc#roominfo</name>
  <doc>XEP-XXXX</doc>
  <desc>
    Forms extension for slow mode support in a MUC room.
  </desc>
  <field
    var='muc#roominfo_slow_mode_duration'
    label='Slow Mode'
  />  
</form_type>
  

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0500

Publisher

XMPP Standards Foundation

Status

Experimental

Type

Standards Track

Version

0.1.1

Last Updated

2024-12-03

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0001, XEP-0045, XEP-0068, XEP-0122, XEP-0128, RFC6120

Supersedes

None

Superseded By

None

Short Name

muc-slow-mode

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

John Livingston

Email

contact@john-livingston.fr

JabberID

john@im.yiny.org

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.1.1 (2024-12-03)¶

   Include first feedbacks

   jl
2. Version 0.1.0 (2024-11-28)¶

   Promoted to Experimental

   XEP Editor: dg
3. Version 0.0.1 (2024-02-28)¶

   First draft.

   psa

Appendix I: Bib(La)TeX Entry

@report{livingston2024muc-slow-mode,
  title = {MUC Slow Mode},
  author = {Livingston, John},
  type = {XEP},
  number = {0500},
  version = {0.1.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0500.html},
  date = {2024-02-28/2024-12-03},
}

END