diff --git a/inbox/xep-slow-mode.xml b/inbox/xep-slow-mode.xml new file mode 100644 index 000000000..0a74f2a40 --- /dev/null +++ b/inbox/xep-slow-mode.xml @@ -0,0 +1,504 @@ + + +%ents; +]> + + +
+ MUC Slow Mode + + This specification describes a way to rate limit messages a single user can + send to a MUC room. It includes room configuration option, and how servers + and clients can handle such a feature. + + &LEGALNOTICE; + xxxx + ProtoXEP + Informational + Standards + Council + + XMPP Core + XEP-0001 + XEP-0045 + XEP-0068 + XEP-0122 + XEP-0128 + RFC6120 + + + + NOT_YET_ASSIGNED + + muc + slow mode + + + John + Livingston + contact@john-livingston.fr + john@im.yiny.org + + + 0.0.1 + 2024-02-28 + psa +

First draft.

 + +
+ +

+ There are some contexts in which you want to be able to rate limit &xep0045; + 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). +

+ + +

This document addresses the following requirements:

+ + + +
+ +
Clients
+
+ The client software used by end-users to join MUC rooms. +
+ + +
Moderator
+
+ A room role that is usually associated with room admins but that can be + granted to non-admins. +
+ + +
MUC
+
+ The multi-user chat protocol for text-based conferencing + (e.g. &xep0045;). +
+ + +
Participant
+
+ An occupant who does not have admin status; in a moderated room, + a participant is further defined as having voice (in contrast to a + visitor). + A participant has a role of "participant". +
+ + +
Role
+
+ A temporary position or privilege level within a room, distinct from a + user's long-lived affiliation with the room; the possible roles are + "moderator", "participant", and "visitor" (it is also possible to have + no defined role). A role lasts only for the duration of an occupant's + visit to a room. See &xep0045;. +
+ + +
Room administrator
+
+ A user empowered by the room owner to perform administrative functions + such as banning users; however, a room administrator is not allowed to + change the room configuration or to destroy the room. An admin has an + affiliation of "admin". See &xep0045;. +
+ + +
Room owner
+
+ Users that have special access to a room, and that can edit room + configuration. See &xep0045; - Owner Use Cases. +
+ + +
Service Discovery Extensions
+
+ See &xep0128; +
+ + +
Slow Mode
+
+ Feature allowing to rate limit user messages in a MUC room. +
+ + +
Slow Mode duration
+
+ When the Slow Mode feature is active, specifies the duration, in + seconds, users must wait between two text messages. +
+ + +
Visitor
+
+ In a moderated room, an occupant who does not have voice (in contrast to + a participant). A visitor has a role of "visitor". +
+ +
+ + +

+ 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. +

+ + + +

+ Your implementation MAY allow the Slow Mode feature to be set room by + room, by their owners. +

+

+ If room owners can configure the Slow Mode feature, the server MUST add a + 'muc#roomconfig_slow_mode_duration' field in the room + configuration form. +

+

+ This field MUST have its type equal to 'text-single'. +

+

+ This field SHOULD use + + Data Forms Validation + , having its datatype equal to 'xs:integer'. +

+

+ The 'value' of the field MUST be a positive integer, so you MUST + add a 'range' validation, as described in &xep-0122;. +

+

+ Value '0' means that the slow mode is disabled for this room. +

+

+ Any positive value is the duration, in seconds, users must wait between + two messages. +

+

+ Here is an example of response the server could send when a client is + querying + room configuration form: +

+ + + + Configuration for "coven" Room + + Complete this form to modify the + configuration of your room. + + + http://jabber.org/protocol/muc#roomconfig + + + + + + 20 + + + + + +]]> +

+ If the configuration is changed, the server SHOULD send a status code + '104', as specified in + + XEP-0045 - Notification of configuration changes + . +

+ + +

+ The feature can be enabled on a room: +

+
    +
  • + by the room owner, if your implementation allow them to set this option, +
    • +
  • by a server-wide parameter,
    • +
  • by any other criteria, specific to the room or not.
    • +
+

+ In other words: you can enable this feature, without adding the field in + the room configuration form. This allows for example server admins to + apply a rate limit server-wide, or to set the slow mode programmatically + on any wanted criteria (number of users in the room, current server load, + room context, ...). +

+

+ In any case, to allow clients to discover that the feature is active, the + server MUST respond on + + room information queries + + by adding a 'muc#roominfo_slow_mode_duration' field. + This field type MUST be 'text-single', and its value MUST be a + positive integer. +

+

+ Value '0' means that the slow mode is disabled for this room. +

+

+ Any positive value is the duration, in seconds, users must wait between + two messages. +

+

+ Any invalid (non-positive integer) value sent by the server MUST be + considered as equal to '0' (in case of a bad implementation). +

+

+ Here is an example of response the server could send when a client is + + querying room information: +

+ + + + + + + http://jabber.org/protocol/muc#roominfo + + + 20 + + + + + + +]]> +

+ If the slow mode duration has changed (either because the room configuration + was modified, or because a server parameter has changed, or any other + reason), the server SHOULD send a status code '104', as specified + in + XEP-0045 - Notification of configuration changes. +

+ + + +

+ 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 &rfc6120; stanza erors (see + + RFC6120 - stanza errors), to reject the message. Especially: +

+ +

+ Here is an example or error stanza: +

+ + + + + 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. + + + +]]> +

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

+ + +

+ 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. +

+ + +

+ 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). +

+ + +

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

+ + + +

+ &xep0068; defines a process for standardizing the fields used within Data + Forms scoped by a particular namespace, and the XMPP Registrar maintains a + registry of such FORM_TYPES (see &FORMTYPES;). + In this XEP there are two uses of such form fields: +

+
    +
  1. + Configuration of the slow mode duration using the + 'muc#roomconfig_slow_mode_duration' field. +
    2. +
  2. + Discovery of the slow mode duration using the + 'muc#roominfo_slow_mode_duration' field. +
    3. +
+

+ The registry submissions associated with these namespaces are defined + below. +

+ +

+ The registrar shall add the following field to the 'muc#roomconfig' data + form: +

+ + http://jabber.org/protocol/muc#roomconfig + XEP-XXXX + + Forms extension for slow mode support in a MUC room. + + + +]]> + + +

+ The registrar shall add the following field to the 'muc#roominfo' data + form: +

+ + http://jabber.org/protocol/muc#roominfo + XEP-XXXX + + Forms extension for slow mode support in a MUC room. + + + + ]]> + + + +