jdev - 2024-06-11

will i break much if i dont send presence with from my client when joining a groupchat and i dont send the list of participants?

with MUC XEP i mean

or does that break some fundamental assumptions?

MSavoritias (fae,ve), yes, the join operation is triggered by said presence.

ah well then

i was hoping i could just "subscribe" to recieve messages from the node distributing said messages to me, without having to send presense or know who the other participants are by getting the membership

but maybe i am describing a whole different architecture at this point

to be exact my problem is sending presence to everybody. which seems inneficient. plus probably periodically pinging the room.

MSavoritias (fae,ve): that's MUC no way around that.

ah... like i would have hoped to use it in a way. because compatibility and such and MUX is coming(tm) :)

hence all my questions. also i have been told MUC is still good we dont need MIX

You can already have presenceless MUCs, indeed

Just they are rarely used except in places that want/need that behaviour

Yeah, you have to send presence because that's what the subscribe operation is but the MUC doesn't have to send that back to you. So I guess I would see your question as two questions and the answer to must I send is yes and to must I receive is no. And just because you send doesn't require it be sent to anyone else either.

you are right yeah its two questions. my concern basically was that you have to send a presence to everybody in the chat which means you have to know the members

It does make sense to ask for messages from the MUC periodically by sending presence

You as a client only ever send presence to the room, not the other occupants.

You as a room need to send it to all the occupants.

You, as a room, might choose not to do that, but it's breaking a MUST in the spec, so clients are reasonable to behave poorly in the face of you breaking that required behaviour, if you are not controlling all the clients in the environment.

ah you are right my bad. reading the XEP again only the room sends the presence message from all other members > If the service is able to add the user to the room, it MUST send presence from all the existing participants' occupant JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate. [13]

It is supported by all major servers already

which ties directly to me seeing the membership list

so maybe i can hit two birds with one stone

as in: if the room doesnt send presence between everybody, the membership doesnt have to get past around

It can also send presence without including the affiliation if you want that for some reason. But yes any version of this is doable

one reason i would not like the member list is because not everybody may be able to communicate with each other directly. due to firewalls and such.

firewalls i meant that either they are too far away in your social graph or they are just strangers

Well you certainly don't have to include jids in the list

Is this an announcement-only room or a room where people join and chat?

Kev, no, XEP-0045 allows for selective presence broadcast (based on roles)

So no MUST-breaking is necessary

Unless there was an oversight somewhere in the spec

The "Presence Broadcast" section has this: > Unless the room is configured to not broadcast presence from new occupants below a certain affiliation level (as controlled by the "muc#roomconfig_presencebroadcast" room configuration option), the service MUST also send presence from the new participant's occupant JID to the full JIDs of all the occupants (including the new occupant). -- https://xmpp.org/extensions/xep-0045.html#enter-pres

The improvement that MIX/MUX makes is that clients can individually make this decision, rather than the room owner(s)

Probably best to always send the self-presence

Yes, the spec requires that

> , no, XEP-0045 allows for selective presence broadcast (based on roles) If no-one is a participant, then yes, you can do presenceless MUCs that way, true. But once someone's a participant, you MUST receive their presence when you join the room.

> Well you certainly don't have to include jids in the list right and i guess i there would be some kind of "id" occupant or otherwise

> right and i guess i there would be some kind of "id" occupant or otherwise Their occupant JID (room JID with nick as the resource)

But there may also be the consistent ID stuff if the server supports it, yes.

right yeah

Kev, what makes you say that participants MUST always have presence?

7.2.2 > If the service is able to add the user to the room, it MUST send presence from all the existing participants' occupant JIDs to the new occupant's full JID

When XEP-0045 explicitly allows you to override that

The stuff you quoted is about sending the new occupant's presence to existing occupants.

But the bit about sending existing occupants' presence to the new occupant doesn't cover that, that's just a blanket MUST.

That's quite clearly an oversight. It doesn't make much sense to have a config option that controls initial broadcast only, but does not control the broadcast at other times.

I'm loathe to claim anything is quite clear in 45 :)

The intent of the muc#roomconfig_presencebroadcast option is to select which roles have their presence broadcast

That's described multiple times in the document

An implementation following your interpretation would be erratic and broken

All presence, or joins&parts vs presence updates?

E.g. you would be in an empty room, and then rejoin, and suddenly you see everyone

There would be ... issues ....

thinking more about it since i will have some burner ids to put in the member list so might as well do it and have the muc sent the member list ✏

so i may be overthinking things, especially since presence can be tweaked and muc may be fine

NO

wtf

🤷

actually i dont know why i didnt check the MUX pad before but it looks like it solves both of the problems i mentioned today anyway. plus the offline usecase. so might as well use that directly

without hats or the acls that is

The hats/ACL stuff is 99.9% not staying, it's just a scratchpad at the moment while exploring potential ideas

interesting. but yeah i know its early stuff. just makes it clear that the stuff i want is possible

so hats/acl is gonna stay as an optional addon and MUX is going to stick with the MUC stuff for power levels?

No, sorry, I didn't mean to imply that. Just that I don't know *what* it will be yet (proposals are welcome)

