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?