[jitsi-dev] Endpoint to endpoint messaging over data channels


#1

Hello,

Earlier today I reverted the commits that move the statistics from XMPP presence to the data channel, because I see multiple problems and I think it would take changes to the majority of the code from the PRs to address them.

The main problem is that the current design of the JSON protocol we use between the bridge and endpoints is broken. It removes the encapsulation from the original message and forwards it as it is, forcing the user to do things like this[0], and also making it impossible to prevent spoofing (since any sender identification will have to be contained in the payload).

The other problems are with the lib-jitsi-meet API, both for sending a message and for the events which are fired on reception of a message.

Here's my proposal for how to fix these:

1. The protocol:
The format used by an endpoint to send a message can remain the same, i.e.:
{colibriClass: "EndpointMessage", to: <ENDPOINT-ID>, msgPayload: <PAYLOAD>}
Where an empty string for "to" indicates a broadcast, and PAYLOAD is a JSON-formatted string.

Handling by the bridge: the bridge forwards the whole JSON (and not just msgPayload) to the addressed endpoints, and also adds a "from" field:
{colibriClass: "EndpointMessage", to: <ENDPOINT-ID>, msgPayload: <PAYLOAD>, from: <FROM>}

The "to" field is preserved, to allow recipients to differentiate between broadcast and targeted messages.

The "from" field contains the ID of the endpoint corresponding to the data channel/SctpConnection that the message was received from. This allows receiving endpoints to verify the sender of a message based on the "from" field.

This will break existing implementations, but the required changes should be trivial, and I think it's important to fix.

2. Documentation:
The protocol needs to be documented in an md file.

3. The lib-jitsi-meet API for sending a message:
The API should allow sending of both targeted and broadcast messages since we're providing a library and it takes practically no extra effort to do so (given that broadcasting is a matter of setting a certain value for "to"). I suggest:
JitsiConference.sendColibriMessage(to, payload) and
JitsiConference.broadcastColibriMessage = function(payload) { sendColibriMessage("", payload);}

4. Receiving messages:
The library should handle messages with colibriClass: "EndpointMessage" as follows:
It reads the "from" field and finds the corresponding JitsiParticipant. It then fires an event (e.g. COLIBRI_MESSAGE_RECEIVED) with arguments (participant, message, broadcast) where:
participant is the JitsiParticipant
message is the value of the "msgPayload" field
broadcast = (message.to === "")

One remaining issue with this approach is that the user of the library is responsible for choosing the format of the messages. Maybe the library should define a certain format so that it can reserve an identifier and choose to terminate some of the messages. E.g. messages send over the lib-jitsi-meet API have the format: {name: NAME, value: VALUE}, and the library uses the "name" field to either use the message for its own needs (for a future use-case, e.g. if we decide that stats are to be handled in the library) or forwarded to the user. I am not sure whether this is worth implementing at this point.

Regards,
Boris

[0] https://github.com/jitsi/lib-jitsi-meet/pull/181/commits/dd24d1bee1245c50ff41e33f63bb4ffccc7897fb#diff-2251dcf0fd410d41d6b79d04b477d60eR264


#2

Hi,

Agree!

I'll change the implementation today with small changes that we discussed
offline. We will keep the current format of the messages (not sending
{name: NAME, values: VALUES} but JSON object). We'll also skip the
broadcast parameter from COLIBRI_MESSAGE_RECEIVED event because we were not
able to find a use case for it. If anybody thinks it is going to be useful
we can add it later.

The last open question is the names of interfaces in lib-jitsi-meet. In
Boris's proposal all the names contain "colibri" and in the old one the
names were almost the same except "colibri" was "datachannels". I think
that we should keep the "datachannel" version because the most important
difference between these messages and the commands is that we are using the
datachannels. Any other opinions? WDYT?

Regards,
Hristo.

···

On Thu, Jul 21, 2016 at 8:07 AM, Boris Grozev <boris@jitsi.org> wrote:

Hello,

