LSL Protocol/Restrained Love Open Relay Group/email/006 draft

!x-email

STATUS: draft

VERSION: 006

MANDATORY DEPENDENCIES: autoforward, key

RECOMMENDED: sensor

005 implemented in Satomi's Multi-Relay HUD 0.93, and Satomi's Witchy Remote 1.1beta2

005 Implemented in Dahlia's multirelay >=0.39 and anythingRLV >=2.97

Presentation of e-mails

The topic: ORG encapsulated RLVR protocol,<protocol version>, <session_key>

ex:  ORG encapsulated RLVR protocol,006,45afb982-d02c-35e1-d492-a948b92c92f3

The session key is a secret shared by both relay and controlling device, and will be created during the protocol initiation using !x-key as defined in key.

Example of initialization between a controller C and the relay R

In the following exchange, the controller C and the relay R negotiates a secret UUID key which will be the key of the session. The exchange is done using llRegionSayTo() to keep the key secret (k(R) is the UUID key of the wearer of the relay and k(C) the UUID key of the controller).

1 C--RLVR--> R    secret_key,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R    secret_key,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

The second step consists of initializing the autoforwarding by the following sequence:

1 C--RLVR--> R    autoforwarding,k(R),!x-autoforward
2 C<-RLVR--- R    autoforwarding,k(C),!x-autoforward,ok

Then C can start an email session using !x-email as follows:

1 C--RLVR--> R    blah,k(R),!x-email
2 C<-RLVR--- R    blah,k(C),!x-email,ok

Without secret key, the answer for !x-email must be a "ko". There are no exceptions. Then the session can continue by email using the subject "ORG encapsulated RLVR protocol,006,a586c562-bf27-b7db-e36e-822d0a9ba02a".

1 -e>     bleh,<anything>
2 <e-     bleh,<anything>,<ack>
...

Remark

• The autoforwarding is not required: a controller does not necessarily need to send @getxxx or @notify commands.

Ending the email session between a controller C and the relay R

To end up an email session, the command !x-takeover is used (in 005, the command !x-channel was used but this command will be less useful in the future and probably deprecated because of llRegionSayTo()).

1 C--RLVR--> R   back_to_chat,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R   back_to_chat,k(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

Note that in the above exchange, the controller C is not necessary anymore the first controller; this exchange can also be interpreted as a kind of handover. Other possibility (interesting ?? not sure):

1 C--RLVR--> R   back_to_chat,k(R),!x-email/clear
2 C<-RLVR--- R   back_to_chat,k(C),!x-email/clear,ok

In this new exchange, the controller C must be the same controller (i.e. the same UUID key) as the one which started the email session.

Testing controller's presence

For garbage collection purposes, be it on relog, or on regular basis, R might want to check if C is still active. The ping mechanism can be used here.

<e-    ping,ping,ping
-e>    ping,!pong

The important thing is that the relay remembers it was an email session after relog.

C can check R's presence by sending any valid message, as acknowledgement by R is required for every RLVR message from C. If the only purpose of the message is presience verification, the following scenario is recommended:

-e>    blah,!x-email
<e-    blah,!x-email,ok

Handover

!x-handover/K/n should work like in chat sessions (with the semantics that the session is transfered to the object of key K, chatting on standard RLVR channel).

Handing over to another object while remaining in e-mail mode, doesn't however require any special step. The following scenario can be used:

1 - assume C has a session with R, using key k(S)
2 - C gives k(S) to another object C' via any preferred medium
3 - now  C' can continue e-mailing with S, using key k(S) (and can use the "C has a new key" scenario)

Handing over to oneself can also be used to switch back to chat mode.