Very neat. Nice to see more free and easy p2p stuff. Getting a p2p video/audio/screen share application going is definitely a lot less work than it once was. https://teamvideo.app/

webRTC stuff has a ton of cool potential for p2p projects, hopefully more and more of it starts cropping up.

The issue is that webrtc is very complex, bloated and hard to debug. It’s the only way to do browser based p2p though.

Plug: I’m working on a much simpler server-assisted p2p lib with relay fallback, over tcp, with BYO identity/auth. This is certainly for different use cases, but I thought I’d mention it. If anyone is interested, I’d be curious about your use cases.

Which parts are complex? I got a webrtc video chat app up and running from nothing in a weekend.

It gets difficult when you have users saying they can't connect to each other. Then you have to get a better grasp on networking to understand why they can't, sometimes staring at Chrome's webrtc-internals page hoping something clicks. Otherwise you'll have your hands tied and just assume their network is incompatible. Even with a TURN server configured, the same problem can occur.

I can install Ubuntu in a VM in a hour or so. That doesn't mean Ubuntu or virtual machines are simple pieces of software.

Try to find the RFC, then realize there are actually a million defining all the different protocols used by WebRTC. It is not simple :-).

me crying reading through STUN protocol RFCs. You're exactly correct though, once you want to scale it or make it a "quality" piece of software the amount of knowledge you need to ingest is massive.

The protocol and spec mostly, but also the establishment dance and too many knobs. Which client and server libs are you using? Chances are if you dig in their deps it’s messy.

It’s also designed for real-time video and audio (udp), so reliable high-bandwidth streaming p2p apps takes a back seat.

That doesn’t mean it’s not the right choice to build stuff with today, especially browser based real-time apps! I’m all for webrtc getting easier.

I didn't use anything other than the basic webrtc examples from github and a rather basic exchange using a web socket (server was express). Obviously not completely P2P because you need to exchange capabilities somehow. Tbh it probably took me longer to get the domain and coturn set up than the webrtc.

I didn't look into how much bandwidth was being used. I was mainly using it for 1-4 person calls during lockdown. I wanted to write a video calling app that I could have full control of.

It's always easy to run a variant of the main example of a library. The question is: how difficult does it get when you want to do something slightly different?

Looks cool. Usually, when needing something like this, I use Jitsi Meet but having options is nice.

Can someone explain how the two differ (either technically, or from the perspective of a use who just wants reliable/easy/private calls)? I've started using jitsi more because of Zoom's time limit enforcement, but I'm looking for alternatives also.

With great pleasure I contributed to this fantastic project! Simple and functional! If someone have pleasure, can try also the p2p - sfu - c2c versions of mirotalk: https://github.com/miroslavpejic85 A happy weekend to everyone and a merry Christmas!

Hey! We were using mirotalk for p2p video consultations, but switched to jitsi because of the google translate integration. I know searching for all strings and replacing them with placeholders is a giant task, but google is really bad at translating single words without context

This is great, since many people are looking to get away from Zoom. I was on a call the other day that was hosted by a very large startup (raised $200M). They had to end the call at 40 mins "because of our subscription tier".

If companies this big don't want to pay a penny to Zoom, that's saying something! It doesn't mean there's a great market opportunity for a paid tool, but it does mean that free tools will get good usage. I'm looking forward to the normalization of Jitsi and other alternatives, so people don't think I'm a weirdo for sending out links to services they've never heard of.

I agree with everything you said, but those guys are just cheap

Talk is a free, peer-to-peer, disposable group video calling app for the web.

Works in all major browsers.

No signups. No downloads. 100% peer-to-peer.

> 100% peer-to-peer.

Is this even possible with WebRTC? How do clients initially learn about each other's IP addresses and ports?

There seems to be some logic to facilitate that in the server code: https://github.com/vasanthv/talk/blob/master/server.js

I agree, this is super cool but it's not 100% peer to peer as WebRTC requires a central server to establish the connection as far as I know.

It does not require a central server, signaling is left as an implementation detail. Implement a p2p signaling system, and that will be p2p.

Is LAN P2P? If yes, WebRTC is 100% P2P over LAN is it not?

