Signaling: WHIP/WHEP superset over stateless HTTP, supporting custom low-frequency signaling.
Platform Support: Requires only basic WebRTC compatibility, targeting a wide range of devices, including embedded systems.
No TURN: Uses public host candidates with TLS (planned).
Ports: Single UDP and TCP port (planned).
Codecs: H.264 baseline (up to 4.1) and Opus for hardware acceleration.
Early project with a basic demo. Feedback and contributions welcome!
We don't have an example of CRDT with PulseBeam yet. But, CRDT itself is just a data structure, so you can use PulseBeam to communicate the sync ops (full or delta) with a data channel. Then, you can either use y.js or other CRDT libraries to manage the merging.
Yes, the plan is to use JWT for both the client and server side.
OIDC is not on the roadmap yet. But, I've been tinkering on the side related to this. I think something like an OIDC mapper to PulseBeam JWT can work here.
I'm not envisioning integrating into a decentralization ecosystem at this point. The scope is to provide a reliable service for 1:1 and small groups for other developers to build on top with centralization. So, something like Analytics, global segmented signaling (allow close peers to connect with edge servers, but allow them to connect to remote servers as well), authentication, and more network topology support.
That's correct, if the client is reachable by a public IPv6 (meaning the other peer has to also have a way to talk to an IPv6), then STUN and TURN are not needed. ICE is still needed but only used lightly for checking and selecting the candidate pair connections.
Yeah, if WebRTC is the only communication channel, TURN will be needed, especially doing p2p. LMK your experience if you have any questions, hit me up on discord @lherman_cs
Awesome! Yeah I have been doing WebRTC for a while and it's still always a pain to get this stuff up and manage it, I would love to hear what you're building and have you give it a try, feel free to hit me up on discord, username @lherman_cs
