buffer VS simple-peer

If someone is a web dev this could probably explain this better than me but here it goes. This does NOT mean Feross has ANYTHING to do with the site. Feross published an open-source module (https://github.com/feross/buffer) for node.js that this site happens to use. There is likely 0 relation between the website and Feross considering that thousands of other websites use this module.

Thanks for trying it out!

The frontend is built with Svelte. This was my first time using the framework and I found their website super helpful: https://svelte.dev/docs

Used Mapbox API and geolib (https://github.com/manuelbieh/geolib/) for building routes and for other geospatial tasks.

"Talkie" was built with simple-peer (https://github.com/feross/simple-peer) and WebRTC. Great tutorial can be found on MDN: https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRT...

On the backend I use Vercel's serverless functions which are mostly acting as trivial proxies for various open API's.

Feel free to email me if you need more info.

I use simple-peer package: https://github.com/feross/simple-peer. They got good documentation and examples to get started. One thing is that you need to know more about creating signaling server to establish connection between peers - I use socket.io for that.

I am trying to implement a video chat app using simple-peer library. I am using the stream channel to exchange webCam videos of peers. And for text messaging I am using the data channel from simple peer. I implemented the video streaming part using the stream channel and it works perfect as I wanted to. But when I tried to add the text chat functionality and used the data channel to exchange messages between peers the stream channel does not work fine and all the socket connection between peers breaks up. Also again if I remove the data channel snippet from the code everything works fine. I also raised an issue on simple-peer's repo: https://github.com/feross/simple-peer/issues/899

Our team got off the ground really quickly using https://github.com/feross/simple-peer to handle the majority of the WebRTC client implementation. We're sending video and voice, so websockets aren't feasible. I'd say it was a lot easier than I expected coming in cold, and about 95% of connections establish quickly and don't have any problems.

However for that remaining 5%, I have a lot to learn. Using an abstraction is great when it works, but I'm interested in going through OP's project to get a better sense of what's happening when things go wrong.

For the VoIP part you would look up tutorials on creating your own VoIP server and clients. This is the part where you would have to research a ton when you're not familiar with a technology. Looking into it a bit, CrewLink seems to mainly use a library called simple-peer to connect people together and pass audio between them.

It is using the simple-peer library to manage the peer connections. You can open the share url in a separate tab if you want to try it locally. If you know how to use the developer tools you can see it is not uploading to a server. The only thing my server is doing is creating a websocket connection initiating the peer connection then it closes the socket. Everything else is done on the browser without the need of a server.

Custom peer-to-peer video call implementation can also be done using vanilla webrtc or https://github.com/feross/simple-peer but using an SFU such as Janus can help

Not an expert here but have some experience with it:

Assuming that each peer is connected to every other peer via a mesh network [see this image for reference: https://github.com/feross/simple-peer/blob/master/img/full-m...], each outgoing stream (esp. audio / video) is likely going to be duplicated, per recipient.

Scalability over a mesh network is fully dependent on CPU and network performance of all of the connected devices, and I'd doubt it could handle 12 participants if there is video involved, unless all participants are running relatively high-end and modern devices, with optimal network conditions.

You'll need a SFU or an MFU running on the server to handle larger rooms, while enabling all connected devices to only have to send one output stream per media type, regardless of how many connected participants there are.