I read the part about p2p and quality in your description "If you are on a call with up to 4 participants, your voice and video are also only shared P2P. For calls with more than 4 participants, we use a cloud infrastructure in order to maintain the call quality"
Just curious what's the limiting factor of p2p here. I always read comments like Signal has better voice quality than WhatsApp due to p2p etc, and I'm not very well versed on the subject.
The limiting factor is that on a P2P mesh with N participants, each participant sends its stream to all other participants (to N-1 destinations) and receives the stream from all other participants (receives N-1 streams), which incurs on more network and CPU requirements.
When we go above 4 participants the call model changes to Single-Forwarding-Unit (SFU) where there is a central server that dispatches the different streams to each user. That way, each participant would only upload their stream once, and download N-1 streams back. This server may also apply some other optimizations. You can learn more about P2P limitations from this blog post. [1]
That said, as this CoBrowsing experience is not as bandwith intensive as a 30fps high-quality video, we can afford to use P2P with more than 4 participants.
[1] https://bloggeek.me/webrtc-p2p-mesh/
Edit: btw, we use daily.co for the video and audio part of our product. They abstract very well all the complexity related with real-time video and audio.
We built this Chrome Extension as an alternative to screensharing. The big difference vs "video screen-sharing" besides bandwith and latency is the interactivity. Duckly recreates and keeps in sync the DOM from the shared site to an iframe on the other peers so it feels like you're browsing the remote site from your own browser. We use it a lot for sharing pages hosted on localhost and writing emails or browsing kanban boards together.
This extension has been built by mainly leveraging MutationObserver APIs [1], Chrome Extension APIs, a lot of browser events, and WebRTC! All the data is always sent with P2P and E2E encrypted with WebRTC, so it never touches any kind of server. You can read more details of how it works internally on the "How does it work?" section here [2].
Btw, we launched here 8 months ago as GitDuck [3], we decided to change the name to Duckly because other profiles than developers started using it (or could be using but the tool was marketed for developers only) [4]. As a nice side-effect, we get rid of the possible conflict with Git's trademark [5].
Let us know us know what you think!
[1] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
[2] https://duckly.com/blog/cobrowsing-interactive-screen-sharin...
[3] https://news.ycombinator.com/item?id=24228826
[4] https://duckly.com/blog/gitduck-is-now-duckly/
[5] https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
