Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/key/003 draft"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
{{ ORG Restrained Life Relay Specs TOC }}
{{ ORG Restrained Life Relay Specs TOC }}


= !x-key =
= Key =


STATUS: draft
STATUS: draft
Line 11: Line 11:
Commands:
Commands:
* !x-key/<session_key>: associates key <session_key> to current session.
* !x-key/<session_key>: associates key <session_key> to current session.
* !x-takeover/<session_key>: takes control over of the session with specified key
* !x-takeover/<session_key>: takes over control of the session with specified key
* !x-noping: disables ping on relog, while still reinstating all previous restrictions
* !x-noping: disables ping on relog, while still reinstating all previous restrictions. !x-noping/clear cancels !x-noping.
* !x-noping/clear: cancels !x-noping
* !x-nopingclear ('''DEPRECATED'''): synonym of !x-noping/clear. Will be deleted in next version.
* !x-nopingclear ('''DEPRECATED'''): synonym of !x-noping/clear. Will be deleted in next version.




'''Description of !x-key and !x-takeover'''
==!x-key and !x-takeover==


!x-key/<session_key> associates the key <session_key> with the current session. <session_key> is a [[UUID]] randomly generated by the controller of the current session. After a session key is set, any other controller can then take the control of this session by sending the command !x-takeover/<session_key>. By "other", it can also mean the same controller after a relog or region restart and thus a different key.
!x-key/<session_key> associates the key <session_key> with the current session. <session_key> is a [[UUID]] randomly generated by the controller of the current session. After a session key is set, any other controller can then take the control of this session by sending the command !x-takeover/<session_key>. By "other", it can also mean the same controller after a relog or region restart and thus a different key.


Example with two controllers on the left:
===Example===
* C1, who is in control of the session before this exchange,
Two controllers on the left:
* and C2 who will gain control at the end of the exchange (with all restrictions carried over under its own key),
* C1 is in control of the session before this exchange,
and on the right, the relay R.
* and C2 will gain control at the end of the exchange (with all restrictions carried over under its own key).
On the right, R is the relay.


k(C1), k(C2), k(C) are the keys of the controllers and k(R) is the key of the avatar wearing the relay.
k(C1), k(C2), k(C) are the keys of the controllers and k(R) is the key of the avatar wearing the relay.
Line 34: Line 34:




Comments:
* At 1, C1 generates a random UUID key which must be recorded by the relay.
* Between 2 and 3, C1 gives the key to C2. Often C2 will actually be C1 after a relog and thus with a new object key, but with LSL remembering everything from before the relog, in particular the session key.


* It is required that the relay acknowledges !x-key and !x-takeover using private communications only (so that nobody can eavesdrop and read the session key). Use of [[llRegionSayTo]] is therefore mandatory in case you use chat on standard RLVR channel.
===Requirements===
* It is also recommended that the controller sends !x-key and !x-takeover through private channels only too. But, in fine, letting session keys be "leaked" or not is the controller's responsibility. It could be done on purpose.
General requirements:
* For 1, C1 generates a random UUID key which must be recorded by the relay.
* By supporting this x-tension, a relay associates a new key/UUID field to each RLVR session: the session key.
* Between 2 and 3, C1 gives the key to C2; in general C2 will be C1 after a relog with a different key, but its LSL memory intact (and  thus remembering the session key).
* The relay must acknowledge !x-key and !x-takeover using private communications only (so that nobody can eavesdrop and read the session key). Use of [[llRegionSayTo]] is therefore mandatory in case you use chat on standard RLVR channel.
* The communication method is unchanged after !x-takeover. If !x-email was used, it will still be used, until another command says otherwise.
* If a controller C sends a command !x-key/(key) for a current session which already has an abstract key, the new key must supersede the old one.
* In every case if a session was already open, the relay must accept !x-key/(key) by answering !x-key/(key),ok.
* If the command !x-key/(key) is the first command, it must be acknowledged as any new restricting command; by ok or ko, depending on the setting of the relay (auto-accept or ask) and on the answer of the wearer of the relay.
* If a controller C sends a command !x-takeover/(key) with a key which corresponds to no known session key, the relay must answer by !x-takeover/(key),ko and ignore it.
* If the key was known as a session key, the relay must answer !x-takeover/(key),ok and give the control to the controller C.
* Since the abstract key (key) was randomly generated, there is little risk for a session to be stolen.


These commands are intended to be used with the following commands (which are in the same x-tension):
Requirements concerning !x-key:
* !x-key is to be considered as a secondary behavior (it can trigger an ask dialog and open a session but the session will eventually time out if there is no primary behavior)
* On !x-key/<uuid> acceptation, the relay sets the current session key to <uuid>.
* If a relay accepts a command !x-key/<uuid> within a session which already had a key, then the new one replaces the old one.


