LSL Protocol/Restrained Love Open Relay Group/who/002 draft

STATUS: Silver
VERSION: 002
Relay implementations: TK, Dahlia's, Satomi's, OpenCollar, Cool HUD(?), Turbo Safety 1.3 ...
Controller implementations: TK/dd, Dahlia, Witchy, and so on...
Commands:
* !x-who: secondary behavior
(was previously !who, which is now deprecated)
Synopsis:
This x-tension makes it possible for the controller to tell the relay who is currently operating the device.
This is motivated by a legitimate question relay wearers ask themselves when they get the authorization dialog "Should I? Should I not? I know this device. It could be fine... if only I knew the one pressing the buttons was not some -BEEP-!".
Using the information provided by !x-who, now the relay can inform the wearer and tell them the name of the avatar pressing the buttons.
==Usage==
===Syntax===
!x-who/<key>
:: (key) is the UUID of the AV that you wish to present to the relay.
It is assumed that all commands following !x-who in the message are sent on behalf of that AV.
Commands in next messages are not affected by !x-who.
===Usage scenarios===
Use of !x-who in front of a bunch of commands to inform the relay:
 C -> R: @detach=n|!x-who/<user_key>|@remoutfit=force
 <- : @detach=n,ok
 -- auth dialog, the wearer says they don't like the avatar with key <user_key> --
 <- : !x-who/<user_key>,ko
 <- : @remoutfit=force,ko
 -> : @remoutfit:shoes=force
 <- : @remoutfit:shoes=force,ok
As a result, the wearer's relay is locked, and the wearer is stripped only of their shoes.
 C -> R: !x-who/<user_key_1>|@remoutfit=force
 -- auth dialog, the wearer says they like the avatar with key <user_key_1> --
 <- : !x-who/<user_key_1>,ok
 <- : @remoutfit=force,ok
 -> : !x-who/<user_key_2>|@detach:skull=force
 -- auth dialog, the wearer says they don't like the avatar with key <user_key_2> --
 <- : !x-who/<user_key_2>,ko
 <- : @detach:skull=force,ko
As a result, the wearer's relay is locked, and the wearer is stripped of their clothes, but keeping their prim hair.
Alternatively, use of !x-who alone for its acknowledgement value:
 C -> R: !x-who/<user_key>
 -- auth dialog, the wearer says they don't like the avatar with key <user_key> --
 <- : !x-who/<user_key>,ko;
After this ko, the controller knows not to send further commands on behalf of that user.
 C <- R: !x-who/<user_key>
 -- auth dialog, the wearer says they like the avatar with key <user_key> --
 -> : !x-who/<user_key>,ok
After this ok, the controller knows it is fine to send commands on behalf of that user.
===Requirements===
* !x-who is always the first command in a RLVR message from the controller.
* The relay must remember the last key positively authenticated that was given in a !x-who. This way, if several subsequent messages use the same user key in !x-who, the ask dialog will appear for the first message only. Therefore the controller can safely put !x-who in front of every batch of commands.
* For the sake of simplicity of implementation, it is not expected (but allowed) that the relay remembers all users in the session.
*!x-who/clear tells the relay that following commands are not sent by a menu user and that it is not required for the relay to remember the user key anymore.
*!x-who/00000000-0000-0000-0000-000000000000 (NULL_KEY) is valid, meaning "some user", with no more info given.
===Caveat===
The content of this message is obviously only as trustworthy as the controller is. Hence when you accept a bunch of commands prefixed by a "!x-who", you have to trust not only the avatar whose key is in after the "!x-who" and, but also the owner of the device issuing the command.
Fortunately this requirement can be met easily (i.e.: if the owner is also the land owner, or if you personally know her), which makes this meta-command useful nonetheless.
==Implementation ideas==
* The acknowledgement to a !x-who can be used by the controller to display some message and warn the user attempting to use its menus. 
* The ask dialog in relays would ideally show the device name, its owner's name and that of the avatar using the device at the moment. Several actions can be proposed for accepting/rejecting the control attempt, with or without adding owner and/or controller to a white or black list.