[Standards] MUC message moderation

Mridul Muralidharan mridul at sun.com
Thu Aug 9 18:14:56 UTC 2007


Hi Peter,

   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.

Thanks,
Mridul

Peter Saint-Andre wrote:
> As promised, here are some questions and comments on the proposed MUC
> message moderation specs:
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html
> 
> http://www.xmpp.org/extensions/inbox/room_moderator.html
> 
> 
> 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?
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state
> 
> 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 
requirements.

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
> presence.
> 
> http://www.wimba.com/labs/mucol/
> 

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
> moderation?
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state
> 
> 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.
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html#message-moderation-result
> 

We could change this (remove type ?).
[Please see response (*) below though.]

> 
> 5. Example 10 says it is an error but the type is groupchat.
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html#example-10
> 


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 
such).

(*) 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 
means.



> 
> 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).
> 
> http://www.xmpp.org/extensions/inbox/msg_moderate.html#message-submission-cancel
> 


 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.
> 
> http://www.xmpp.org/extensions/inbox/room_moderator.html#start-moderation
> 
> http://www.xmpp.org/extensions/xep-0045.html#requestvoice
> 


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 
moderator usecases.



> 
> 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 
specs.

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
> XEP-0045?
> 


"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?
> 
> http://www.xmpp.org/extensions/inbox/room_moderator.html#message-moderation-submit
> 
> http://www.xmpp.org/extensions/xep-0045.html#voiceapprove
> 

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 
correlate both.

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.


Regards,
Mridul

> 
> /psa




More information about the Standards mailing list