Re: XEP-0045 muc#roomconfig_allowinvites in practise

On 11/26/25 9:39 AM, Stephen Paul Weber wrote:
> Hello everyone,
> 
> XEP-0045 is very quiet about how some of the options are to be 
> interpreted. For muc#roomconfig_allowinvites there is only one normative 
> line in the XEP, in the registry submission, which is "Whether to Allow 
> Occupants to Invite Others"
> 
> Now, it seems that ejabberd and Conversations have interpreted this to 
> mean "whether to allow occupants *who wouldn't normally be able to 
> invite otherwise* to invite other" which is to say, pretty much, in a 
> members only room can members invite members.  On means members invite 
> members, off means only admin can (actually Conversations checks for 
> moderator role not for admin...)
> 
> This feels like the correct implementation to me given that you can't 
> meaningfully restrict invitations to a pubilc MUC (you could block 
> mediated invitations but we're moving away from those and they don't do 
> anything special in a public MUC traditionally) and it seems like 
> nonsense to ban admins from inviting members (since the admins can 
> change this settings anyway?)
> 
> Why it matters: currently Prosody does not implement this option at all, 
> because it seemed from the descriptio to mean something nonsensical. So 
> Prosody has (AFAICT) implemented the same thing as ejabberd and 
> Conversations, but under a custom name to make it clear how it works.
> 
> My proposal: change the one line of text in the XEP to instead read 
> "Whether to Allow Members to Invite Others".

That seems reasonable to me. The privilege of sending invitations 
derives from the time when the spec used the phrase "invitation-only 
room" for what we now call a "members-only room" (a change made in 
Version 0.10 on 2002-10-15).

Peter


_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]