[potmat]

> it may use a custom API that does not line up with the spec

Not sure about that, but it's been working brilliantly for me so far.

> API compatible with browser RTCPeerConnection

Fair enough, though I'd be curious what you'd be doing with Node not in a browser that requires this...

> Also, when you say native, I guess you mean just in Node, right?

Yeah, sorry I guess "native" was the wrong word there.

> C++ or wasm binaries are going to be faster

True, but if you are trying to distribute your NPM package to lots of users, and it requires platform specific binaries or, God help us, node-gyp, you're in for a lot of GitHub issues :)

[keepamovin]

RTCPeerConnection is central to WebRTC, it's the main p2p connection. In Node you use the same thing. The server is just another "peer". We wrap @roamhq/wrtc with SimplePeer, which, funnily enough heh, greatly simplifies things! :) RTCPeerConnection is central to simple peer.

The other library does say it has a different API, on its homepage: Easy to Use - The API design is similar to the browser's WebRTC API, which reduces the learning cost.

From: https://shinyoshiaki.github.io/werift-webrtc/website/build/

Regarding native binaries we have not had any issues so far, mainly as the prior major wrtc provided pre-built binaries for every major platform. I think the new one posted here expands the set of targets.

I do recall encountering a few obstacles with various addons from different libraries in different projects in the past, and node-gyp was occasionally involved. Tho I don't recall it being particularly troublesome, nor preventing us doing what we wanted. In fact I fondly recall node-pre-gyp or whatever usefully creating a build for the current target on the fly on install, which was fantastic and convenient, magic.

In the worst case to build for a custom arch, I consider these types of things a configuration issue, nothing insurmountable.

Stepping back, I think a lot of these concerns will eventually go away, or you can currently make them go away, with wasm. Which, while not at C++ perf level, is adequate and a significant speedup on node for some computationally intensive tasks.

I'm interested to know more about what particular issues have you had with native addons and node-gyp in the past and what you are currently using WebRTC for, if you're interested to share.

[potmat]

I maintain a Homebridge (community built system to bridge IoT devices to Apple HomeKit) plugin for Google Nest devices. The newer Nest cams use WebRTC for video streaming. This makes viewing the cameras in Apple Home a bit complex, as the bridge must setup and connect to a WebRTC stream, transcode it, and then send it out to your iPhone etc. as an RTSP stream.

https://github.com/potmat/homebridge-google-nest-sdm

Since this is for home automation the system runs on all kinds of weird devices, from RPi's to NAS's to old laptops etc. When I tried to use anything requiring platform specific binaries it was a complete mess, most of the time things would not build.

The problem may not be insurmountable if you're being paid, but since this is just done in my spare time it's not something I wanted to deal with.

[keepamovin]

Completely understand, yeah. It is annoying trying to get those builds to work! You'd rather just do something that slips right in. It's always good to shop around and find the lib that best suits your purpose!

Cool, these home automation projects seems pretty nifty, and like a compelling rabbithole where you can just keep adding stuff. Your set up sounds like a big project, well done! It's cool you created a whole streaming stack for this. The use of a dedicated streaming RTSP server is a high level of technical sophistication!