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

[giomfo]

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)

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

[giomfo]

Design answer: "Let’s use the same as for a message. It doesn’t need to be in a tile
Optionally, we may adapt the error text with : “** Déchiffrement impossible : La session de l’expéditeur ne nous a pas envoyé les clés pour ce voice broadcast”.

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 “Unable to decrypt ...”. 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)