Proposed XMPP Extension: MUC Slow Mode
The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC Slow Mode Abstract: 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. URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
A rate limit configuration field, but with no support for burst, etc, and the spec even explicitly says you must not allow bursts? Shouldn't that be configurable if we're making new configuration fields? I would suggest to check this existing implementation https://modules.prosody.im/mod_muc_limits.html for the kinds of things that one might want to be able to configure.
"The enemy of the good XEP is the dream of the perfect one". I think this is a great start point. I was more concerned with the lack of an application specific error element, but that can be sorted in Experimental too. On Thu, 21 Nov 2024 at 16:12, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
A rate limit configuration field, but with no support for burst, etc, and the spec even explicitly says you must not allow bursts? Shouldn't that be configurable if we're making new configuration fields?
I would suggest to check this existing implementation https://modules.prosody.im/mod_muc_limits.html for the kinds of things that one might want to be able to configure. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Le 21/11/2024 à 17:12, Stephen Paul Weber a écrit :
A rate limit configuration field, but with no support for burst, etc, and the spec even explicitly says you must not allow bursts? Shouldn't that be configurable if we're making new configuration fields?
I would suggest to check this existing implementation https:// modules.prosody.im/mod_muc_limits.html for the kinds of things that one might want to be able to configure.
Hello, Maybe that was unclear, but they are many differences between my slow mode XEP, and what mod_muc_limits can do. TL;DR: See https://xmpp.org/extensions/inbox/xep-slow-mode.html#usecases I'm using an implementation of this XEP to provide a chat in Peertube live streams. This provide a slow mode similar to the one existing on Twitch for example. Here are some differences: * mod_muc_limits is configurable by server admins, slow mode is configurable by MUC owners * slow mode is configurable room by room, mod_muc_limits is server wide * slow mode parameter can be changed in live, without any server reload * slow mode limits the number of text message user by user, mod_muc_limits limits all kind of messages * ... So, there is no need for burst parameters. As the limitation is user by user. If you want a demo, i have set a slow mode of 2 seconds here: https://videos.john-livingston.fr/w/qqNQwFDerUB1KnFA6N6Jbi (in real life situations, it would more be something like 30 seconds) You can join the same test room with your XMPP client here: xmpp:c5d20adf-1088-4d40-bbfc-1abb42d20b05@room.videos.john-livingston.fr?join -- John
So, there is no need for burst parameters. As the limitation is user by user.
I don't think this follows. Users often will send for example two messages right in a row which are effectively one message. An admin may wish to allow this kind of short burst even for per-jid limits. There's also a question of if this should interact with affiliation. Perhaps a setting to allow admins to exempt members from the rate limit.
On 22/11/2024 16:19, Stephen Paul Weber wrote:
So, there is no need for burst parameters. As the limitation is user by user.
I don't think this follows. Users often will send for example two messages right in a row which are effectively one message. An admin may wish to allow this kind of short burst even for per-jid limits.
If this is intended to be used in streaming and models Twitch and the likes, no. There is no burst functionality. One reasoning I could think is that it is easy to game the system around burst. And making slow mode as simple as possible makes the attack surface smaller. (stuff like this has been extensively tested by streamers during hate raids, spam attacks and the likes.)
There's also a question of if this should interact with affiliation. Perhaps a setting to allow admins to exempt members from the rate limit.
For context this is not what happens currently in any other streaming platform afaik. Twitch, Youtube, etc. When you slow down the chat, you slow down everybody. I imagine not slowing down members is not useful in this situation also because there may be thousands of members.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Le 22/11/2024 à 15:28, msavoritias a écrit :
On 22/11/2024 16:19, Stephen Paul Weber wrote:
There's also a question of if this should interact with affiliation. Perhaps a setting to allow admins to exempt members from the rate limit.
For context this is not what happens currently in any other streaming platform afaik.
Twitch, Youtube, etc.
When you slow down the chat, you slow down everybody. I imagine not slowing down members is not useful in this situation also because there may be thousands of members.
Some Twitch channel can define "VIP" users, that are not subject to certain rules. I thinks VIP are not affected by the slow mode. Such option seems a good idea. (the member affiliation could be used as an equivalent to the VIP status) -- John
Somebody claiming to be msavoritias wrote:
On 22/11/2024 16:19, Stephen Paul Weber wrote:
So, there is no need for burst parameters. As the limitation is user by user.
I don't think this follows. Users often will send for example two messages right in a row which are effectively one message. An admin may wish to allow this kind of short burst even for per-jid limits.
If this is intended to be used in streaming and models Twitch and the likes, no. There is no burst functionality.
Sure but we're talking about standardizing configuration fields for MUC rate limits. It shouldn't just be as simple as "this is the feature twitch has". Of course that use case should e considered, but so should others (such as the antispam / antiflood use case)
Le jeudi 21 novembre 2024, 17:01:12 heure normale d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Slow Mode Abstract: 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.
URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hello, thank you for your contribution! This is a useful feature and we can appreciate the effort put in this protoXEP. I've a few small remarks regarding this specification: - Glossary redefines many terms from XEP-0045. There is no need for that, it makes the specification more difficult to read, and it duplicates information. Just add a note to reference XEP-0045. - In https://xmpp.org/extensions/inbox/xep-slow-mode.html#example-1 there is a confusion between label and description. Label should be a simple "Slow Mode", and <desc> should be used for the description (cf. https://xmpp.org/ extensions/xep-0004.html#protocol-field). It's just an example, but if developer copy it, it will result in bad UX for end-users. - The topic "Client Handling" is missing an anchor, resulting in ugly URL such as https://xmpp.org/extensions/inbox/xep-slow-mode.html#sect-idm46190554600112 . - At https://xmpp.org/extensions/inbox/xep-slow-mode.html#sect-idm46190554660208 (anchor is missing here too), those 2 lines contradict themselves:
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 Data Forms Validation (XEP-0122) [3].
You say that Data Forms Validation is a "SHOULD", but below that you "MUST" add a "range" validation. You need either 2 SHOULD or 2 MUST. - In the same section the link to "client-discovering" is incorrect and results in a 404. Best, Goffi
Le 26/11/2024 à 21:37, Goffi a écrit :
Hello,
thank you for your contribution! This is a useful feature and we can appreciate the effort put in this protoXEP.
Thanks a lot! I made a PR with the requested modifications: https://github.com/xsf/xeps/pull/1404 Some notes beneath:
- Glossary redefines many terms from XEP-0045. There is no need for that, it makes the specification more difficult to read, and it duplicates information. Just add a note to reference XEP-0045.
I added a paragraph in the Glossary section, saying:
Many terms used in this XEP are defined in &xep0045; and &xep0128;. Please refer to these XEP for more informations. Is this correct? Or is this redundant with the <dependencies> section?
- In https://xmpp.org/extensions/inbox/xep-slow-mode.html#example-1 there is a confusion between label and description. Label should be a simple "Slow Mode", and <desc> should be used for the description (cf. https://xmpp.org/ extensions/xep-0004.html#protocol-field). It's just an example, but if developer copy it, it will result in bad UX for end-users.
Right. I tested it so in my first implementation, but it did not work at the time... It was ConverseJS that was ignoring the <desc> child node. This was fixed in ConverseJS, but i forgot to change my implementation (and the xep). Thanks! Other points were fixed. -- John
Hello Le mardi 3 décembre 2024, 11:43:08 heure normale d’Europe centrale John Livingston a écrit :
I made a PR with the requested modifications: https://github.com/xsf/xeps/pull/1404 [SNIP]
Other points were fixed.
That looks good. Thank you for taking my feedback into account. Best, Goffi
Hi John, congrats on your first XEP and for managing to get XEP number 500! https://xmpp.org/extensions/xep-0500.html There has already been some feedback wrt error elements and the specifics on the form field. Please try to incorporate the feedback. You can create PRs against the xep-0500.xml in the repo and the Editor will merge them ASAP. cheers Daniel On Thu, Nov 21, 2024 at 5:01 PM Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Slow Mode Abstract: 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.
URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Hello Daniel, I saw the feedbacks (and the discussion during the XMPP council). I will incorporate them next week! Thanks a lot. John Le 28/11/2024 à 10:01, Daniel Gultsch a écrit :
Hi John,
congrats on your first XEP and for managing to get XEP number 500!
https://xmpp.org/extensions/xep-0500.html
There has already been some feedback wrt error elements and the specifics on the form field.
Please try to incorporate the feedback. You can create PRs against the xep-0500.xml in the repo and the Editor will merge them ASAP.
cheers Daniel
On Thu, Nov 21, 2024 at 5:01 PM Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC Slow Mode Abstract: 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.
URL: https://xmpp.org/extensions/inbox/xep-slow-mode.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
John Livingston -
msavoritias -
Stephen Paul Weber