LSL Protocol/Restrained Love Open Relay Group/key/003 draft

!x-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 control over 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.

Description of !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 with two controllers on the left:

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

and on the right, the relay R.

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

Comments:

• 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.
• 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.
• 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 key, but its LSL memory intact (and thus remembering the session key).
• 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):

Description of !x-noping and !x-noping/clear

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 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.

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

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.