Does this lib support E2ee implementation?

Does this lib support E2ee implementation?

im trying to do the same as here :


I’ve responded on GitHub but we can continue the conversation here.

Thanks for responding, is Insertable Streams and the frame cryptor hard to implement?
we really need this feature and we can contribute if you are plan to work on it

We are ready to finiancialy support this feature @8BallBomBom

Implementation of such features would take quite a bit of effort.
As for financial help towards the organisation, best to talk with @saghul about that :+1:

But we are open to contributions and would help push things along if any code were to be committed.
If you check over here you’ll see an implementation of the features you are looking for not that long ago. Some code could potentially be ported over due to similarities but there would also need to be refactoring along with implementations of the missing parts.

1 Like

I’m happy to get the some code done as long as its not related to C++ because i saw an issue on github repo has a planty of C++ and got confused, so is this C++ need ot be written by us?

also is the base done from the native side - google android & ios code for webrtc or it has no base there too?


Unless we decide to go down the lines of rewriting the entire project to be C++ for the new React Native Architecture which might bring some performance benefits and also mean less varieties of languages.
You probably wouldn’t need to be touching any C++ code.

Far as i’m aware mostly just Java and Objective C implementations bridging to WebRTC.
Along with some TypeScript to bring everything together.

Take everything i’ve said with a grain of salt, research to be 100% accurate would need to be conducted. But either way, them features would require a pretty large undertaking.

Hey folks,

We (Jitsi) also want this and have attempted to tackle it in the past, but for various reasons had to drop the effort. We hope to get back to it later in the year though.

The insertable streams API is not feasible IMHO, so the plan was to create some setEncryptor and setDecryptor APIs in senders and receivers respectively. This is pretty much what the native API is.

In orderr to be able to use this those would need to be implemented in C++ as part of our WebRTC build. THis is mostly for perforemance and because the Android API is just a thin JNI wrapper that takes a pointer to the C++ object. They would follow the SFrame semantics, so the applications can implement the same in JS.

Hey saghul,

Can you please mention some of the reasons so we know what we are dealing with?

Also i saw in the native API there is setFrameEncryptor and setFrameDecryptor inside Rtpsender and Rtpreciever

So what are these? Are they different than what you mentioned?

It’s just complex and requires time.

Nope, those are the APIs I meant.

So this setFrameEncryptor takes an object from type FrameEncryptor. Is this where the c++ comes in? If yes then our start is gonna be with the c++ :sweat_smile:

do you have any idea if Signal Protocol/ Whatsapp uses SFrame or another approach for e2ee for calls?

Yes, that’s where the C++ part comes in.


Sorry for too much questions but im trying to collect more info as i can.
Whats the benefit of doing our own e2ee for calls when the webrtc using SRTP already provide encryption?

@saghul thanks

SRTP is hop by hop (ie, your SFU will decrupt the packets), that’s why
E2EE is useful.

Glad i brought salt, wasn’t entirely aware of how much C++ code would be required, caught me by surprise though as always :smile: What might be worth looking into is whether way way way down the line we convert over to the new architecture. Only thing which keeps giving me a bit of push back is the fact all of that is marked as experimental currently.

what about MESH? is there any need for E2EE?

Yeah its the C++ code what makes it harder. anyway, away from E2EE what does the convertion of this library to the new architecture required? is it too much work?

Update: never mind i took a look and it seems too much work :joy:

Less so, but you can change the path of a video stream mid conference and the browser won’t warn you.


1 Like

Authorizing call members will not handle that?