!x-email

STATUS: draft

VERSION: 006

PREREQUISITE: forward

RECOMMENDED: key

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

Initiate an email-encapsulated RLVR session.

On reception of !x-email, the relay should start checking emails periodically and execute their content as RLVR commands.

Commands:

!x-email, which is secondarily restricting.
!x-email/clear, which is releasing.

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 as described in forward (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 may not be private
-R> is a llRegionSayTo message by chat channel: authentified and private
-e> is a message by email: private but not authentified

Email session initiation

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

After this, the relay starts polling for emails and execute them as RLVR commands.

The relay can stop polling after some timeout after no email session exists anymore.

Chat session can be transfered over to email by using key x-tension.

1 -R>     blah,k(R),!x-key/k(S)/!x-email        where k(S) is some randomly generated UUID
2 <c-     blah,k(C),!x-key/k(S),ok
3 <R-     blah,k(C),!x-email,ok
4 -e>     blah,!x-takeover/k(S)
5 <e-     blah,!x-takeover/k(S),ok

k(S) being a shared secret thanks to llRegionSayTo, and included in the topic of every subsequent email, R is certain that it is really C sending emails, and thus can transfer over all restrictions (or associate the email address to the original key, depending on relay implementation).

Remote initiation protocol:

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

In other words: if the relay is already polling email, and C knows k(R) (and thus its email address) no specific step is required. In this case, it is up to C to create a session key.

If the relay is not polling email, it can be started thanks to another controller X in the same sim as R, by the following exchange:

1 X-c>R     blah,k(R),!x-email
2 X<R-R     blah,k(X),!x-email,ok

Only requirement: if the relay advertises being open on email, it has to poll email. The !x-email exchange above plays this role, enabling polling, but maybe other means can be used.

Relaying viewer chat messages:

Viewer replies are forwarded back to the controller by the relay, according to the lines of forward.

Example 1:

-e>  bloh,@getxxxx=1234
<e-  bloh,@getxxx=1234,ok
<e-  1234,<viewer_chat_message>

Example 2:

-e>  bloh,!x-fwd/getxxxx
<e-  bloh,!x-fwd/getxxx,<viewer_chat_message>

Ending e-mail session and going to chat

-e>     blih,!x-email/clear
<e-     blih,!x-email/clear,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-email/clear,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

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

Requirements

On !x-email acknowledgement, the relay should start listening to e-mails and handle them like RLVR messages. 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, behaving exactly as if !x-forward had been issued.
!x-forward/clean must never be acted upon while in email mode (an appropriate answer is !x-forward/clean,ko).

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

Contents