LSL Protocol/Restrained Love Open Relay Group/key
!x-key
STATUS: draft
version: 001
Implemented in Dahlia's multirelay 0.45 and in anythingRLV 3.0beta
Description of !x-key and !x-takeover
!x-key/(key) associates the UUID key (key) with the current session. (key) is randomly generated by the controller of the current session.
Any controller can take the control of this session by sending the command !x-takeover/(key). Any controller means another real controller, or the same one after a relog and a different UUID key. Example with two controllers C1 and C2 on the left and the relay on the right. k(C1), k(C2), k(C) are UUID of controllers and k(R) is the UUID key of the avatar having the relay.
1 -c1> blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a 2 <r- blah,k(C1),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok 3 -c2> blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a 4 <-r blah,k(C2),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
Comments:
- Before the sequence of commands, the session is controlled by C1.
- For 1, C1 generates a random UUID key which must be recorded by the relay.
- Between 2 and 3, C1 gives the key to C2; in general C2 will be C1 after a relog with a different real UUID key.
- The communication channel is reinitialized to the default RLV channel; C2 must negociate a new private channel with !x-channel if necessary.
- After the sequence of commands, the session is controlled by C2.
- 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; if the current session has not yet an abstract key, the relay must accept it 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 is not recorded, the relay must answer by !x-takeover/(key),ko. If the key is recorded, the relay must answer !x-takeover/(key),ok and gives the control to the controller C. Since the abstract key (key) is randomly generated, there are no risks for a session to be stolen.
These commands are intended to be used with the following commands (which are in the same x-tension):
Description of !x-noping and !x-nopingclear
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.
Remarks:
- !x-noping can be used without !x-key.
- As first command, !x-noping must be processed 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.
After the following sequence of commands, the user of the controller C if it is a HUD can go offline. The session will persist unless the relay safewords.
1 -c> blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a 2 <r- blah,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok 3 -c> blah,k(R),!x-noping 4 <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> blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a 2 <-r blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok 3 -c> blah,k(R),!x-nopingclear 4 <r- blah,k'(C),!x-nopingclear,ok
To release the victim after a relog:
1 -c> blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a 2 <-r blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok 3 -c> blah,k(R),!release 4 <r- blah,k'(C),!release,ok
To continue with the session after a relog:
1 -c> blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a 2 <-r blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok 3 -c> blah,k(R),@xxx=add 4 <r- blah,k'(C),@xxx=add,ok
Important remark
If the controller and the relay were in a !x-email session before the relog, the controller can take over the relay without using the command !x-takeover: it is already in the specification of !x-email that an email with the correct UUID key will be accepted; if the UUID key of the controller has changed, the new one will be recorded by the relay.