Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/who/002 draft"

From Second Life Wiki
Jump to navigation Jump to search
Line 72: Line 72:
*!x-who/FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF (wildcard) is valid, meaning "some user", with no more info given.
*!x-who/FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF (wildcard) is valid, meaning "some user", with no more info given.


===Recommendations===
===Caveat===
*The content of this message is obviously only as trustworthy as the world object is. Hence when you accept a bunch of commands prefixed by a "!x-who", you have to trust both the avatar whose key is in after the "!x-who" '''''and''''' the owner of the device issuing the command.
The content of this message is obviously only as trustworthy as the world object is. Hence when you accept a bunch of commands prefixed by a "!x-who", you have to trust both the avatar whose key is in after the "!x-who" '''''and''''' 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.
 
* !x-who should be the first command in a message, so it can be picked up immediately by the relay.
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==
==Implementation ideas==

Revision as of 12:09, 18 June 2011

STATUS: Silver

VERSION: 002

Relay implementations: TK, Dahlia's, Satomi's, OpenCollar, Cool HUD(?) ...

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 scenarii

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.
  • The relay must remember the last key positively authentified 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 no user. It is synonym of !x-who/clear.
  • !x-who/FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF (wildcard) is valid, meaning "some user", with no more info given.

Caveat

The content of this message is obviously only as trustworthy as the world object is. Hence when you accept a bunch of commands prefixed by a "!x-who", you have to trust both the avatar whose key is in after the "!x-who" and 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.
  • Since !x-who only really affects current line of commands for sure, it is not very useful to send !x-who/clear. It was added to this specification for the sake of consistance with other meta-commands inducing secondary behaviors. However since this should erase the key of the last user, this gives another chance to the relay wearer to refuse commands from the same user later on in this session.