MSC4143: MatrixRTC – Real-time communication over Matrix - #4143
Conversation
d717c0b to
cff8291
Compare
turt2live
added
A-VOIP
Signed-off-by: Timo K <toger5@hotmail.de>
| The recipient devices are determined from the `m.rtc.member` events that are considered to be | ||
| joined to the slot. The conditions for considering a member joined were given | ||
| [above](#joining-a-slot). Once the member events are determined, the `m.rtc.encryption_key` | ||
| to-device messages are sent to the devices that were used to encrypt these member events. |
There was a problem hiding this comment.
Is this obvious how to do correctly? Given that e.g. device_id and sender_key are untrusted and shouldn't really be used? Might want to be explicit here if this is a non-standard thing to do
There was a problem hiding this comment.
We had detailed steps for how to do this in #4516 but @BillCarsonFr preferred to not put these into the MSC because this is a general gap in the spec that's covered in https://github.com/element-hq/crypto-internal/issues/422. So I think it's a standard thing to do but the spec is lacking clear wording for how to do it correctly. I'd suggest to keep the MSC as is and solve https://github.com/element-hq/crypto-internal/issues/422 separately.
|
|
||
| When joining a slot, clients generate a 32-byte key by using a cryptographically secure pseudorandom | ||
| number generator. They then share the key with other clients joined to the slot by sending encrypted | ||
| to-device messages of the type `m.rtc.encryption_key`. |
There was a problem hiding this comment.
Do we need to worry about missed to-device messages? I think megolm allows rerequesting keys in case of wedged OLM session?
There was a problem hiding this comment.
There is no re-requesting of RTC keys, and for now no plan to support it in the future.
This behavior in megolm is also pretty much deprecated.
| - `key` (required, string): The key (32 bytes) encoded as specified by `format`. | ||
| - `index` (required, number): The rolling index of the key to distinguish it from other keys. The | ||
| value MUST be between 0 and 255 inclusive. WebRTC-based transports may use this as the `keyID` | ||
| field of [SFrame](https://www.w3.org/TR/webrtc-encoded-transform/#sframe) headers. |
There was a problem hiding this comment.
What happens if index reaches 255?
| are defined by the transport's specification. This could, for instance, include WebSocket URLs. | ||
| The transport's specification would be as per its [MSC4519] registration. | ||
| - `can_subscribe` (array): An array of transport types that the member is able to subscribe to. | ||
| Other members can use this as cue for deciding which transports to use to accommodate this member. |
There was a problem hiding this comment.
Do we also need a section for how transports work in the abstract? Like how does a client choose which one to use? What happens if there is no overlap of supported transport types?
Also it says can_subscribe can be used to decide what transports to start to accommodate other members? But wouldn't you want to have every type you support published anyway? Or does everyone join initially with empty published and then decides what to publish?
There was a problem hiding this comment.
Do we also need a section for how
transportswork in the abstract? Like how does a client choose which one to use? What happens if there is no overlap of supported transport types?
Yes, good point. Our thinking was to offload any negotiation or consensus for choosing transports to a future MSC. Right now we only have one transport (LiveKit). How exactly clients agree on which transport to choose depends on what transports are available. So I think we cannot prescribe that generically. The future MSC that introduces the second transport will need to cover how clients choose between LiveKit and the new transport and what happens if there is no overlap in client support.
But wouldn't you want to have every type you support published anyway? Or does everyone join initially with empty
publishedand then decides what to publish?
No, I think you wouldn't. Publishing a transport will usually incur some amount of cost (traffic, processing, etc.) on clients. So you clients have an interest to only publish transports that are actually needed.
Have tried to clarify both in d6133e4.
|
|
||
| #### Distributing keys | ||
|
|
||
| When joining a slot, clients generate a 32-byte key by using a cryptographically secure random |
There was a problem hiding this comment.
[non-blocking] To support future encryption mechanisms that want more entropy, I would suggest either saying that:
- 32 bytes is the minimum, but clients could generate more bytes. (Transports might need to specify what to do with excess bytes, but it shouldn't cause a problem for transports that use HKDF.), or
- clients should generate the number of bytes specified by the transport that they're publishing to (or the maximum of the number of bytes specified by the transports).
20 participants
Rendered
Pull Request Checklist
#matrix-spec:matrix.org to
get feedback on this PR.
SCT Stuff:
MSC Checklist
FCP tickyboxes