XSF Discussion - 2018-07-10

Should a MUC room require a password for affiliated JIDs?

XEP-0045 is silent on the matter as far as I can tell

I'd say yes, for consistency reasons.

But then again... 🤔

I think xep45 should be inconsistent, for consistency reasons.

well played

and another case I just hit... if a password is supplied but the room isn't password-protected...? :)

is that due to process consistency, or due to consistency process?

MattJ, uh... ignore?

Ge0rG: Not sure, but I think so.

MattJ: I'd say: if the joining user is admin/owner, the room should be updated to use the password, otherwise, the user join be rejected.

What if a password is given in the room creation stanza?

</s>

MattJ: There's an argument for rejecting, I think.

If the security properties of the room have changed unexpectedly.

That's what Prosody currently does, it seems

This is the kind of argument that we owe proxy JIDs to.

But it doesn't seem very useful (or requiring a password for owner/admin/member)

Yeah, I can see how it might be useful to let the admins in without a password.

Or at least owners.

if the owner wants to exclude admins, they should remove them from the affiliation list first?

Fair.

maybe we should deprecate passwords for the sake of explicit affiliation management and namespace-bump?

No thanks

I just used passwords for something

for whatthing?

namespace-bump XEP-0045.

jonasw, good idea

can we tempban Ge0rG from all MUCs for this day? he’s trolling too much :)

Ge0rG, a system where you invite one JID, but a different JID will join

So I made a module that injects an invite token into the outgoing invite's password field, and validates the token provided as the password of the joining user

uhhh

I’m interested

I want MUC invites

to members only MUCs

jonasw: I was just going to say that this isn't possible due to the federated nature of XMPP, but then I realized that there is a person in this MUC who could disable my access to yax.im and firewall me off.

in onboarding

MattJ: that's... interesting.

MattJ: but please use PARS instead.

I mean, technically you could just have per-user "passwords" for a MUC, but it feels wrong.

It's a hack.

Actually, I like it.

:D

reminds me that I need to try my per-device password SASL authcid hack

Ge0rG, PARS isn't suitable here, the invite is accepted by a machine

MattJ, what’s wrong with that?

MattJ: use the PARS wire format to pass tokens along.

Ge0rG, so you mean use a <preauth> element instead of a <password> element?

MattJ: essentially yes, also you could use the URI parameter to carry such invitations via HTTPS

Maybe in a future version

The nice things about passwords is that all the code I was dealing with already supported them

(except in reality each component had a bug, such as looking for or putting the password in the wrong place in the stanza)

Turns out it's not a child of the <invite> element

MattJ: you could change the server to use the pars token as the primary mechanism but to allow passing the token in the password field

yeah, invitations with passwords are funny.

nobody is checking corner cases

I'm trying to implement tombstones for MUC. How am I supposed to signal that?

Isn't it in XEP-0045?

Not really

Not that I could see at least.

Oh, you mean signal that the service implements tombstones?

To signal that, when joining/creating a room, that it's already been destroyed.

Hm, this seems to work with Gajim

Just needed to not reply with weird <messages>