I started typing some stuff (which is probably what's still in the pad) and I wasn't too pleased with the result

But sometimes typing it out like that is the best way to decide if something makes sense or not

ah makes sense. from a quick look hats seems to be just a map on top of affiliations and roles and such so meh

Hats aren't anything currently

that also yeah

its basically another MIX with zero traction :P

So this would be one of the first attempts to tie hats into a permissions model

hmm. true actually if instead of the affiliation/role whatever they were tied to a better model it would actually work

(for me at least)

The huge, massive, absolutely critical advantage mux has over mix is backwards compat with muc, literally nothing will gain traction on the public federated XMPP network without it (personal opinion, not legal advice, no warranty bla bla)

MUX will be implemented in Prosody, and unlike MIX it doesn't depend on participant servers, and it is backwards-compatible with MUC, so it will eventually reach (and be usable by) at least 50% of the federated network

I'm not entirely opposed to implementing MIX in the long run if that's what we decide (if certain things in MIX get fixed), but implementing MUC and MIX simultaneously is what has been holding us back in Prosody

Implementing (MUC, MUX) or (MUX, MIX) should both be possible without too much trouble, at least that's the goal

i would like to see an independent permissions model that works for both

> The huge, massive, absolutely critical advantage mux has over mix is backwards compat with muc, literally nothing will gain traction on the public federated XMPP network without it (personal opinion, not legal advice, no warranty bla bla) i agree with this ↺

has there been a community consensus that we need better permission model for MUC?

don't think so, but there's hole in my heart in the shape of multiple hats on a pfp

MSavoritias (fae,ve): what would make it better IYO?

> one reason i would not like the member list is because not everybody may be able to communicate with each other directly. > due to firewalls and such. MSavoritias (fae,ve): well that's why I asked: > Is this an announcement-only room or a room where people join and chat? In my mind if it's the second, it doesn't make sense for people to be about to post messages in a room of X participants if some amount smaller than X will be able to read them? ↺

ah. no the context its a f2f kind of network. where basically people that you dont know cant contact you unless they get the capability to do so from somebody else or from you

But yes, please suggest better/alternative permission models

so for example: i join a groupchat for my local knitting club but i only have 3 people in my contacts. not the other people because i dont know them. and they are not near my graph so i may not even accept connect requests from them

I understand all that for 1:1, but the group chat I don't get So you (a) join that local knitting club group chat and you know 3 of the people (b,c,d) in there and there are 2 others you don't know (y,z)... What do you expect to happen when you talk? When c talks? When z talks?

the whole procedure would work like: i (a) know three people in the local knitting group (b,c,d). so i "subscribe" to them to recieve messages from the room. in the room there happened to be other people (y,z etc.) but i dont need to contact them directly because i fetch messages opportunistically when i ask from b,c,d or they route the messages to others that i sent. and same way i can have subscribers too.

any of the b,c,d can also work as a "introducer" of me into the group. and they added me there initially

and what about the current MUC permissions prevents this in your view?

ah that was seperate. it was responding to moparisthebest question about what i meant with firewalls and how would there be people i cant contact in the same groupchat as me

for the permissions i have a pretty good idea of what i am going for, but i don't feel comfortable talking about it here yet.

> the whole procedure would work like: > i (a) know three people in the local knitting group (b,c,d). so i "subscribe" to them to recieve messages from the room. > in the room there happened to be other people (y,z etc.) but i dont need to contact them directly because i fetch messages opportunistically when i ask from b,c,d or they route the messages to others that i sent. > and same way i can have subscribers too. That *sounds* like you are describing 1:1, not group chat ↺

What happens when you send a message to the group chat? Who sees it?

the message gets relayed through one of the people you are subscribed too. you could also say that the nodes/people you are subscribed too are just servers for you :)

USE MATRIX

NO ONE USE XMPP

hm I don't know anyone using Matrix..

EVERY ONE IS IN MATRIX

XMPP IS DEAD TECH

SHITFUCK: have you come here just to be banned for capslock? =)

NO

I COME HERE TO INFORM

STOP USE XMPP

SHITFUCK, we could have turned you into xmpp's strongest soldier

XMPP IS 100 PEOPLE

MATRIX IS MILLIONS

whatsapp is a shitty xmpp client silly

NO

WHATSAPP IS META

ITS NOT OPEN SOURCE

that's what they use

xmpp

SO WHAT

WHATSAPP PEOPLE DONT CARE

maybe

NO

SHITFUCK, look up how much ram the fast matrix server recommends vs how much ram prosody recommends

IT DOESNT MATTER

spoiler the ratio is like 30:1 ✏

PEOPLE COUNT IS THE IMPORTANT MATTER

exactly Matrix doesn't matter )

META IS BILLIONS

MattJ, pls ban

TABA LOOK UP NETWORK EFFECT

XMPP HAS NO NETWORK

MATRIX DO

CALOPTER DONT BAN ME FOR TRUTH

I AM LEAVING

BUT YOU HAVE INFORMATION USE IT WISE

SHITFUCK: everyone have his own metrics to qualify things

i've tried matrix clients

they're simply worse than xmpp ones

SHITFUCK: what an odd way to advertise Matrix, Matthew

> they're simply worse than xmpp ones 😁️😂️