jdev - 2023-05-17

Should "Setting someone's affiliation from 'none' to something else" be considered an affiliation change?

What's the use-case for this https://xmpp.org/extensions/xep-0045.html#example-176 (the <message/>)

What was the idea behind it

Anything to be worried about if someone discovers the address of a MUC this way by getting affiliated?

pep., affiliation "none" is a normal user joined in a non-members-only chat

if you change his affiliation to "owner"

you dont want to inform him?

affiliation "none" is the absence of affiliation, really. So that's the entire XMPP world in a non-members-only chat that isn't affiliated with the room :P

Note the <message/>, it's not a presence, the user isn't joined in this case.

yeah and if you affiliate someone, and he is not joined, the room tells him via message

because it cant via presence

i think the intention is quite clear

users which get affiliated in a room should be notified about it

Why is it a MAY and why would a room not notify though?

because its a optional feature

which is not a MUST

Thanks captain :)

My question was, is there any reason this shouldn't be implemented

that was not your question at all, if you ask me, you posted an example and asked

> What was the idea behind it

Anyway, now that's my question

if you take a guess from me, a xmpp spec should only enforce things which are essential for it to work, this thing seems not essential to MUCs working

especially in the light that "invites" also exist

though that may be not exactly the same

Yeah ok that's not what I'm asking, still, sorry. I'm wondering if there's a reason someone would be against implementing this

The implementation note says: Out of courtesy, a MUC service MAY send an out-of-room <message/> if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a <body/> element describing the affiliation change, and MUST contain a status code of 101.

this was added very early in the spec

so i would say from the word "courtesy", it was regarded as something thats not necessary at all, just a nice thing someone could do, but nothing someone should be forced to

but of course thats all guessing :) maybe you find the one who put it there

Yeah.. and no security considerations or anything it seems. The thing is I added that as a MUST in 0463, I remember there was a reason for it, but I can't remember it. I'm trying to now :x

from reading that xep, it seems not essential to inform out of room members

Yea that sounds fun security wise, I bet there exist clients you can force join to a room with an affiliation change

moparisthebest, you receive a message and trigger a very specific join presence?

this can not happen on accident

a developer wanted it that way

i dont see any problem here, even IF the client would join

i mean many client join if you send them an invite to a room automatically

thats a basic feature

i wonder though which server has implemented this out of bound notificaiton

i would like to test if Gajim acts correctly

i definitly never tested that

I guess if someone is added in affiliations it's that it's ok for them to learn the JID ✏

Yeah me neither. I learned of it when I wrote the spec, talking with people

Joining unsolicited MUCs would be a bad thing no? iirc clients should only accept invites from people on their roster at most

Otherwise it'd be great for spam and other kinds of abuse

of course, you can limit that

but if a family member opens a groupchat, i dont want to be asked if i want to join

or at least a client should offer a option where i can set auto accept

whatsapp does not ask you if you want to join for example

im not sure how it would benefit a spammer if instead of sending you the spam directly

adds you to a muc

but i guess maybe someone wants to have many people joined or something

https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ again?

Actually it'd be a kind of great way to spam

Ok, the reasoning behind sending a message for affiliation updates is so that clients don't have to poll.

I can mass invite people to a muc on some remote server, spam them, and none know my jid

If someone wants to have many people joined they can already send invites

(without looking into their server logs or XML console)

why you don't auto-accept invites from non-contacts

Yep

But I bet clients exist that take affiliation change like "oh a change for a muc, oh I'm not in that muc, better join"

Anyway a fun thing to test one day

Actually I doubt this specific feature is implemented much

moparisthebest, i bet no client does anything on that message

"oh yeah another message with payloads I don't understand"

its really a obscure feature, i dont even know which server supports it

the chance is more likely that you break a client or surface a bug with that message

because devs will not have accounted for that

funny zash that article about fractal

I'm reading logs saying prosody 0.12 possibly does

i went through the same thought process vs rooms and private chats

lovetox, it's been posted here before I'm sure :)

the author cam to the conclusion they need to separate apps

i think the "Workspace" feature does deal with that propblem rather well

in Gajim for example

probably not even the first to come to that conclusion, but they blaged it and I have in it in my browser history

oh

lovetox, are you saying per-workspace setting for whether to auto-follow invites?

what, no the article says, because they only have one side bar they dont want group chats and private chats fight for real estate

and activity sorting is useless

because mucs have much noise

to their conclusion whas, make 2 apps, one focused on private chats, one on group chats

while in Gajim we simply made workspaces, and now you can switch between your group chat workspace, and private worksapce

and we dont need two apps

I mean that it makes more sense to auto-join when you get an invite from a contact in the private chat use case, while in a work team chat app might make less sense to follow invites by default

What was the saying again? You can solve any problem by adding one more abstraction layer?

its exactly the opposite

in a work env you need to follow all invites

and thats als what MS Teams does

i heard never complain anyone about it

there is no spam in work env

It may be tricky to know it's a work env though and invites can be followed without worries? If people aren't in your contacts

either way, could it not make sense to have a setting per workspace then?

yes im not saying the idea is bad, i just talked about completely other thing

the problem is though

or should we just go back to the IRC way of having the server decide what channels you are in? :P

a workspace in Gajim does not group contacts per see

it just has open conversations

i would say a account setting is better

this is my work account, so accept all invites

this is my private, so dont

but i think the "contact is in my roster" is also good enough

Oops wrong room

Sorry 😅

So having the registered FTTH SFP module inclusive of VLAN and PPPoE parameters and a thing with 12 SFP ports is there a reason to not just bypass the ISP CPE...? 🤔

Wrong message order?

Brought to you by eventual consistency?

fwiw, I figured out that <message/> affiliation update thing.

And I have an update coming for 463. > The introduction of a MUST on &MESSAGE; updates is necessary to ensure an observer (joined in the room) sees affiliation updates for offline users too, as these don't have any presence and thus their affiliation change wouldn't be broadcasted otherwise.

It's not meant to notify users outside the room

(Took me some time to figure out again)