From fec00803e0ea6f0f0ab56dd3052402eb3b8dc0d4 Mon Sep 17 00:00:00 2001 From: John Livingston Date: Wed, 28 Feb 2024 15:38:56 +0100 Subject: [PATCH 1/3] first xep draft. --- xep-slow-mode.xml | 499 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 499 insertions(+) create mode 100644 xep-slow-mode.xml diff --git a/xep-slow-mode.xml b/xep-slow-mode.xml new file mode 100644 index 000000000..2ffd31d2f --- /dev/null +++ b/xep-slow-mode.xml @@ -0,0 +1,499 @@ + + +%ents; +]> + + +
+ MUC Slow Mode + + This specification describes a way to rate limit messages a single user can + send to a MUC room, from the room configuration to the server and client + handling of 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). +

+ + +

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

+ If the slow mode duration has changed (either because the room configuration + was modified, or because a server parameter has changed), 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), 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: +

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

+ 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. + + + + ]]> + + + + From 79541c0b512a53ba4611ca6da10742bef7b755ac Mon Sep 17 00:00:00 2001 From: John Livingston Date: Wed, 28 Feb 2024 17:51:17 +0100 Subject: [PATCH 2/3] minor corrections. --- xep-slow-mode.xml | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/xep-slow-mode.xml b/xep-slow-mode.xml index 2ffd31d2f..0a74f2a40 100644 --- a/xep-slow-mode.xml +++ b/xep-slow-mode.xml @@ -9,8 +9,8 @@ MUC Slow Mode This specification describes a way to rate limit messages a single user can - send to a MUC room, from the room configuration to the server and client - handling of such a feature. + send to a MUC room. It includes room configuration option, and how servers + and clients can handle such a feature. &LEGALNOTICE; xxxx @@ -58,7 +58,8 @@ 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). + messages without waiting the delay to be over, and displaying some + information to them).

@@ -106,7 +107,8 @@
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 is further defined as having voice (in contrast to a + visitor). A participant has a role of "participant".
@@ -206,7 +208,7 @@

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

http://jabber.org/protocol/muc#roominfo - 2 + 20 @@ -318,9 +320,9 @@ ]]>

If the slow mode duration has changed (either because the room configuration - was modified, or because a server parameter has changed), the server SHOULD - send a status code '104', as specified in - + 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.

@@ -343,7 +345,7 @@ If a user bypass the limit, the server MUST reply an error stanza, that respects &rfc6120; stanza erors (see - RFC6120 - stanza errors), especially: + RFC6120 - stanza errors), to reject the message. Especially:

  • @@ -384,6 +386,9 @@ ]]> +

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

    @@ -403,8 +408,8 @@ 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. + 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 From 45b62e47c93c77732a712542474572b25c39a485 Mon Sep 17 00:00:00 2001 From: John Livingston Date: Wed, 13 Nov 2024 18:34:25 +0100 Subject: [PATCH 3/3] Fix file location: move xep-slow-mode.xml in the inbox directory. --- xep-slow-mode.xml => inbox/xep-slow-mode.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename xep-slow-mode.xml => inbox/xep-slow-mode.xml (100%) diff --git a/xep-slow-mode.xml b/inbox/xep-slow-mode.xml similarity index 100% rename from xep-slow-mode.xml rename to inbox/xep-slow-mode.xml