[Standards] MUC message moderation
mridul at sun.com
Thu Aug 9 18:14:56 UTC 2007
Please note that the submitted specs are based on what have been
shipping for 2+ years now - so it is possible that subsequent xep's have
come out with different or better idioms - we can definitely change for
the better if it is consistent with the rest of the specs.
I have responses to the rest inline.
Peter Saint-Andre wrote:
> As promised, here are some questions and comments on the proposed MUC
> message moderation specs:
> 1. I think it makes sense to combine the two specs into one, with
> separate sections for the occupant and moderator use cases.
The msg_moderate spec talks about occupant to room interaction - which
is expected to be fairly stable across various moderation schemes.
room_moderator spec talks about one realization (profile ?) of message
moderation where room moderators actively take up the role of message
moderator - and component decides on this based on the role & affiliation.
While keeping the interaction between occupant and room stable, we could
have other backend moderation interactions satisfying various other
requirements - the occupant is agnostic to the actual moderation scheme.
Hence the split - since both are logically different functions.
> 2. What is the rationale for sending out state changes via presence from
> the room's JID?
> How will existing clients handle such state notifications?
The intention is for any occupant who does not understand the xep's to
continue to function without any error - but with reduced functionality
since they cant request for moderation.
I was not aware of these presence stanza's causing any problems - but we
could very well change that to message or iq if they satisfy the same
Another alternative could be to discover if the client supports these
xep's (disco ?) and the usecases and stanza's described in msg_moderate
are applicable only to those.
> I think we need to come up with a generic approach here. Perhaps the
> authors of the message moderation proposal could collaborate with the
> authors of the MUCOL proposal (not yet submitted)? They use IQs, not
mucol defines a way to using particular media like whiteboarding. In
case of message moderation it is not a collaboration between
participants of the room. The communication is between the
user/moderator and room so probably we cannot co-relate them.
> 3. Why is the message sender forced to flag the message as intended for
> It seems to me that this forces the client to be smart about the state
> of the room. Older clients may not be that smart, and in any case I
> think the room (MUC service) can intelligently decide how to handle
The affiliation/role of an occupant which can make use msg_moderate spec
is of one who does not have voice.
So, existing clients will not be able to send messages to the room
currently, and they will not be expecting this ability (like no text
area in client, etc).
This proposal enables these users to participate in the discussion -
pending approval from moderator.
The intention here is to be explicit about exhibiting the fact that
occupants are requesting for a moderated message submission - and due to
the nature of submission, there are additional workflow and client side
UI aspects which make use of this information.
For example, in our client how this works is like this:
By default if occupant has no voice, the textarea for submitting
messages is not present. As soon as message moderation is enabled - a
text area come up, along with a list of submitted messages and their
status (pending, approved, rejected - with reason).
On submission of a message, it goes into the pending list - and stays
there until room acts on it after moderator decision (which can be an
extended amount of time).
So the user known about message moderation being active, and does not
expect his message to show up in the room until approved.
So the moderation aspect is expected to be explicit - not implicit.
A particular client could hide these if required.
> messages without forcing that intelligence on the sender. Also there is
> a dependency here for the client to include an 'id' attribute, which
> many clients do not. IMHO it would be good to enable the clients to be
> fairly dumb in order to participate in a message-moderated MUC.
Use of id is optional.
Without using id, a client may not be able to disambiguate responses to
two message submissions if they are rapid enough (that is, before
component responds to both after recieving both).
Normally, this should not happen - hence optional.
Only requirement is - if present, room should ack it in the response.
> 4. If undeliverable messages are sent with type='groupchat' then I think
> older clients could get confused.
We could change this (remove type ?).
[Please see response (*) below though.]
> 5. Example 10 says it is an error but the type is groupchat.
The error is present in the action's type - this is not an error to a
specific message submission, but a state error due to succeeding events
(one of them being, all moderators leaving much after the user submitted
the message : so there was nothing wrong with the initial submission as
(*) In general, we always kept the type to groupchat in the
request/response since the values an action type can take are more than
what a message type can take.
We could change this if it is unambiguous as to what the error actually
> 6. The cancellation workflow strikes me as similar to XEP-0142. Perhaps
> it would be good to make the two approaches consistent (or at least not
> very different).
From what I understood, the intent in 142 seems to be different and the
way cancellation is done is consistent with the rest of the spec.
If we can make a change to this usecase in a manner consistent with the
rest of the proposed specs, that would be great.
Currently, we are trying to make sure that everything within the two
specs are consistent with each other.
> 7. We probably want a consistent protocol between XEP-0045 and moderator
> management to request privileges.
A moderator/owner becoming a message moderator is an additional
responsibility they takes up - and this usecase is applicable only to
participants who already are moderator/owner : not to others.
It is not an affiliation or role change - but a state change.
Which is why we used iq's, and explicit action type for all room
> 8. Use of the term "moderator" might provide confusion with XEP-0045,
> unless you're just adding a new privilege to the existing role. If this
> is a new role, then we need to think clearly about how we want to do
> that, since others might want new roles and affiliations too (e.g., for
> multi-user media conferences, whiteboarding, etc.).
In room_moderator spec, a message moderator is a room moderator who has
temporarily taken up additional responsibilities beyond what is defined
in xep 45.
The way we designed the spec, we wanted to continue with the existing
acl's in muc and did not want a new role or affiliation level.
Any subsequent proposal would map to the muc role/affiliation levels in
some way, and we would just reuse that mapping for the purpose of these
Both the msg_moderate and room_moderate specs only define the
interaction between an occupant/moderator and the room - so it is
possible to extend these definitions in a component and reuse the same
interactions. Both specs defer to the room for the actual decisions.
> 9. I'm not sure what it means to "leave as a moderator" -- does that
> mean to stop being a moderator? Isn't that a simple role change per
"leave as a moderator" as in - Stop taking up the responsibility of
being a message moderator.
The occupant continues to be a room moderator/room occupant - just that
they stop being a message moderator.
> 10. In order to moderate messages, why don't we use Data Forms as we do
> for voice requests?
I am not sure of using an alternate data form only for purpose of
message approval - it kind of introduces inconsistency within the specs.
The voice request is a change of role - while this is related to each
message moderation submission : I am not sure if we should be trying to
The message moderation request is just the occupant submitted request
with a few additional meta-data for identifying the request back to the
room - and we wanted to keep it as minimal as possible : almost along
the lines of AMP.
More information about the Standards