Replace custom-room-events with toDevice messages for embedded widget mode end-to-end encryption

[fkwp]

Context

Following up on #1350 and limitations on the (rust) widget API

We want e2ee in embedded mode but need to share the keys in a way that the widget can access them via the rust widget driver, which is in a fairly early stage. We would like this to work without being blocked by too much widget api work.

Our original design has EC send the media key as a room event, then include the event ID of this room event in the call membership event. Other clients can then use the context (get_by_id) API to fetch this event if they don’t already have it. The problem with this is that it requires implementing get_by_id in the widget API which is non-trivial.

Some suggestions were to flip the relation and use the relations API (which we already have) to fetch the event. This would involve posting another, separate state event (because the ID of our call membership event would keep changing) that we can use as a relationship root. This would be a relatively significant change to the protocol to work around our lack of impl though.

Thought experiment: could we get by for now just not having a way to fetch the key if it wasn’t already in our backfill? Answer: probably not: it would break if someone tried to join an ongoing call, having not had their client open, and where there had been some amount of chatter in the room since the start of the call. This might be rare-ish but would still be flakeyness which we must avoid. However, this would avoid us having to make any protocol changes and would let us get the product out of the door without being blocked on adding get_by_id to the widget API.

A more blunt workaround would be to simply re-send the media key event whenever a new member joins the call. This would ensure that new membership could always see the key, at the cost of a lot more traffic. This would be okay for small rooms though.

A variation on this would be to have this fallback mechanism instead work via to_device messages: that way, our primary key distribution happens via rooms events and then the fallback happens via to_device. We can skip straight to our ultimate intended solution for the fallback mechanism (ie. to_device messages) and avoid having to write code that gets thrown away, and it would only fail if both the room event was not visible and the to_device message failed which should be quite a narrow scope.

However, we also currently lack to_device messages in the rust widget API, so we’d block ourselves behind this. For this reason, we opt for the blunt workaround of re-sending the room event whenever we see a member join the call.

we need to replace custom room events with toDevice messages for individual sender keys distribution in order to preserve PFS and PCS.

Have you considered any alternatives?

No response

Additional context

No response