'''Description of !x-noping and !x-noping/clear'''
Requirements concerning !x-takeover:
* If <uuid> is an existing session key !x-takeover/<uuid> cannot be refused by the relay (acknowledgement by "ok").
* If <uuid> is no existing session key, !x-takeover/<uuid> must be refused by the relay (acknowledgement by "ko").
* In no case !x-takeover triggers an interactive dialog or opens a session.
* On accepting !x-takeover/<uuid>
:* the relay makes the device who issued the command the controller of the session having <uuid> as session key,
:* the relay considers that if that device already was controlling a session, then that session has no controller anymore.
* The communication method (chat, email, http, ...) of the session that was taken over becomes the same as the one by which !x-takeover was received, no matter the way that session was previously accessed. For instance, if a device sends !x-takeover by chat and takes over an existing email session, then the session continues by chat.


There are three ways of getting out of a session: !release sent by the controller, safeword of the relay, and controller not present (not answering !pong to a !ping after a relog or a refresh). The command !x-noping removes the last possibility. So, combined with !x-key/!x-takeover the session persists if the controller disappears.
===Recommendations===
* The controller should preferably send !x-key and !x-takeover through private channels only too. But letting session keys be "leaked" or not is only the controller's responsibility. It could actually be done on purpose.
* The key should preferably be randomly generated, so there is little risk for a session to be stolen by another device by guessing the key.
* A session currently having no controller will fail all pings and thus unless !noping is set, a controller sending !x-takeover within a session will lose its former session (all restrictions will be released). In this case, the relay can release the current session immediately after !x-takeover is accepted.
* As a RLVR controller scripter, most likely you don't want !x-takeover to be sent within an existing session, as this would mean closing/releasing it. If you do that, ask yourself if you want the session to remain in the background. If the answer is yes, don't forget to make the session resistant to !ping's by sending !x-ping before you send !x-takeover/<uuid of the other session>. Also preferably set a key to the first session so it can be recovered later on.


Remarks:
==!x-noping==


*!x-noping can be used without !x-key.
There usually are three ways a relay can end a session:
*As first command, !x-noping must be acknowledged as any new restricting command; by ok or ko, depending on the setting of the relay (auto-accept or ask) and on the answer of the wearer of the relay.
* when a !release is sent by the controller,
* when the user safewords from the relay,
* and when the relay finds the controller is not present (not answering !pong to a !ping after a relog or on refresh).
The command !x-noping disables the latter possibility, so that the session can persist despite the controller disappearing. This would typically happen very often if the controller is a portable HUD.


Combined with !x-key and !x-takeover, !x-ping makes it possible for that portable HUD to recover a RLVR session after its wearer relogs, possibly after a long time offline.
Note !x-noping can also be used without !x-key.
===Example===
After the following sequence of commands, the user of the controller C if it is a HUD can go offline. The session will persist until the relay safewords.
After the following sequence of commands, the user of the controller C if it is a HUD can go offline. The session will persist until the relay safewords.


Line 87: Line 103:
  4 C <- R: blah,k'(C),@xxx=add,ok
  4 C <- R: blah,k'(C),@xxx=add,ok


'''Locked seat and !x-noping'''
===Requirements===
 
* !x-noping is a secondary behavior. It can trigger an interactive ask dialog, depending on settings.
* On answering "!x-noping,ok" to !x-noping, the relay commits itself not to check for presence of the controller of this session anymore and thus not to close the session because the controller fails to answer a ping.


When a grabber uses !x-noping and, moreover, locks the captured avatar on a seat, the grabber cannot resend a @sit:uuid=force command after the ping-pong exchange because there is not anymore such an exchange. It is therefore recommended for the relay to store the key of the seat and to resend the @sit command itself after e.g. a relog. So a relay implementing !x-noping not only must store all restrictions @xxx=add like any other relay but also the uuid key of the seat.
===Caveat===
On relog, the fact there is no ping/pong exchange for a session with !x-noping does not mean the relay should not sit the avatar back to where it was sitted if this session had @unsit=n as active behavior. So the key <uuid> of the sit target should still be remembered, and @sit:<uuid>=force be sent a few seconds after relog.

Revision as of 05:21, 14 June 2011

Restrained Love
Open Relay Group
x-tensions
Restrained Love Relay

Key

STATUS: draft

version: 003

002 Implemented in Dahlia's multirelay >= 0.48 and in anythingRLV >= 3.1

Commands:

  • !x-key/<session_key>: associates key <session_key> to current session.
  • !x-takeover/<session_key>: takes over control of the session with specified key
  • !x-noping: disables ping on relog, while still reinstating all previous restrictions. !x-noping/clear cancels !x-noping.
  • !x-nopingclear (DEPRECATED): synonym of !x-noping/clear. Will be deleted in next version.


!x-key and !x-takeover

!x-key/<session_key> associates the key <session_key> with the current session. <session_key> is a UUID randomly generated by the controller of the current session. After a session key is set, any other controller can then take the control of this session by sending the command !x-takeover/<session_key>. By "other", it can also mean the same controller after a relog or region restart and thus a different key.

