XSF Discussion - 2024-02-23


  1. 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?

  2. Guus

    Ah, it's "Xfinity Mobile Protection Plan" https://www.xfinity.com/mobile/support/article/protection-plan-details

  3. Guus

    Hehe, to further confuse things: "XMPP is administered by The Signal"

  4. Seve

    What the... 😂️

  5. 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 :)

  6. John Livingston

    (i have a working implementation as a Prosody module, that will be proposed to prosody-module once i submit the XEP)

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

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

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

  10. Kev

    You caps COULD as if it was a 2119 keyword, but it isn't.

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

  12. Kev

    Did you mean MAY, perhaps?

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

  14. John Livingston

    right

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

  16. Kev

    I think that's all my feedback for a first pass. Thanks for working on this :)

  17. 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?

  18. singpolyma

    Mayve even should wait for the echo

  19. singpolyma

    Guus: non anon maybe?

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

  21. Zash

    John Livingston, https://xmpp.org/extensions/xep-0122.html

  22. John Livingston

    > I think that's all my feedback for a first pass. Thanks for working on this :) thank you so much!!

  23. Guus

    spec says to only act on 'body' elements - are those guaranteed to be present when using omemo?

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

  25. John Livingston

    > John Livingston, https://xmpp.org/extensions/xep-0122.html thanks! i missed the <min> tag, i'll add this

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

  27. 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> ```

  28. mathieui

    (Guaranteeing a common ordering of messages)

  29. 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?

  30. Zash

    John Livingston, excellent question, possibly deserving a XEP of its own :)

  31. John Livingston

    haha

  32. Zash

    https://xmpp.org/extensions/xep-0226.html is the closest we have

  33. 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 :) )

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

  35. Zash

    It's a hard question and it only gets harder. Other than chat states, consider reactions.

  36. Zash

    Should you be able to send another message after someone reacts to your message?

  37. Kev

    It comes down to asking why you want it to be slow, I think.

  38. Zash

    I'm sure there's other payloads that further complicating thigs

  39. Kev

    And the answer depends on that :)

  40. Guus

    Kev, that' reduce functionality though. I want my typing notification. :)

  41. Kev

    > , that' reduce functionality though. I want my typing notification. :) Sure, and I want to be not rate limited :)

  42. 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 ^^'

  43. John Livingston

    > Should you be able to send another message after someone reacts to your message? good point...

  44. Guus

    John, maybe be a bit handwavey and spec that servers must only count sensible stanzas...

  45. Guus ducks, runs.

  46. singpolyma

    Only stanzas that the server will store in mam

  47. Guus

    being handwavey by proxy, you mean? :)

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

  49. John Livingston

    here is my prosody implementation: https://github.com/JohnXLivingston/peertube-plugin-livechat/tree/main/prosody-modules/mod_muc_slow_mode

  50. singpolyma

    > being handwavey by proxy, you mean? :) It's a good proxy

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

  52. John Livingston

    This commit fix points mentionned by Kef: https://github.com/JohnXLivingston/peertube-plugin-livechat/commit/1ac1b24e65ec5d853f4181eecb3e060f1e608d43

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

  54. Guus

    is it worth warning about taking into account Multi-Session nicknames?

  55. pep.

    Probably? Yes please? :)

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

  57. pep.

    Never too obvious for a spec I would say

  58. pep.

    Add that to security considerations or something

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

  60. 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?

  61. John Livingston

    "bare JID"?

  62. John Livingston

    Something like: the server MUST use the bare JID has a key to identify users.

  63. Zash

    participant?

  64. Kev

    Occupant, not participant ;)

  65. Zash

    words

  66. Zash

    too many of them

  67. John Livingston

    > participant? oh, this make me think... i forgot to tell to ignore moderators

  68. Guus

    Or, like pep. suggested, mention in security considerations that using multi-session nicks should not circumvent things.

  69. Zash

    Bypassing it by using separate occupants seems meh too

  70. John Livingston

    > participant? oh, this make me think... i forgot to tell to ignore moderators (server MAY not apply any rate limiting to moderators)

  71. Zash

    So, bare jid isn't a bad idea, but may complicate implementation

  72. Guus

    complicate it how?

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

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

  75. Zash

    Does generic rate limiting need a XEP? We've had stuff for Prosody for ages without a XEP.

  76. Zash

    Internal service policy something something

  77. John Livingston

    Guus: seems to complicated to explain to end user for me.

  78. Guus

    Openfire doesn't. I blame the lack of a XEP. :)

  79. Guus

    John, that's fair.

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

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

  82. Guus

    exclude/allow

  83. Guus

    wow, I'm ready for the weekend.

  84. John Livingston

    Another point that could be included: specify roles that are not rate limited. But i'm not ready to work on this.

  85. John Livingston

    i will stick on my implementation for now

  86. John Livingston

    Just published a new version, with missing parts (ignore moderators, security consideration, ...). Thanks again for your help, so precious!

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

  88. emus

    FYI https://github.com/ietf-wg-mimi