XSF Discussion - 2020-06-03

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"

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.

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

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

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

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

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.

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

but rather explicitly call complete

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.

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

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

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

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

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

Kev in Stupid Typo Shocker?

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

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

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

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

So I think your original assesment was correct.

sudo -s

-EWIN ✏

wrong window ✏

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

Thanks for checking Kev

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

Neustradamus, no, have you?

Alex: Can you explain? It is linked to slixmpp

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

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

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

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

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.

Thanks in advance dwd!

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

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

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

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.

There's already a PR for this

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

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

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

k

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

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

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

Where is the world going :(

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

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