Hacker News Reader

Comment by 0x0 | Hacker News Reader

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

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.

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

Same here. We use Jitsi inside our app for online learning. It works good.

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

Ubuntu, just apt install or whatever it was

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

Getting Jitsi running is actually trivial (depending on your definition of trivial). I went from zero to fully running in about 30 minutes on a fresh Ubuntu server when I wanted to check something one time. It might even be dockerized, but my memory isn't 100% on that.

Maybe on Ubuntu. I'm talking about the ``manual'' installation to which everyone not using Ubuntu must resort.

It’s always “just npm install.” IMO that’s no different than curl | sh; it’s easy to copy/paste but not simple.

If you don't trust the app, don't run it. You'll be giving it access to video, voice and internet at minimum.

You can't avoid that if you want to punch through NAT like all of us have to do.

Or can you?

Don't need NAT with IPv6

But it's still used nonetheless (even if less than with IPv4).

I have 2 routers and one by default blocks incoming connections on ipv6 and the other one give you the choice between drop and reject for incoming connections.

More than half of the world still can't use IPv6 (including my whole country) due to ISPs not implementing it, so relying on that is not a good choice for now.

huh, interesting. I’m sure there’s a use to this extra layer of “obscurity” after the sibling comment.

It's not even that. Well, it is, but it's two separate things: you need a publicly-addressable server to host this code, for all the peers to connect to in order to discover each other and exchange session information. You could also host this locally and use something like ngrok to provide the publicly-addressable endpoint.

The NAT hole punching is done by the STUN servers listed in script.js. They appear to be public third-party STUN servers, so that could be a vector for a malicious actor. There are also third-party TURN servers listed, which will relay media in the case that NAT traversal fails. That should be ok too, but could also be another attack vector.

And it seems to contain hardcoded usernames and password for those STUN/TURN servers too...

Jitsi not being p2p is advantage in my book. I'd imagine p2p group video calling is subpar.

Reply on news.ycombinator.com