Earlier today I reverted the commits that move the statistics from XMPP
presence to the data channel, because I see multiple problems and I think
it would take changes to the majority of the code from the PRs to address
them.

The main problem is that the current design of the JSON protocol we use
between the bridge and endpoints is broken. It removes the encapsulation
from the original message and forwards it as it is, forcing the user to do
things like this[0], and also making it impossible to prevent spoofing
(since any sender identification will have to be contained in the payload).

The other problems are with the lib-jitsi-meet API, both for sending a
message and for the events which are fired on reception of a message.

Here's my proposal for how to fix these:

1. The protocol:
The format used by an endpoint to send a message can remain the same, i.e.:
{colibriClass: "EndpointMessage", to: <ENDPOINT-ID>, msgPayload: <PAYLOAD>}
Where an empty string for "to" indicates a broadcast, and PAYLOAD is a
JSON-formatted string.

Handling by the bridge: the bridge forwards the whole JSON (and not just
msgPayload) to the addressed endpoints, and also adds a "from" field:
{colibriClass: "EndpointMessage", to: <ENDPOINT-ID>, msgPayload:
<PAYLOAD>, from: <FROM>}

The "to" field is preserved, to allow recipients to differentiate between
broadcast and targeted messages.

The "from" field contains the ID of the endpoint corresponding to the data
channel/SctpConnection that the message was received from. This allows
receiving endpoints to verify the sender of a message based on the "from"
field.

This will break existing implementations, but the required changes should
be trivial, and I think it's important to fix.

2. Documentation:
The protocol needs to be documented in an md file.

3. The lib-jitsi-meet API for sending a message:
The API should allow sending of both targeted and broadcast messages since
we're providing a library and it takes practically no extra effort to do so
(given that broadcasting is a matter of setting a certain value for "to").
I suggest:
JitsiConference.sendColibriMessage(to, payload) and
JitsiConference.broadcastColibriMessage = function(payload) {
sendColibriMessage("", payload);}

4. Receiving messages:
The library should handle messages with colibriClass: "EndpointMessage" as
follows:
It reads the "from" field and finds the corresponding JitsiParticipant. It
then fires an event (e.g. COLIBRI_MESSAGE_RECEIVED) with arguments
(participant, message, broadcast) where:
participant is the JitsiParticipant
message is the value of the "msgPayload" field
broadcast = (message.to === "")

One remaining issue with this approach is that the user of the library is
responsible for choosing the format of the messages. Maybe the library
should define a certain format so that it can reserve an identifier and
choose to terminate some of the messages. E.g. messages send over the
lib-jitsi-meet API have the format: {name: NAME, value: VALUE}, and the
library uses the "name" field to either use the message for its own needs
(for a future use-case, e.g. if we decide that stats are to be handled in
the library) or forwarded to the user. I am not sure whether this is worth
implementing at this point.

Regards,
Boris

[0]
https://github.com/jitsi/lib-jitsi-meet/pull/181/commits/dd24d1bee1245c50ff41e33f63bb4ffccc7897fb#diff-2251dcf0fd410d41d6b79d04b477d60eR264

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.


#3

Hi Hristo,

The last open question is the names of interfaces in lib-jitsi-meet. In Boris's proposal all the names contain "colibri" and in the old one the names were almost the same except "colibri" was "datachannels". I think that we should keep the "datachannel" version because the most important difference between these messages and the commands is that we are using the datachannels. Any other opinions? WDYT?

I agree that we should avoid using the string “colibri" in the API methods since this had nothing to do with colibri and it might lead to confusion. "Datachannel” seems more appropriate.

Another idea would be JitsiConference.sendEndpointMessage JitsiConference.broadcastEndpointMessage, as “EndpointMessage” is the “colibriClass” of the data channel message that is being sent.

Cheers,
George


#4

sgtm. i think the user being able to decide the format of the message (and
neither the library nor the bridge caring) is a plus...that way it's
generic and can handle any sort of message the user may want to send (which
could vary quite a bit from application to application).

···

On Thu, Jul 21, 2016 at 7:53 AM, George Politis <gp@jitsi.org> wrote:

