The Moderation Protocol is a standard protocol that allows my viewer to communicate with in-world moderation tools. This is a draft under discussion and not yet implemented.
Commands are sent on channel by default 0. The viewer will always shout.
Alternatively, a different channel can be used. The channel must be positive as the viewer can't talk on negative channels.
: My preference would be to have the viewer shout commands over channel 0, to have open moderation (as in, everybody can see who is kicking out who, no secrets). If this isn't satisfactory to all parties, I propose that any other positive channel may be used, but 0 is the default. This will also make it easy to use the commands without a viewer that supports them.
All commands must be prefixed with "!admin", to make it less likely that anything on the channel interfers.
The next word is the command's name. All commands are one word, lowercase, without spaces.
A command can be suffixed with a "?" to indicate that the command is optional, and that if the moderation object doesn't recognize it, it should be silently ignored. This is intended to allow extensions.
Unless the "?" is used, unrecognized commands should be reported.
Arguments are separated by a space.
For commands that operate on avatars, the arguments should be: FirstName LastName [Key]
For commands specifying the key, the script should issue a dataserver request and make sure the name returned for the key is the same as the one that was specified. This is intended to eliminate the possibility of somebody accidentally or maliciously providing the wrong key.
By "optional command" I mean truly optional, as in it can be safely ignored. I can see two kinds of extensions:
Extensions that if used are expected to work. For example, interfacing with BanLink?
. If the object doesn't support banlinking somebody you wouldn't want this to be silently ignored. You'd want an error message to know that something you tried to do didn't work.
Extensions that are really optional. For example suppose an extension to deliver a log to the viewer, which the viewer automatically requests when teleporting to the area. You wouldn't want seeing the object produce an error message every time a viewer emits a request like that (on a non-0 channel).
This sort of thing probably isn't needed just yet, but it seems easy enough that it makes sense to plan for it.
The exact behavior of the commands isn't specified. Each place may add whatever variations make sense for them.
|eject||Avatar||Ejects avatar from the land. Islands may send home instead.
|shortban||Avatar||Adds to ban list. Short duration (site defined)
|longban||Avatar||Adds to ban list. Long duration (site defined)
|permban||Avatar||Adds to ban list. Permanent.
|unban||Avatar||Removes from ban list
|warn||Avatar||Delivers an official warning|
These are additional commands for usage at Luskwood. Implementing them is optional.
|findadmin||(none)||Searches list of moderators, finds an online one and allows to contact them. The LW version presents a dialog with a list of admins and allows choosing one, but this doesn't need to be a mandatory behavior. It could just IM the first admin it finds instead. At LW, no special permission is needed to use this command.
|advice||Avatar||Delivers an official request to let admins do their job. At LW, this is: "This is a message from the Luskwood security system addressed to you, AvatarName?. A staff member is attemtping to resolve the current situation. Please allow them to do so without interference. "Thank you."|
!admin eject Dale Glass
!admin eject Dale Glass 7aa440e7-4971-4a6c-8289-6960f2e7781e
Example optional extension command: (this should be ignored silently if there's no foobar command)
!admin foobar? Dale Glass