LSL Protocol/Restrained Love Open Relay Group/email

!x-email

STATUS: draft 5

VERSION: 005

Draft4 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-channel. Full support for !x-channel is also strongly recommended for !x-email support.

Presentation of e-mails

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

ex:  ORG encapsulated RLVR protocol,005,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 (with session transfer):

This protocol establishes an authentified email session and transfers whatever restrictions C already had on R.

1 -c>     blah,k(R),!x-email
2 <c-     blah,k(C),!x-email,ok
3 -e>     bleh,!x-session
4 <e-     bleh,!x-session,nonce
5 -c>     nonce,k(R),!x-session-confirm
6 <c-     nonce,k(C),!x-session-confirm, ok

Comments:

• After 2, the relay is ready to initiate the session (it is listening to emails), and the controller (also listiening) knows it.
• Between 2 and 3, the controller randomly generates a session key, k(S), that goes into the future e-mail topics.
• After 4, as only R should have received 3, C knows 4 comes from R, and thus that R has acknowledged k(S). Moreover C knows R has generated the nonce[1] (random integer that should be used only once).
• After 5, R knows that C has received the nonce, and thus that C is the one who proposed k(S).
• After 6, C knows that R knows, which means both C and R agrees on the shared secret k(S).

This protocol only works because of the unusual properties of the used channels: chat messages being public, but authentified (SL server guarrantees the origin of messages), e-mails being somewhat private (short being able to physically spy network links... ), but are easily forgeable, thus not authentified.

Simple Email session initiation protocol (without session transfer):

This protocol establishes an authentified email session and transfers whatever restrictions C already had on R.

1 -c>     blah,k(R),!x-email
2 <c-     blah,k(C),!x-email,ok
3 -e>     bleh,<anything>
4 <e-     bleh,<anything>,<ack>
...

Here there is no need for an elaborate authentification protocol: the relay will only read the session key from the e-mail topic and decide what to do with it (depending on its acceptance policy).

Alternately:

1 X-c>R     blah,k(R),!x-email
2 X<c-R     blah,k(X),!x-email,ok
3 -e>     bleh,<anything>
4 <e-     bleh,<anything>,<ack>
...

Where X is a 3rd party object. This allows C to start a session from another sim, assuming it knows R's key by some other medium.

Now supposing some relays keep e-mail polling always on, even steps 1 and 2 are optionnal.

Relaying viewer chat messages:

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

R has a new key:

When the relay wearer teleports or is crossing regions, the relay can (will?) have a new key. For it being able to receive further controller messages, it needs to give its new key.

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

Comment: the new relay key appears in the email address, for this reason it doesn't show explictly in this dialog.

C has a new key:

Same issue for the controller, as it could well be a device worn by an avatar, or even if it is an object rezed on land, the region could restart.

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

Comment: here also, the key is implicit, as it is included in the e-mail address.

Note: this is only the recommended method. The following scenario should also work, provided <anything> is a valid RLVR command, and the topic includes the relevant session key:

-e>   blah,<anything>
<e-   blah,<anything>,<ack>

Ending e-mail session and going to chat

-e>     blih,!x-channel/-12345
<e-     blih,!x-channel/-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-channel/-12234,ko

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

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

!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)

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.