I still think the clients need a coordination server to discover each other (won't use multicast/broadcast traffic). You could probably make a browser that does this, but if they already do then I am not aware of it.

Signaling is up to the implementation. You can use carrier pigeons if you want. Would that qualify as p2p? :)

Pigeon-to-pigeon connection establishment, I like it :)

I've never considered using WebRTC without STUN or TURN, but apparently it's quite possible, enabling LAN-only usage: https://stackoverflow.com/questions/30742431/webrtc-on-isola...

If it's disposable, how many uses can you get out of it before it is worn out and has to be replaced?

This is awesome. I wonder why no modern browsers have this baked in.

Brave has something similar to this baked in

Brave just uses Jitsi under the covers.

Also see keet (https://keet.io/), a peer-to-peer chat and video app

What are my options for running a larger scale web conferences (up to a thousand endpoints perhaps, handful of them speaking) with free software and regular web browsers involved?

I guess past a certain point it's more like streaming than group calls. What have larger f/oss events such as FOSDEM used during the pandemic and what did they have to change to get it to scale?

> The sweet number is somewhere around 6 to 8 people in an average high-speed connection.

Based on mesh architecture WebRTC, so unfortunately not really an option for anything but small calls. WebRTC is fun, but in the end, someone has to do the encoding, and w/ mesh, the client pays the price.

The issue isn't really encoding but bandwidth, specifically upload bandwidth (due to needing to send your own stream to all n-1 other participants rather than just one SFU, which then fans out to n streams).

Many popular group video call solutions are end-to-end encrypted these days, so there isn't any re-encoding happening.

>Many popular group video call solutions are end-to-end encrypted these days, so there isn't any re-encoding happening.

What format do you think an end2end encrypted video comes in over the wire?

SRTP, in most cases, at least for point-to-point encryption.

I'm not too sure about end-to-end encryption in WebRTC, though; I remember reading that something different happens there [1].

[1] https://webrtchacks.com/you-dont-have-end-to-end-encryption-... and https://webrtchacks.com/true-end-to-end-encryption-with-webr...

6 to 8 people is a lot even without using Star-Configuration WebRTC. For example, how many people do you talk to at once face to face in real life in an average group? 4 to 6 people calls its like the size of a normal table at a restaurant. It is the typical group conversation. You could argue large group calls become more and more unnatural after 8 total people.

Is this like jump.chat where you share links? What's meant by disposable?

Yes, it's similar. This one is also open source so can be self-hosted. JumpChat also has file share I see.

Does this work if everyone is behind a different NAT? If so, how?

WebRTC is pretty good at getting through complex NAT constellations, trying to punch through NATs via STUN/ICE and falling back to TURN in case that fails (but the latter requires a central coordination server).

It only needs a lightweight signalling server to relay each client's ICE candidates (which is more or less an opaque string to the server) to their peers, and if that succeeds, they can communicate P2P (audio, video, and even opaque byte streams).

All of the complex NAT traversal logic and the encrypting P2P protocol stack is baked into all modern browsers (or non-browser clients using a WebRTC library); the only thing that's needed is the signalling server, and practically a STUN server to facilitate ICE (but these use very little bandwidth and there are public ones available).

Most of WebRTC is arguably about handling the NATs, actually.

Is node and npm required only for building the project, or also for running it?

In other words, can this run if I upload the html, js and other files to static hosting?

I'm not associated with the project, but I found that it's not a static site. Node.js is required for the thin WebSocket layer.

https://github.com/vasanthv/talk/blob/master/server.js

The actual P2P handshake is done through these default ICE servers defined in the client script.

https://github.com/vasanthv/talk/blob/master/www/script.js

  const ICE_SERVERS = [
    { urls: "stun:stun.l.google.com:19302" },
    { urls: "turn:openrelay.metered.ca:443", username: "openrelayproject", credential: "openrelayproject" },
  ];

How many concurrent users can it support on a single cheap nodejs server? Or is the client the bottleneck?

Since it's all peer-to-peer, there isn't anything being done on the server (I don't even think there is a server?)

Like others have said, the bottleneck will be your client's upload speed- if you have a meeting with 10 people, you're going to be sending your video out to 10 different peers.

Can't you send 1/10 to each, and they will in turn send to one another, so the load is equal on all nodes?

Is there a way to integrate it into other software products?