LSL Protocol/Restrained Love Open Relay Group/email

!x-email

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

Initiate an email-encapsulated RLVR session.

On reception of !x-email, the relay should make itself ready for the protocol initiation, which means starting checking emails periodically. The command should be ignored (or ko'd) by older relays.

Other commands used in this protocol: !x-session, !x-session-confirm, !x-listen. Full support for !x-listen is also strongly suggested for !x-email support.

Presentation of e-mails

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

ex:  ORG encapsulated RLVR protocol,draft2,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.

The message: consists of several submessages, each on a different line.

A submessage is:

either a RLVR standard message (only without the recipient key): <identifier>,<RLVR command> for a controlling object message, and <identifier>,<RLVR command>,<ack> for a relay message.
either a RL viewer answer (for instance an answer to a @getstatus or @version): <channel>,<viewer answer>

Protocol scenarii

Conventions: messages are symbolized by different types of arrows. We suppose the controller (C) is on the left and the relay (R) on the right. An arrow with a c (-c>) is a chat message on RLVR channel (or whatever channel the controller and the relay negotiated before). An arrow with a e (-e>), is a submessage (like defined before) in an email with the requirements stated before.

C(ontroller)<->R(elay)

-c> is a message by chat channel: authentified, but not private
-e> is a message by email: private but not authentified

Email session initiation protocol:

This protocol establishes an authentified email session.

-c>     blah,k(R),!x-email
<c-     blah,k(C),!x-email,ok
-e>     bleh,!x-session                                  |C knows it goes to R (nb: the topic contains a new session key k(S), just randomly created by the controller)
<e-     bleh,!x-session, nonce                      | C knows this comes from R (because of k(S)) and thus that R acknowledges k(S)
-c>     nonce,k(R),!x-session-confirm                      | R knows this comes from C (chat channel) and thus that C acknowledges k(S)
<c-     nonce,k(C),!x-session-confirm, ok

R has a new key:

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

C has a new key:

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

Relaying viewer chat messages:

( -e>  bloh,@getxxxx=1234
  <e-   bloh,@getxxx=1234,ok )
<e-    1234,<chat_message>

//Maybe won't be implemented at all.
//Aternately:
//-e>    k(R),bloh,#getxxxx
//<e-    k(C),bloh,#getxxxx,<message>
//

Ending e-mail session and going to chat

-e>     blih,!x-listen/-12345
<e-     blih,!x-listen/-12234,ok

Both relay and controller have to check that their recipient is in chat range. The controller before even trying. The relay before acknowledging. If the latter fails, then the relay should answer:

<e-     blih,!x-listen/-12234,ko

Handover

!handover should combine nicely, but is actually optional, as giving k(S) to the device you want to hand the session over to should allow the taking over device to use the "C has a new key" mechanism to announce its email address in place of that of the handing over device.

Requirements

On !x-email acknowledgement, the relay should start listening to e-mails and handle them like RLVR messages.
On !x-session confirm, the relay confirms that the RLVR session with the controller is transfered to e-mail, which means e-mails with the negotiated session key should be handled as if coming from the controller.
Whenever the relay accepts a RLV command with calls for a viewer answer (@blah=1234), the relay must listen to the viewer answer, and forward it via email to the controller.