Closed ok300 closed 1 week ago
Mediasoup, an SFU (Selective Forwarding Unit), does not natively offer end-to-end encryption (E2EE) by default for streams. In an SFU architecture like mediasoup's, the server forwards media streams between participants without fully decrypting them. Mediasoup ensures that the communication between the client and the server is encrypted using DTLS-SRTP, which protects the streams from being tampered with or intercepted during transmission. However, the server itself does have access to the decrypted media streams.
To achieve true end-to-end encryption (where only the clients can decrypt the streams and not the server), additional measures are required, such as implementing a custom encryption layer on top of the media streams. For example, you can apply client-side encryption, where participants encrypt and decrypt their streams before sending and receiving them from the SFU, so the server only handles encrypted data without the ability to decrypt it.
This can be implemented using WebRTC's Insertable Streams API, which allows developers to control and process media before it is sent or after it is received, ensuring that the encryption remains intact during the SFU's forwarding process.
at this time we do not plan on implementing E2EE until we have addressed all other nostr and UX issues. E2EE may be considered further down the timeline, 6+ months from now contingent on user demand.
The Privacy page^1 mentions the mediasoup integration:
Are the streams E2E encrypted, i.e. participant to participant, or do they terminate at the mediasoup server, where they're re-encrypted for the receiver?