Jitter evaluation, as an alert trigger, was changed in 3.0 to get the internal
average jitter used in the conn-status component data (which is total jitter
delay divided by jitterbuffer emit events). This was done accidentally and that
metric is _very_ different from the one used in 2.7 (point-in-time jitter from
remote-inbound-rtp/inbound-rtp, highest on the interval, gathered on
/utils/stats.js). The alert thresholds were preserved, which makes it overly
sensitive in regards to jitter (and thus causes it to be critical whenever the
user is in audio).
Remove jitter as a connection status alert trigger, which fixes the
false positive. The implementation on <= 2.7 is also not ideal - if
anything, it generates false negatives. That's why I'm removing jitter for
the time being since it's ill-suited (at least in the way it's used)
for what we want to achieve.
* feat(graphql-server): add new view `v_chat_private_read_feedback`
Adds a view called `v_chat_private_read_feedback` to retrieve the last seen time
of the recipient of a private chat.
* refactor(chat): removes unused prop `lastSeenAt`
* feat(private-chat): message read confirmation feedback
Adds message read confirmation feedback feature to private chats.
This feature uses the private chat recipient's `lastSeenAt' attribute to
check which messages were read. Messages read are show in the chat with
a check icon next to it.
Feature behind a flag in settings.yml, which is disabled by default:
- `public.chat.privateMessageReadFeedback.enabled`
* fix(chat): poll chart message
Fixes poll chart message which was not using the full chat width due to
previous changes in chat messages `flex-direction`.
* fix: adds missing initial value for `privateMessageReadFeedback`
* fix: linter errors
* fix(chat): add `recipientHasSeen` property to existing view
This commit changes the way the messages read by the recipient are
tracked. The previous strategy required the client to calculate the read
messages and as a consequence all messages of the given chat
were re-rendered every time the recipient `lastSeenAt` time
changed. The current strategy consists of calculating the read messages
on the server(based on recipient `lastSeenAt`) and just expose to the
client a boolean(`recipientHasSeen`) for each message that indicates whether
it has already been read or not.
* fix: typo in message description
* fix: typo in settings flag
* fix: vertically align icon