Example

Two controllers on the left:

  • C1 is in control of the session before this exchange,
  • and C2 will gain control at the end of the exchange (with all restrictions carried over under its own key).

On the right, R is the relay.

k(C1), k(C2), k(C) are the keys of the controllers and k(R) is the key of the avatar wearing the relay. 

1. C1 -> R: blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2. C1 <- R: blah,k(C1),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3. C2 -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
4. C2 <- R: blah,k(C2),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok


  • At 1, C1 generates a random UUID key which must be recorded by the relay.
  • Between 2 and 3, C1 gives the key to C2. Often C2 will actually be C1 after a relog and thus with a new object key, but with LSL remembering everything from before the relog, in particular the session key.

Requirements

General requirements:

  • By supporting this x-tension, a relay associates a new key/UUID field to each RLVR session: the session key.
  • The relay must acknowledge !x-key and !x-takeover using private communications only (so that nobody can eavesdrop and read the session key). Use of llRegionSayTo is therefore mandatory in case you use chat on standard RLVR channel.

Requirements concerning !x-key:

  • !x-key is to be considered as a secondary behavior (it can trigger an ask dialog and open a session but the session will eventually time out if there is no primary behavior)
  • On !x-key/<uuid> acceptation, the relay sets the current session key to <uuid>.
  • If a relay accepts a command !x-key/<uuid> within a session which already had a key, then the new one replaces the old one.

Requirements concerning !x-takeover:

  • If <uuid> is an existing session key !x-takeover/<uuid> cannot be refused by the relay (acknowledgement by "ok").
  • If <uuid> is no existing session key, !x-takeover/<uuid> must be refused by the relay (acknowledgement by "ko").
  • In no case !x-takeover triggers an interactive dialog or opens a session.
  • On accepting !x-takeover/<uuid>
  • the relay makes the device who issued the command the controller of the session having <uuid> as session key,
  • the relay considers that if that device already was controlling a session, then that session has no controller anymore.
  • The communication method (chat, email, http, ...) of the session that was taken over becomes the same as the one by which !x-takeover was received, no matter the way that session was previously accessed. For instance, if a device sends !x-takeover by chat and takes over an existing email session, then the session continues by chat.

Recommendations

  • The controller should preferably send !x-key and !x-takeover through private channels only too. But letting session keys be "leaked" or not is only the controller's responsibility. It could actually be done on purpose.
  • The key should preferably be randomly generated, so there is little risk for a session to be stolen by another device by guessing the key.
  • A session currently having no controller will fail all pings and thus unless !noping is set, a controller sending !x-takeover within a session will lose its former session (all restrictions will be released). In this case, the relay can release the current session immediately after !x-takeover is accepted.
  • As a RLVR controller scripter, most likely you don't want !x-takeover to be sent within an existing session, as this would mean closing/releasing it. If you do that, ask yourself if you want the session to remain in the background. If the answer is yes, don't forget to make the session resistant to !ping's by sending !x-ping before you send !x-takeover/<uuid of the other session>. Also preferably set a key to the first session so it can be recovered later on.

!x-noping

There usually are three ways a relay can end a session:

  • when a !release is sent by the controller,
  • when the user safewords from the relay,
  • and when the relay finds the controller is not present (not answering !pong to a !ping after a relog or on refresh).

The command !x-noping disables the latter possibility, so that the session can persist despite the controller disappearing. This would typically happen very often if the controller is a portable HUD.

Combined with !x-key and !x-takeover, !x-ping makes it possible for that portable HUD to recover a RLVR session after its wearer relogs, possibly after a long time offline.

Note !x-noping can also be used without !x-key.

Example

After the following sequence of commands, the user of the controller C if it is a HUD can go offline. The session will persist until the relay safewords. 

1 C -> R: blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!x-noping
4 C <- R: blah,k(C),!x-noping,ok

k'(C) is the new UUID key of C after the relog. To cancel this setting after a relog: 

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!x-noping/clear
4 C <- R: blah,k'(C),!x-noping/clear,ok

To release the victim after a relog: 

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!release
4 C <- R: blah,k'(C),!release,ok

To continue with the session after a relog: 

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),@xxx=add
4 C <- R: blah,k'(C),@xxx=add,ok

Requirements

  • !x-noping is a secondary behavior. It can trigger an interactive ask dialog, depending on settings.
  • On answering "!x-noping,ok" to !x-noping, the relay commits itself not to check for presence of the controller of this session anymore and thus not to close the session because the controller fails to answer a ping.

Caveat

On relog, the fact there is no ping/pong exchange for a session with !x-noping does not mean the relay should not sit the avatar back to where it was sitted if this session had @unsit=n as active behavior. So the key <uuid> of the sit target should still be remembered, and @sit:<uuid>=force be sent a few seconds after relog.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Love_Open_Relay_Group/key/003_draft&oldid=1146349"