Hi Hristo,

> The last open question is the names of interfaces in lib-jitsi-meet. In
Boris's proposal all the names contain "colibri" and in the old one the
names were almost the same except "colibri" was "datachannels". I think
that we should keep the "datachannel" version because the most important
difference between these messages and the commands is that we are using the
datachannels. Any other opinions? WDYT?

I agree that we should avoid using the string “colibri" in the API methods
since this had nothing to do with colibri and it might lead to confusion.
"Datachannel” seems more appropriate.

Another idea would be JitsiConference.sendEndpointMessage
JitsiConference.broadcastEndpointMessage, as “EndpointMessage” is the
“colibriClass” of the data channel message that is being sent.

Cheers,
George
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi George,

Hi Hristo,

> The last open question is the names of interfaces in lib-jitsi-meet. In
Boris's proposal all the names contain "colibri" and in the old one the
names were almost the same except "colibri" was "datachannels". I think
that we should keep the "datachannel" version because the most important
difference between these messages and the commands is that we are using the
datachannels. Any other opinions? WDYT?

I agree that we should avoid using the string “colibri" in the API methods
since this had nothing to do with colibri and it might lead to confusion.
"Datachannel” seems more appropriate.

Another idea would be JitsiConference.sendEndpointMessage
JitsiConference.broadcastEndpointMessage, as “EndpointMessage” is the
“colibriClass” of the data channel message that is being sent.

+1 from me for JitsiConference.sendEndpointMessage and
JitsiConference.broadcastEndpointMessage.

···

On Thu, Jul 21, 2016 at 9:53 AM, George Politis <gp@jitsi.org> wrote:

Cheers,
George
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.


#6

sendJSONDataChannelMessage and broadcastJSONDataChannelMessage?

Just a thought.

···

On Jul 21, 2016, at 6:36 PM, Hristo Terezov <hristo@jitsi.org> wrote:

Hi George,

On Thu, Jul 21, 2016 at 9:53 AM, George Politis <gp@jitsi.org> wrote:
Hi Hristo,

> The last open question is the names of interfaces in lib-jitsi-meet. In Boris's proposal all the names contain "colibri" and in the old one the names were almost the same except "colibri" was "datachannels". I think that we should keep the "datachannel" version because the most important difference between these messages and the commands is that we are using the datachannels. Any other opinions? WDYT?

I agree that we should avoid using the string “colibri" in the API methods since this had nothing to do with colibri and it might lead to confusion. "Datachannel” seems more appropriate.

Another idea would be JitsiConference.sendEndpointMessage JitsiConference.broadcastEndpointMessage, as “EndpointMessage” is the “colibriClass” of the data channel message that is being sent.

+1 from me for JitsiConference.sendEndpointMessage and JitsiConference.broadcastEndpointMessage.

Cheers,
George
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hey Hristo,

Thanks for taking care of this so quickly!

Boris

···

On 21/07/16 18:36, Hristo Terezov wrote:

Hi George,

On Thu, Jul 21, 2016 at 9:53 AM, George Politis <gp@jitsi.org > <mailto:gp@jitsi.org>> wrote:

    Hi Hristo,

    > The last open question is the names of interfaces in lib-jitsi-meet. In Boris's proposal all the names contain "colibri" and in the old one the names were almost the same except "colibri" was "datachannels". I think that we should keep the "datachannel" version because the most important difference between these messages and the commands is that we are using the datachannels. Any other opinions? WDYT?

    I agree that we should avoid using the string “colibri" in the API
    methods since this had nothing to do with colibri and it might lead
    to confusion. "Datachannel” seems more appropriate.

    Another idea would be JitsiConference.sendEndpointMessage
    JitsiConference.broadcastEndpointMessage, as “EndpointMessage” is
    the “colibriClass” of the data channel message that is being sent.

+1 from me for JitsiConference.sendEndpointMessage and
JitsiConference.broadcastEndpointMessage.

    Cheers,
    George
    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

--
Regards,
Hristo.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev