[Standards] MUC message moderation
stpeter at jabber.org
Fri Aug 10 21:18:11 UTC 2007
Mridul Muralidharan wrote:
> 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.
OK, thanks for explaining the context.
> 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.
I understand that moderation could occur in different ways (e.g., via a
web interface). But I think it would be simpler for developers if
everything is in one spec.
>> 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
I think it is worth thinking about this. Currently clients would not
know what to do with presence from the room. I know we've talked about
that idea and I still think it's worth pursuing, but we're really
changing the state of the room here. Let's say that people can subscribe
to the room from outside -- would they get these presence updates? That
would be odd -- they are intended only for people in the room. So I
think an in-room message or in-room IQ would make more sense. Probably a
message would be enough (I don't see a good reason to ack the status
> 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.
How so? In any case I think an in-room message would make the most sense.
>> 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.
I meant a generic approach to sending out notification of changes in the
room state. Again see the in-room messages we send already:
>> 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.
But can't the room be smart about that? In my experience, lots of
clients may ignore the fact that the user does not have voice and enable
the user to send messages anyway. In your approach, the client would
need to know that the user does not have voice and then specifically
flag the message as needing moderation. IMHO the room should know which
users have voice and which don't, and if the room receives a message
from a user without voice then it should send that message off to the
moderators (perhaps also sending notification to the sender, which the
sender's client can use to do something smart if it understands the
moderated message stuff). But don't force the client to support this in
order to participate at all.
> For example, in our client how this works is like this:
Your client is smart. Not all clients are as smart as yours
> 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.
See above. IMHO this puts too much of a burden on the client (and on
>> 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.
See above. I still think you're closing out too many dumb clients.
>> 4. If undeliverable messages are sent with type='groupchat' then I think
>> older clients could get confused.
> We could change this (remove type ?).
At least if it is not type='groupchat' then it would not be shown in the
same interface. But I'd be curious to see how clients handle this kind
of thing now, because it is perhaps not as well-specified as it could be
> [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
Yes, see above, I think we need to clarify this in XEP-0045. Right now I
think MUC servers don't return errors, but I have not tested it. Will do
that before posting further about it.
>> 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.
Always a good idea. :)
>> 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
> moderator usecases.
Maybe I'm missing something, but it seems to me that the ability or
privilege to moderate messages is something that existing room
moderators would have automatically if the state of the room changed to
this moderated mode. We didn't define that mode in XEP-0045 (it was
explicitly out of scope) but I don't understand why existing room
moderators (or room admins) would not have this privilege. The state of
the room changes and this privilege is now activated / has meaning.
>> 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.
Right, but only because the room is now in moderation mode.
> 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.
Good idea. But we're not changing the meaning of the roles and
affiliations -- we're just saying that moderator now means something in
addition (hey you've got a new privilege, that's great!).
> 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.
Why? I don't see the use case for this. If you don't want the
responsibility, don't sign up for being a moderator. Life is hard.
>> 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
> correlate both.
It would be a different data form. But it seems good to re-use data
forms here rather than define a special-purpose XML format that clients
need to code for. With data forms we get those GUIs for free.
> 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.
Data forms re-use seems better here. But I'd be curious to see what
client authors think.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards