IntroductionThe 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.
ChannelCommands 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.
Rationale: 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.
FormatAll 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.
Optional commandsBy "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.
Standard commandsThe exact behavior of the commands isn't specified. Each place may add whatever variations make sense for them.
Luskwood extensionsThese are additional commands for usage at Luskwood. Implementing them is optional.
!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