Define/Document affiliations permissions management for rooms

[nesium]

It seems that our implementation of room affiliations and the corresponding privileges will differ from what is described in the MUC spec.

Here's an example when inviting a user to a room:

The MUC XEP says

If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a error to the occupant; for details, see the Modifying the Member List section of this document.)

In our case though this might turn into a problem. An occupant of a room should be able to invite other users. These in turn should then be able to invite other users as well. The problem is that according to the MUC spec you’d need to be Admin to invite other users (modify the member list), however you can only grant Admin status to other users as an Owner - which would be the precondition for the invited users to invite other users on their behalf as well, unless the server would automatically turn these into Admins. Otherwise not everyone can be an owner which would e.g. allow them to destroy a room.

These permissions needs to be defined, documented in a way that also works for end users and of course implemented on the server.