XSF Discussion - 2020-06-03


  1. Guus

    With FMUC, it seems desirable to be able to establish federation between nodes out of the context of an occupant that joins the room, for example when an administrator configures FMUC for a pre-existing room, or when network connectivity recovered causing a previous federation to be "re-established"

  2. Guus

    The act of establishing federation as described in the XEP is triggered by the event of an occupant joining a room. The XEP is not overly clear on how federation is established for a pre-existing room.

  3. Guus

    what's the best approach here? Simulate a join using a random occupant?

  4. Guus nudges Kev

  5. Kev

    Yep, you can just pick someone to be the first user.

  6. Guus

    ok, thanks. Not very elegant, but it'll do, I guess.

  7. jonas’

    from council@, we were discussing PR#591 and the XEP-0050 'execute' problem

  8. jonas’

    pasting some logs from there, you can read for yourself, too: https://logs.xmpp.org/council/2020-06-03#2020-06-03-04158e5cf65364df 15:28:47 jonas’> flow, at a first glance, 591 has multiple problems: - It defines previously undefined behaviour, making implementations which were previously neutral non-compliant - It does not solve the issue for when neither next nor complete are allowed.

  9. jonas’

    flow, for later: the key difference between 591 and 598 in my eyes (and why I prefer 598) is for "clients" of the Ad-Hoc protocol: With 591, clients could, theoretically, start to rely on execute = complete if and only if next is not allowed. If they talk to an old implementation, that implementation will do whatever instead. In case of 598, a new client will see "ah, so that’s an invalid state" (ideally + wording that it was UB before) and will avoid using execute in that situation

  10. jonas’

    but rather explicitly call complete

  11. jonas’

    so both PRs do indeed make implementations non-compliant, but I think 598 is slightly better since it doesn’t "promise" behaviour to clients which existing servers may not provide.

  12. Zash

    An observation: All ad-hoc commands provided by Prosody are 1-step commands, and the 'action' is basically ignored since there's never any previous step and 'next' completes the command, so it's redundant with 'complete'.

  13. Zash

    Well. I think there's one or two 0-step commands.

  14. Zash

    So, I wonder about what the distribution of step-lengths in the wild might be.

  15. Guus

    FMUC exampel 9 (https://xmpp.org/extensions/xep-0289.html#example-9) lists 5 presence stanzas, to illustrate how a 'leave' presence fans out. Am I correct that the 'to' address of the fourth stanza is not correct? I am specifically looking at the resource (nickname). I think that should be the nickname of the user that is leaving, instead of the nickname of the intended recipient of the presence (elsinore@talk.denmark.lit/Hatter instead of elsinore@talk.denmark.lit/Hamlet).

  16. Guus

    I think that would correspond with the 'join' example above.

  17. Kev

    Kev in Stupid Typo Shocker?

  18. Guus

    well, things get complicated fast, and I'm known to not interpret things correctly.

  19. Guus

    So a confirmation that this indeed is a stupid typo would be welcome. 🙂

  20. Kev

    I'm not immediately 100% sure that's wrong, hang on.

  21. Kev

    I've checked M-Link. We iterate across the remote rooms, create a JID by appending the resource of the 'from' JID to the bare JID of the remote room, and use that as the 'to'.

  22. Kev

    So I think your original assesment was correct.

  23. jonas’

    sudo -s

  24. jonas’

    cd

  25. jonas’

    -EWIN

  26. jonas’

    wrong window

  27. Guus

    My reasoning is that you would not want to address each individual occupant on the remote node

  28. Guus

    Thanks for checking Kev

  29. Neustradamus

    Link Mauve and pep.: Have you looked for Alex memberbot problem?

  30. pep.

    Neustradamus, no, have you?

  31. Neustradamus

    Alex: Can you explain? It is linked to slixmpp

  32. pep.

    So what? Because I contribute to a project that uses slixmpp I don't have a choice but to fix everybody's slixmpp bots?

  33. pep.

    I have looked in the past, I don't even manage to make the thing run on my machine, for different reasons than Alex.. so there's that

  34. Alex

    I have left a comment here on the PR: https://github.com/xsf/memberbot/pull/2 The code on master does not work anymore. Lance's original code works fine, but is using sleek and python 2

  35. Alex

    I can add instructions on how to run the code. It's super simple. Only requires 2 jids, and the voter jid must be in the roster file

  36. dwd

    Alex, I'll take a look once I'm slightly less busy. Feel free to nag me if I don't seem to get around to it.

  37. Neustradamus

    Thanks in advance dwd!

  38. dwd

    I think I might make it use pipenv as a first step.

  39. dwd

    Alex, Cloned and running in pipenv. Easy enough. Nudge me when you're around and we can discuss what's needed.

  40. Neustradamus

    dwd: I have informed about the problem of "no" which is transformed in "No" in my client, my client has a function: automatically capitalize the first letter. There is no problem with "yes", no change, it is always "yes".

  41. dwd

    Got it. Seems trivial to fix, I'll do so and make up a PR. I should probably lint this too, looks a little rough in places.

  42. pep.

    There's already a PR for this

  43. dwd

    pep., Where? I see a vcard one and the requirements.txt one.

  44. pep.

    https://github.com/xsf/memberbot/commits/master ah it's been merged

  45. dwd

    Ah, so there's cases I can see that haven't been fixed.

  46. pep.

    k

  47. Neustradamus

    But when we click on "no" it is always "No", when we click on "yes" it is "yes"

  48. dwd

    Bug fixed, PEP8 applied, linted, pipenv. Properly test it in the morning, then PR. Do we want it dockerized while I'm at it?

  49. pep.

    it's supposed to be a simple python script :/

  50. pep.

    Where is the world going :(

  51. dwd

    I run a lot of Python scripts, many of them much simpler than this. I always run them in pipenv and usually docker.

  52. dwd

    I think pipenv makes things simpler. Docker makes deploying things simpler, but I don't know if the XSF/Alex needs it.