-
Guus
It may not have anything to do with our networking protocol, but does anyone know what "XMPP Attach Rate Trends" from the job description in https://www.linkedin.com/jobs/view/3836666026 means?
-
Guus
Ah, it's "Xfinity Mobile Protection Plan" https://www.xfinity.com/mobile/support/article/protection-plan-details
-
Guus
Hehe, to further confuse things: "XMPP is administered by The Signal"
-
Seve
What the... đď¸
-
John Livingston
Hello everybody. Let me quickly introduce myself. John Livingston, FOSS dev. I'm working on the chat system for Peertube, a streaming FOSS software (to provide chatting features for lives, like on twitch for example). I - of course - use XMPP (Prosody + ConverseJS to be exact). For such streaming platforms, there is a very useful feature, called the "Slow Mode". As far as i know, there is no XEP to describe this feature. So⌠I made a draft. Here it is: https://johnxlivingston.github.io/peertube-plugin-livechat/technical/slow_mode/ This is not submitted yet. As it is my first one, i'd like to have some people to have a look, and tell me if there are mispelling, misconception, or things to clarify. (I know i have some things to cleanup, to be fully compliant with the XEP standards.). Feel free to comment :)
-
John Livingston
(i have a working implementation as a Prosody module, that will be proposed to prosody-module once i submit the XEP)
-
Kev
> Any invalid value MUST be considered as equal to 0. Is a bit odd - it means that the server can't reject an invalid form, which seems the better option?
-
Kev
> When the Slow Mode is enabled, server MUST NOT accept two consecutive messages from the same user, to the same room Is that really what you want? That a user can't send two messages, hours apart, unless someone else sent one in between? And it doesn't care about duration? I think you meant to say two messages within the rate limiting period.
-
John Livingston
> Is a bit odd - it means that the server can't reject an invalid form, which seems the better option? I meant if the server implementation accept incorrect value. You are right, i will change that.
-
Kev
You caps COULD as if it was a 2119 keyword, but it isn't.
-
John Livingston
> Is that really what you want? That a user can't send two messages, hours apart, unless someone else sent one in between? And it doesn't care about duration? I think you meant to say two messages within the rate limiting period. Right! i'll fix it
-
Kev
Did you mean MAY, perhaps?
-
Kev
> If the muc#roomconfig_slow_mode_duration field is present in room configuration form (as described in â4.1 Activating Slow Mode in the MUC Room configurationâ), the client SHOULD add an input field when the roomâs owner modifies the room configuration. This field SHOULD only accept positive integer as value (0 included, which means the feature is disabled). I think this isn't needed, as it's covered by standard MUC config stuff once you've got the field in the form (unless I'm missing something)
-
John Livingston
right
-
Kev
> To avoid some frustrating behaviour, in case there is some lag on the server for example, the client SHOULD prevent sending new messages for a slightly longer duration, than the slow mode duration (for example by adding 100 or 200ms). 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. I'm not sure this really needs to be a SHOULD, I'd weaken it to a MAY, as for example the client could also wait for the echo to start the timer, which is more reliable.
-
Kev
I think that's all my feedback for a first pass. Thanks for working on this :)
-
Guus
is there precedent for having a room_config_ option and a room_info_ option of otherwise the same name, that flags the optionally configured setting?
-
singpolyma
Mayve even should wait for the echo
-
singpolyma
Guus: non anon maybe?
-
John Livingston
> > If the muc#roomconfig_slow_mode_duration field is present in room configuration form (as described in â4.1 Activating Slow Mode in the MUC Room configurationâ), the client SHOULD add an input field when the roomâs owner modifies the room configuration. This field SHOULD only accept positive integer as value (0 included, which means the feature is disabled). > > I think this isn't needed, as it's covered by standard MUC config stuff once you've got the field in the form (unless I'm missing something) Hum, is there any standard to limit a field to a positive value? Execpt that point, you are right, everthing is in MUC config standard.
-
Zash
John Livingston, https://xmpp.org/extensions/xep-0122.html
-
John Livingston
> I think that's all my feedback for a first pass. Thanks for working on this :) thank you so much!!
-
Guus
spec says to only act on 'body' elements - are those guaranteed to be present when using omemo?
-
John Livingston
> Mayve even should wait for the echo i think i have still many things to learn on XMPP, i did not know there was an echo
-
John Livingston
> John Livingston, https://xmpp.org/extensions/xep-0122.html thanks! i missed the <min> tag, i'll add this
-
mathieui
John Livingston: in MUCs, you know your message was delivered because you get it back at the same time as the other participants receive it
-
Zash
```lua util.dataforms.new{ {type="text-single",datatype="xs:integer", range_min=1} }:form():indent() ``` â ```xml <x xmlns='jabber:x:data' type='form'> <field type='text-single'> <validate xmlns='http://jabber.org/protocol/xdata-validate' datatype='xs:integer'> <range min='1'/> </validate> </field> </x> ```
-
mathieui
(Guaranteeing a common ordering of messages)
-
John Livingston
> spec says to only act on 'body' elements - are those guaranteed to be present when using omemo? i don't know. What is the good way to filter chatstate messages, and only keep real message, with content?
-
Zash
John Livingston, excellent question, possibly deserving a XEP of its own :)
-
John Livingston
haha
-
Zash
https://xmpp.org/extensions/xep-0226.html is the closest we have
-
John Livingston
(i know i already said this many time, but let me say it again: <3 to the XMPP community, you are so kind and helpful :) )
-
Kev
I'd have thought it might be most sensible to not exclude any messages, but simply say not to use chat states in slow rooms.
-
Zash
It's a hard question and it only gets harder. Other than chat states, consider reactions.
-
Zash
Should you be able to send another message after someone reacts to your message?
-
Kev
It comes down to asking why you want it to be slow, I think.
-
Zash
I'm sure there's other payloads that further complicating thigs
-
Kev
And the answer depends on that :)
-
Guus
Kev, that' reduce functionality though. I want my typing notification. :)
-
Kev
> , that' reduce functionality though. I want my typing notification. :) Sure, and I want to be not rate limited :)
-
John Livingston
> I'd have thought it might be most sensible to not exclude any messages, but simply say not to use chat states in slow rooms. That was my first implementation... But... Then i tested with a Gajim client, which was sending chatstates anyway... So... I started typing a message, and got rate limited before even sending it ^^'
-
John Livingston
> Should you be able to send another message after someone reacts to your message? good point...
-
Guus
John, maybe be a bit handwavey and spec that servers must only count sensible stanzas...
- Guus ducks, runs.
-
singpolyma
Only stanzas that the server will store in mam
-
Guus
being handwavey by proxy, you mean? :)
-
John Livingston
I'm not familiar enought with XMPP to fully understand what would be the right criteria. If you have any suggestion, by my guest.
-
John Livingston
here is my prosody implementation: https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/prosody-modules/mod_muc_slow_mode
-
singpolyma
> being handwavey by proxy, you mean? :) It's a good proxy ↺
-
Guus
John, I think we're nearing the point where we're arguing what color the bikeshed should be. The spec as is seems sensible enough for you to submit it, and have further discussions in the regular XEP acceptance process.
-
John Livingston
This commit fix points mentionned by Kef: https://github.com/JohnXLivingston/peertube-plugin-livechat/commit/1ac1b24e65ec5d853f4181eecb3e060f1e608d43
-
John Livingston
Guus: thanks. As english is not my native language, i will just wait for some friend to read it, to detect any mispelling
-
Guus
is it worth warning about taking into account Multi-Session nicknames?
-
pep.
Probably? Yes please? :)
-
Guus
a user could join the same MUC, using the same nickname, with different clients. You'd want the slow-delay to be applied to all of them, to prevent that to be a circumvention. Might be obvious enough to not include it though.
-
pep.
Never too obvious for a spec I would say
-
pep.
Add that to security considerations or something
-
Guus
John's plugin implementation seems to guard for that: https://github.com/JohnXLivingston/peertube-plugin-livechat/blob/main/prosody-modules/mod_muc_slow_mode/mod_muc_slow_mode.lua#L106
-
John Livingston
> a user could join the same MUC, using the same nickname, with different clients. You'd want the slow-delay to be applied to all of them, to prevent that to be a circumvention. Might be obvious enough to not include it though. Right! what is the good terminology to use?
-
John Livingston
"bare JID"?
-
John Livingston
Something like: the server MUST use the bare JID has a key to identify users.
-
Zash
participant?
-
Kev
Occupant, not participant ;)
-
Zash
words
-
Zash
too many of them
-
John Livingston
> participant? oh, this make me think... i forgot to tell to ignore moderators✎ -
Guus
Or, like pep. suggested, mention in security considerations that using multi-session nicks should not circumvent things.
-
Zash
Bypassing it by using separate occupants seems meh too
-
John Livingston
> participant? oh, this make me think... i forgot to tell to ignore moderators (server MAY not apply any rate limiting to moderators) ✏
-
Zash
So, bare jid isn't a bad idea, but may complicate implementation
-
Guus
complicate it how?
-
Guus
John: have you considered making the XEP allow for more complex rules, like 'not more than X messages in Y duration' ? I'm not sure if that's functionally an improvement, but I was wondering if it's worth considering.
-
Guus
(instead of having 1 message per 2 seconds, 2 seconds per 4 might also be ... fine (and allow for a quick correction of the last message)? I'm unsure how this plays out in the real world though.
-
Zash
Does generic rate limiting need a XEP? We've had stuff for Prosody for ages without a XEP.
-
Zash
Internal service policy something something
-
John Livingston
Guus: seems to complicated to explain to end user for me.
-
Guus
Openfire doesn't. I blame the lack of a XEP. :)
-
Guus
John, that's fair.
-
John Livingston
I think we have to stick to something very simple. Ok, this room has huge activity? (because, as in my use case, viewers are commenting a live?). So, make it readable by setting a simple limit.
-
Guus
well, allowing for X in Y does not exclude that. You could still say 'exclude 1 in 2 seconds'. But by defining it like this in the XEP, you might gain a bit of flexibility. I'm not sure if it's worth the additional complexibility (but that seems ... light)
-
Guus
exclude/allow
-
Guus
wow, I'm ready for the weekend.
-
John Livingston
Another point that could be included: specify roles that are not rate limited. But i'm not ready to work on this.
-
John Livingston
i will stick on my implementation for now
-
John Livingston
Just published a new version, with missing parts (ignore moderators, security consideration, ...). Thanks again for your help, so precious!
-
singpolyma
If what affiliations to ignore and if to limit just mam messages or everything were both options it would cover both slow mode and mod_muc_limits I think. I guess burst factor too
-
emus
FYI https://github.com/ietf-wg-mimi