[jpgneves]

Hi, I'm João, one of the co-authors of this post!

Regarding mediasoup, their Rust effort so far has focused mostly on the server side of things, whereas for this particular project we would be looking more towards the client side.

That would definitely be something we are considering contributing to, as it would, as you say, drop quite a significant amount of C++ (with additional benefits on the web side, too).

[7sidedmarble]

I'm curious about the approach you guys are taking here. The client side of doing WebRTC is by far the easiest part. Maintaining separate client side implementations for mobile and web is... no harder then maintaining a web and mobile app separately anyways.

The server side is the hard part to work on. Also, one of the downsides of wasm is that it can be a pain to communicate out to the JS APIs, especially for doing lots of DOM manipulation. I'm not sure how sound this approach is really. It seems like you're going to do a lot of extra work in order to solve a problem that isn't much of a problem in the first place.

[kwindla]

I would say that both the client and the media server (SFU) side of the work are challenging in their own ways, if you are trying to support a large variety of use cases, features, and sessions with large numbers of participants.

The client-side and server-side code end up being tightly coupled and you end up having a lot more client-side code than maybe is obvious if you're building an application that uses WebRTC in one specific way. For example, handling fast subscription to and un-subscription from batches of tracks is non-trivial, but important if you're implementing "grid mode" client views.

The goal of the approach we're taking here is to be able to support a bunch of different platforms at the same level of performance, stability, and feature parity. Web, iOS, and Android are the three most important platforms. But people are also using WebRTC on Flutter, native Linux, macOS, Windows, Unreal, Unity, and various embedded platforms.