[HN Gopher] Free, P2P, disposable group video calling app for th...
___________________________________________________________________
Free, P2P, disposable group video calling app for the web
Author : vasanthv
Score : 74 points
Date : 2022-12-23 16:04 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dtx1 wrote:
| Does this work if everyone is behind a different NAT? If so, how?
| lxgr wrote:
| 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).
| omeze wrote:
| This is awesome. I wonder why no modern browsers have this baked
| in.
| codetrotter wrote:
| 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?
| lioeters wrote:
| 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" }, ];
| xorcist wrote:
| 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?
| vasanthv wrote:
| 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.
| lxgr wrote:
| > 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
| clemensley wrote:
| 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.
| koolala wrote:
| Is LAN P2P? If yes, WebRTC is 100% P2P over LAN is it not?
| lucb1e wrote:
| 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.
| backspace_ wrote:
| If it's disposable, how many uses can you get out of it before
| it is worn out and has to be replaced?
| gnicholas wrote:
| 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.
| guerrilla wrote:
| Is this like jump.chat where you share links? What's meant by
| disposable?
| forgotpwd16 wrote:
| Yes, it's similar. This one is also open source so can be self-
| hosted. JumpChat also has file share I see.
| boredumb wrote:
| 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.
| klabb3 wrote:
| 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.
| forgotusername6 wrote:
| Which parts are complex? I got a webrtc video chat app up and
| running from nothing in a weekend.
| klabb3 wrote:
| 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.
| forgotusername6 wrote:
| 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.
| mp85 wrote:
| 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!
| lucakiebel wrote:
| 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
| folkrav wrote:
| > 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.
| koolala wrote:
| 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.
| lxgr wrote:
| 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.
| bobkazamakis wrote:
| >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?
| lxgr wrote:
| 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...
| forgotpwd16 wrote:
| Looks cool. Usually, when needing something like this, I use
| Jitsi Meet but having options is nice.
| gnicholas wrote:
| 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.
| koolala wrote:
| How many concurrent users can it support on a single cheap nodejs
| server? Or is the client the bottleneck?
| TranquilMarmot wrote:
| 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.
___________________________________________________________________
(page generated 2022-12-23 23:01 UTC)