Unique Identification of a SignalEvent

Is there any unique information in a SignalEvent or way to force Signals to include a server-created timestamp?

I’ve been working with Signal and SignalEvent and had thought rpcSessionId or creationTime were unique to the signal, but they are unique to the Connection.

As a result, it seems like signals generated from a client, such as say a chat message, must be the source of uniquely identifying information.

It seems like every signal should include a unique id and perhaps a creation timestamp generated on the openvidu server. This allows clients consuming the signal to not have to trust the creation time of a signal presented by another client.

Session.signal method offered by openvidu-browser is a quick, simple way of sharing non-secure information for the users connected to an OpenVidu session. I understand that you need some kind of information from the server side in all of those messages to know that they are truthful.
But this conflicts a little with the idea of this API, apart from not being clear how to add that information and what should be exactly added. The timestamp when the server did receive the message to broadcast from the client to know the order of the messages? Iff that’s the case then you can simply assume that the server re-sends every message as soon as it receives it, and always in order (that’s assured by the websocket JSON-RPC protocol communicating openvidu-server and clients). Or maybe you prefer an ID or something like that. But that ID could just be replicated by any client, so the message then could pass as a server-side one…

As you see it is not simple. If you really need to provide some kind of securly checked direct client-to-client communication system, then you should use your own channel separeted from OpenVidu.
A simple way of achieving this is to based it on HTTP calls from your clients to your application server, and then use the backend version of Session.signal to send a secure signal directly from openvidu-server. The SignalEvent triggered by a signal from the server does not contain the from field. That is the way you can know a signal is secure and its data fully build in your backend.

Thanks for the reply, Pablo.

I was looking for a way to ensure that I was not re-processing a chat message emitted, as I had thought I was getting duplicate events from:

session.on('signal:sendMessage', (event)

Now, I wonder if it was because I was using data that was being duplicated. I wonder, is the transactionID passed in here unique?

I still think it might be useful if the signals could have a timestamp, since that would act as a single source of truth for the replay of signals over time.

Without this, can you suggest a way to tag signals with time? Perhaps by ensuring the signals are included in CDR via something like this PR?

Is there a strong reason not to include timeStamp on signals the way CDREventSendMessage does currently?

The main concern I had with time is without the server stamping signals, chat messages rely on the time reporting of the client. Ignoring attempts to deceive, it seems like the client would still possibly mis-report the current time.

Without any server-owned sequential ID or timestamp wouldn’t this mean a “record” of the a conversation made up of signals might display data out of order?

Thanks for the idea on additional security. I suppose I am less worried about the security, since my users already authenticate to the server that shares the secret with my OV server.

Somewhat separately, I have other reasons for needing my clients to have very sync’d up client sessions. So I was also curious if there might be any easy time / clock client/server sync gets from ov browser, something like this?