
Show HN: Talk – A free group video call app with screen sharing - vasanthv
https://github.com/vasanthv/talk
======
CameronNemo
Is this different from or better than Jitsi Meet? Not intending to criticize
the effort, just curious if I should switch my goto choice of video
conferencing software.

[https://meet.jit.si/](https://meet.jit.si/)

~~~
zucker42
Jitsi is built to run with a server managing the call. This is peer to peer,
it appears.

~~~
0x0
It still needs a server to relay the webrtc peer discovery stuff, at least by
looking at server.js ?

~~~
daffy
Setting up a Jitsi server is non-trivial; this is simple (git clone / cd talk
/ npm install / npm start). And, if you don't want to trust the programme, you
can do this from a dedicated unpriviledged user.

~~~
d0100
I thought so as well. Ended up rolling my own and encountering too many sync
and error-handling issues.

Ended up deciding to spend the week configuring jitsi, but all it took was 1
hour to install and configure the server and I was done

~~~
daffy
Was this using Ubuntu or whatever it is they recommend or ``manually''?

~~~
d0100
Ubuntu, just apt install or whatever it was

The development of the frontend is a bit messy, but you'll manage

------
theanirudh
Another fully featured group video chat: [https://talky.io](https://talky.io)

It's based on this open source app
[https://github.com/simplewebrtc/simplewebrtc-talky-sample-
ap...](https://github.com/simplewebrtc/simplewebrtc-talky-sample-app)

They also run [https://www.simplewebrtc.com](https://www.simplewebrtc.com)
which is an SDK for building custom WebRTC apps. They also provide TURN and
SFU servers.

~~~
e12e
This appear to be client side only (it can even be statically deployed) - the
project in the submission is a client + server that handles signalling.

And,i dont quite understand this bit:

> To get started, you will first need to edit public/index.html to set your
> API key.

So, for any service using talky, I can just steal the Api key rather than
subscribing? I mean, it's in the _index_ file, not even protected by login,
but sent to all clients (and bots..)?

------
Benjamin_Dobell
Is this hosted anywhere?

I created [https://omen.tv/](https://omen.tv/) just last weekend. Similar in
that it's powered by WebRTC, but it's designed for casting your screen (e.g.
Jackbox Games) to other people's TVs.

My greatest annoyances with WebRTC were:

1\. WebRTC _requires_ a STUN server, and despite the spec initially supporting
default ICE servers, it has since been pulled out into an extension because
browser vendors don't want to provide servers[1]. There are free STUN servers
(Google etc.) but...

2\. Double NAT clients. STUN is inevitably going to discover double NAT
clients. The _only_ way to connect these clients is through a proxy.
Specifically a TURN server. Unlike STUN servers, these are not light-weight,
and I can totally understand why browser vendors don't offer them by default.
So inevitably any WebRTC use still requires a self-hosted TURN server.

3\. Inconsistent access to streams across browsers. In particular the
getDisplayMedia[2] API provides poor availability of the audio stream.
Courtesy of Apple doing Apple things, I don't believe it's even possible to
implement this API on macOS as there's no audio loopback device. I worked
around this for my use-case by installing BlackHole[3] (which is great
software!) However, the loopback device appears as an input e.g. like a
microphone, so isn't technically the display audio.

For this all to be smooth I think all these pain points need to be addressed.

Issue 1 and 2 require NAT to be kicked to the curb, come on IPv6! Issue 3,
requires Apple to expose a loopback device _and_ browsers to implement
support. These aren't insurmountable issues, but they're unfortunately out of
our hands as day-to-day devs.

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/RTCPeerConn...](https://developer.mozilla.org/en-
US/docs/Web/API/RTCPeerConnection/getDefaultIceServers)

[2] [https://developer.mozilla.org/en-
US/docs/Web/API/MediaDevice...](https://developer.mozilla.org/en-
US/docs/Web/API/MediaDevices/getDisplayMedia)

[3]
[https://github.com/ExistentialAudio/BlackHole](https://github.com/ExistentialAudio/BlackHole)

~~~
jitbit
I was playing around to create something similar and these problems were
EXACTLY what I bumped into. STUN is a must for discovery, TURN is a must if
both people are behind NATs, Apple support is meh...

So, to sum up, for a webRTC p2p app you need to:

1-3) The things you mentioned.

4) Code your own signaling server to transmit events like "call", "hung up",
"room" tracking, etc.

~~~
MayeulC
> TURN is a must if both people are behind NATs

This is not what double NAT means. If both people are behind single NAT, STUN
is enough.

I think it is also enough if one person (or both) are behind more than one
regular NAT, which is what double-nat usually means.

Where STUN doesn't work is symmetric NAT [1], where different destination
servers will receive a packet with different source ports, even if the
original source port was the same.

It also doesn't work in a few, lesser-used NAT types [2].

[1]
[https://en.wikipedia.org/wiki/Network_address_translation#Sy...](https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT)

[2]
[https://en.wikipedia.org/wiki/STUN#Limitations](https://en.wikipedia.org/wiki/STUN#Limitations)

------
mpartel
The JS code is under 500 lines so this is at least simple and auditable.

I didn't see anything about encryption based on a cursory read. Does WebRTC
have some built in or is this unencrypted?

~~~
kelnos
WebRTC requires DTLS (the UDP version of TLS) for the media streams; it
doesn't even allow unencrypted.

The signaling for call setup / maintenance / teardown can be whatever, though.
It looks like this uses socket.io with HTTPS long-polling. So you need a
publicly-addressable IP (or a proxy service like ngrok) in order to host this
yourself.

Assuming you host it yourself, all clients should have encrypted signaling
with your server, and encrypted voice/video packets between each other. If
someone else hosts it for you, they can see your signaling traffic, but --
unless they change the code to forward the media stream elsewhere in order to
MitM it -- your media should still be encrypted.

However, this does make use of public STUN servers to help with NAT/firewall
hole punching, which will leak your IP addresses and possibly make it so an
adversary can figure out the IPs of the people who were talking to each other,
based on the timing of connections. There are also public TURN servers listed
which will act as media relays if the NAT traversal fails. Usually the TURN
servers are dumb packet forwarders and won't terminate the DTLS sessions, so
that should be fine, but I don't remember how the protocol works well enough
(it's been a good 7 years since I was knee-deep in this stuff) to say that for
certain.

~~~
algesten
DTLS is only the first part of the encryption. The actual media is transferred
of SRTP which is encrypted RTP. DTLS provides the keying material to derive
keys for SRTP.

DTLS is however fully used for SCTP, which the protocol for data channels
alongside the media streams.

~~~
kelnos
Yes, I'm aware (I've implemented a WebRTC stack before); I didn't think diving
into the finer details of SRTP would be necessary at this point.

------
abhayhegde
Amazing! I think this is the better open-source alternative to Google Meet and
Zoom. Of course, this may not be filled with all the features offered by them,
but this is more than enough for meeting 6-8 people at a time.

------
cloogshicer
Is there a video call app with screen sharing that doesn't use WebRTC?

I often host online lectures and with screen sharing, it always uses up 100%
of my CPU resources.

------
ArtWomb
>>> quality of the call is inversely proportional to the number of people on
the cal

Interesting experiment would be to run locally on high speed LAN with LOTS of
participants. Whats the limit to what the browser can handle?

Thanks for building, vasanthv ;)

------
_heimdall
Is this pretty similar to zipcall.io? I've used it a few times and was
surprised with how well it worked for video calls and screen sharing.

Only problem I had with it was one client that couldn't get his mic working.
I'm assuming it was a browser permissions issue but I called him on Signal
instead rather than trying to track it down remotely.

------
badalsurana
I am surprised to see a video call and screensharing app build with less than
500 lines of JS code.

Did not know that.

------
moron4hire
WebRTC is amazing, until you start getting users on iPads. The complaints of
the Firefox users are easy to ignore (there are so few of them, after all),
but the iPad users are too numerous (especially within my company).

------
fonosip
here's a similar webrtc app, but free of node.js dependency
[https://ba.net/screen-share-party](https://ba.net/screen-share-party)

------
amitheonlyone
I don't know anything about STUN or TURN servers. I saw some credentials in
the script.js file. Is it dummy or is it okay to make this public?

~~~
Benjamin_Dobell
The original ICE credential APIs make approximately zero sense. Basically the
clients need the password, so there's nothing stopping them redistributing it,
making the whole thing rather pointless.

There's now support for third-party auth (i.e. oauth). It's not really fool-
proof on its own, however you can at least then disable access to those who
abuse the system. However, for this to work you need to have an oauth provider
i.e. sign-in, which may be non-desirable.

------
canada_dry
Couldn't the double NAT STUN/TURN thing be eliminated if the solution was
modified to utilize Wireguard on all the endpoints?

------
haroldegibbons
I thought WebRTC was the coolest thing since sliced bread until I ran into the
whole TURN and STUN thing. I feel catfished.

~~~
daffy
What are TURN and STUN?

~~~
SamWhited
Ways for punching through NAT. STUN lets you discover NAT addresses and the
like to try and establish a connection with a port on the WAN IP, or some
other connection mechanism. TURN is effectively a proxy that can be used by
both sides to establish a connection through NAT.

------
redindian75
Here is a demo:

[http://talk.vasanthv.com](http://talk.vasanthv.com)

------
h43z
To share just one screen (mostly for my mom and me) I created
[https://screenshare.43z.one/](https://screenshare.43z.one/) in just a few
lines of client side js.

------
nyxtom
Nice! The WebRTC samples tend to be a bit convoluted. This sample project is a
great demonstration of simplicity. Going to use this for some data channel
work.

------
pkz
It would be great with a similar solution that also packaged you own STUN/TURN
setup. Maybe there is someone who did that for Jitsi meet?

~~~
j1elo
OpenVidu.io packs everything needed: an all-in-one Docker image that you can
deploy and use to build any videoconference project upon it (or use the ready
made Call app that is provided as a real-world project example)

Disclaimer: I am coworker with the people that write OpenVidu. Check it out!

------
rajbiswas125
Is there anything which doesn't use webrtc?

------
upofadown
How does the identity management work here? How do you know that you are
talking to who you think you are talking to?

~~~
falcor84
Can't we just manage this on layer 8?

------
rdlecler1
There are lots of free options. We use zoom because it has the best and most
consistent quality.

~~~
SamWhited
From a tech-org perspective I've had the opposite experience. Zoom crashes,
behaves weird, has issues on some peoples machines but not others, does weird
javascripty things to hide the "join by web" link which we get complaints
about, etc.

From a non-technical persons perspective, my piano teacher was using Zoom but
ended up having to switch to Jitsi Meet because (anecdotally) the audio
quality was better and more consistent.

~~~
ComputerGuru
It’s not anecdotal, Zoom applies significant audio filtering and “enhancement”
as well as selectively attenuating “non-primary” speakers.

~~~
SamWhited
My casual observations of it were anecdotal, that is. Glad to see someone else
has noticed similar behaviour.

------
usaphp
Is there a way for multiple people to simultaneously share their screen with
each other

------
rambojazz
Could you add some screenshots on the README?

------
mixedbit
Up to how many participants P2P WebRTC video calls work well in browsers?

~~~
kelnos
Right from the first paragraph of the README:

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

------
john_alan
Doesn’t look too secure.

~~~
kelnos
Quite the contrary; if you host this yourself, remove the TURN server list,
and host your own STUN server, it's much more secure than pretty much any of
the third-party-hosted services out there. Assuming you trust your browser,
that is.

Obviously I haven't audited the code, but it's pretty small, and wouldn't be
hard to thoroughly audit.

It's surprisingly light on dependencies, just pulling in express as the webapp
server, and socket.io for the call signaling. Personally I'd probably roll my
own signaling over websocket to avoid that dependency (socket.io is an awful
protocol, though for generally understandable reasons), but that would likely
more than double the amount of code the author would've had to write.

~~~
Kiro
Why is socket.io awful?

~~~
lioeters
I was curious too, since I'm generally fond of socket.io. I've written my own
small library around bare WebSocket API, and there are many aspects to
consider, like fallbacks and reconnection. In my opinion, socket.io provides a
simple and smallish interface that takes care of most needs.

Here's an article I found, with opinions on the good and the bad.

[https://dzone.com/articles/socketio-the-good-the-bad-and-
the...](https://dzone.com/articles/socketio-the-good-the-bad-and-the-ugly)
(2018)

~~~
kelnos
The interface is nice (from Javascript; it's impossible to write something
type-safe in any language where you like to care about type safety); the
protocol and implementation itself is horrifying. Some of the protocol's
handshaking gymnastics was necessary 15 years ago when you couldn't rely on
there being a standards-conforming Websocket implementation, but those days
are long gone.

Documentation is sparse, and when you find some docs, half the time it isn't
clear which (incompatible) version of the protocol they're talking about.

Source: I was working on writing an interoperable server implementation of
socket.io a couple years ago, and it was _way_ more work than it should have
been.

------
pmlnr
Great. Can I has hw encoding/decoding on linux, please? I don't need another
software, I need my laptop not to boil.

~~~
moron4hire
That's not the developer of this app's fault.

------
hn3333
Stop giving away great software for free. Sell it! :)

(P.S:: Didn't check out the source code. It's just a general sentiment of mine
lately.)

