[Standards] MUC message moderation

Peter Saint-Andre stpeter at jabber.org
Wed Aug 8 22:56:06 UTC 2007


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.


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?

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/


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


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


5. Example 10 says it is an error but the type is groupchat.

http://www.xmpp.org/extensions/inbox/msg_moderate.html#example-10


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


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


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


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?


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


/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070808/4d77e94f/attachment.bin>


More information about the Standards mailing list