21 Nov
2024
21 Nov
'24
9:01 a.m.
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.
21 Nov
21 Nov
9:12 a.m.
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.
9:16 a.m.
"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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
22 Nov
22 Nov
2 a.m.
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
7:19 a.m.
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.
7:28 a.m.
On 22/11/2024 16:19, Stephen Paul Weber wrote:
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.)
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.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7:33 a.m.
Le 22/11/2024 à 15:28, msavoritias a écrit :
On 22/11/2024 16:19, Stephen Paul Weber wrote:
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
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.
7:34 a.m.
Somebody claiming to be msavoritias wrote:
On 22/11/2024 16:19, Stephen Paul Weber wrote:
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)
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. 
26 Nov
26 Nov
1:37 p.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)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
3 Dec
3 Dec
3:43 a.m.
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
28 Nov
28 Nov
2:01 a.m.
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(a)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.
2:09 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
1
days inactive
13
days old
11 comments
6 participants
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
John Livingston -
msavoritias -
Stephen Paul Weber