Desync can cause users to hear others when they have their whisper bubbles enabled

[epicEaston197]

Describe the bug?

If someone else turns on whisper mode and another user is Desynced they will still be able to hear the user that has their bubble on

To Reproduce

Go into a populated world (preferably australia) there will always be a user that will be desynced and we'll be able to hear others when they have their bubbles enabled

Expected behavior

whisper bubble should have some network priority so it maintains functionality

Screenshots

No response

Resonite Version Number

2024.4.3.1170

What Platforms does this occur on?

Windows

What headset if any do you use?

Desktop

Log Files

It didn't happen to me it happened to another user so I just thought I would note it down here

Additional Context

No response

Reporters

@epicEaston197

[ProbablePrime]

As a reminder, whisper mode is not a secure communication channel and should be used literally. You want to whisper something to someone in a public space? That's what it is for, not secure communications.

[shiftyscales]

By "desync" do you mean that the user has queued packets, @epicEaston197?

If so, the solution to this issue would be mitigating resolving that as an underlying issue.

Frooxius had some recommendations on the topic in here: #1324 (comment) and here #1324 (comment).

[epicEaston197]

queued packets

Yes queued packets

[epicEaston197]

As a reminder, whisper mode is not a secure communication channel and should be used literally. You want to whisper something to someone in a public space? That's what it is for, not secure communications.

I am aware that's why I said nothing about secure communication in the original issue I just wanted to note it down as
a "this is a thing that can happen and people should probably be aware of it"

[Frooxius]

There's a few things:

• Like Prime said, whisper is not designed as privacy feature, but more accessibility
• We do want to focus on resolving queued packets where possible
• This is a bit tricky issue, but there are some things that are planned to do - selectively sending stream data to users. This would make the user indicate who gets their voice data based on their own state, so if they see someone as outside the whisper bubble, they will not send voice data in them. This would improve these kinds of degraded situations, while also improving network performance

[shiftyscales]

I think with that feedback I'll re-label this issue as an enhancement item then.

[TisFoolish]

This is a bit tricky issue, but there are some things that are planned to do - selectively sending stream data to users. This would make the user indicate who gets their voice data based on their own state, so if they see someone as outside the whisper bubble, they will not send voice data in them. This would improve these kinds of degraded situations, while also improving network performance

Will this also also make it harder for others to eves drop as well? EG if someone is parented under a slot that is only enabled for themselves and then enters a whisper bubble, will they still be able to hear the whispered audio or will they not be able to because to the whisperer the hidden user isn't there?

[Frooxius]

Yes it'll make it harder to eavesdrop. You'd only be able to do it if the host client was modified to send the data to everyone or if the host wanted to eavesdrop.

[Stellanora64]

This also happens when a user is muted, as it works by disabling the component which then becomes a queued packet, thus when someone is queueing packets they hear a person when they are ment to be mute, and then later that user becomes muted when they are no longer muted.

This issue, along with other issues related to queued packets, was already discussed here: #120

[epicEaston197]

This also happens when a user is muted, as it works by disabling the component which then becomes a queued packet, thus when someone is queueing packets they hear a person when they are ment to be mute, and then later that user becomes muted when they are no longer muted.

This issue, along with other issues related to queued packets, was already discussed here: #120

I think this is fit for separate issue

[JackTheFoxOtter]

I think this is fit for separate issue

I mean, it's basically the same underlying issue, isn't it?

[Frooxius]

@Stellanora64 Were you able to actually replicate that?

When user mutes themselves on the dash, we actually stop their audio at the driver level completely. This makes it that it doesn't matter if they're queued or not - there's no audio data at all for the period they're muted.

If you are still hearing users when they have muted themselves, this would indicate there is something wrong with the mechanism, which should be a separate report.

[Stellanora64]

@Frooxius Yes, or at least of what I remember (I can confirm the muting after someone has muted, as that happens regularly to me, due to the aforementioned component disabling). I don't have any logs or videos reproducing it so I won't be able to create an issue for it yet. I will try and reproduce it and create an issue for it during the CJ tomorrow as I'm consistently desynced there.