Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let the user know when we are not able to decrypt the voice broadcast chunks #7820

Closed
giomfo opened this issue Dec 19, 2022 · 1 comment
Closed
Assignees
Labels
A-Voice Broadcast Broadcast-style voice messages O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements Z-UI UX

Comments

@giomfo
Copy link
Member

giomfo commented Dec 19, 2022

Your use case

What would you like to do?

The current voice broadcast implementation is description in this discussion.
In case of an encrypted room, the voice broadcast is controlled by unencrypted state events, but its data (the audio chunks) are handled by encrypted events.

Why would you like to do it?

Currently when the user opens a room where there is a voice broadcast for which the encryption keys are not available, we display a tile with an empty voice broadcast, followed by several UTD messages (some of them are the encrypted audio chunks)
image

How would you like to achieve it?

I suggest displaying an error or a message in the voice broadcast tile when the data are not decrypted

An additional question :
How do we want to handle a voice broadcast partially decrypted? Should we consider it in failure or not?

  • I would consider it in failure mode to ease the implementation, and avoid the design of too many use cases which should be unusual

Have you considered any alternatives?

No response

Additional context

No response

Are you willing to provide a PR?

Yes

@giomfo giomfo added T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements A-Voice Broadcast Broadcast-style voice messages labels Dec 19, 2022
@RiotRobot RiotRobot added this to Incoming in Issue triage Dec 19, 2022
@yostyle yostyle moved this from Incoming to Need info in Issue triage Dec 21, 2022
@yostyle yostyle added S-Minor Impairs non-critical functionality or suitable workarounds exist O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience labels Dec 21, 2022
@giomfo
Copy link
Member Author

giomfo commented Jan 18, 2023

Design answer: "Let’s use the same as for a message but with the following text: “Unable to decrypt voice broadcast” It doesn’t need to be in a tile"

We will focus here on 2 uses cases, that we consider more important:

  • I open a room with existing VB for which I'm not able to decrypt the audio chunks
  • I join an encrypted room while a VB is in progress, and I don't have keys for the first chunks

In this 2 use cases,

  • we should replace the tile with “You cannot access this message” or if it's possible “You cannot access this voice broadcast”. In the second case, we should do the same as other messages sent before you joined (or were invited)
  • we should hide the VB audio chunks (encrypted or decrypted ones)

In the other cases, for example if you suddenly failed to decrypt a chunk, we will keep displaying the tile.

To sum up, we will replace (hide) the VB tile as soon as we aren't able to decrypt the first audio chunk (This chunk will be detected by using the m.reference type in the m.relates_to block of the original event)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Voice Broadcast Broadcast-style voice messages O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Minor Impairs non-critical functionality or suitable workarounds exist T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements Z-UI UX
Projects
No open projects
Development

No branches or pull requests

2 participants