!x-key

STATUS: draft

version: 002 (a few changes between 001 and 002)

Version 003 proposal

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

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 then 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 unchanged; it remains private if !x-channel was used; C2 can 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

Locked seat and !x-noping

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.

Important remark: interaction with !x-email

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 session UUID key (which has no reason to be equal to the UUID key generated by !x-key) will be accepted; if the UUID key of the controller has changed, the new one will be recorded by the relay. If the controller sends a !x-takeover/(key) anyway by email, the session continues by email.If the controller sends a !x-takeover/(key) by local chat, the relay must go back to chat mode.