Follow

Talk vs.

NextCloud Talk:
✅ much less resources needed on server-side thanks to p2p (5x to 20x less)
✅ requires an account to create a *new* room (server overload protection)
✅ runs in a browser
✅ AGPL licence

Jitsi:
❌ resources-hungry (on server)
❌ no end2end encryption (need to trust server)
❌ uses servers by default
✅ runs in a browser
❌ Apache licence (code can be closed)

NextCloud is easier to install than Jitsi on Debian Buster:

docs.nextcloud.com/server/18/a

@FuckOffGoogleZurich Jitsi uses Peer2Peer too, it is just not supported in every browser yet. I think not needing an account is the reason why jitsi is so popular right now.

@FuckOffGoogleZurich Am I wrong that it only uses google stun servers to detect the servers public IP, but that's it?

@FuckOffGoogleZurich can not confirm the easier to setup part. Jitsi ran basically out of the box while nextcloud-talk has tons of issues with more than 1:n coms and documentation on that issue seems very poor, actually it was the reason why we tried jitsi after NC-talk...

@FuckOffGoogleZurich @necrosis why is “requires an account to create a new room” a good thing?!

@f2k1de @FuckOffGoogleZurich vllt wegen (server overload protection) ? Schreiben sie zumindest da.
Wobei ich Account anlgegen au net so toll find. 🤔
Gute Frage. Hier kann eins geteilter Meinung sein.

@f2k1de @necrosis
In an ideal case, it would be better (for privacy and usability) not to require an account indeed. Public Jitsi servers however have been coming down in the past day one after the other (presumably) because too many users accessing them. For who manages a server, therefore, requiring an account to create a new room is a solution.

@FuckOffGoogleZurich
both use #webRTC afaik.
That means:

❌ - non of them work in the tor browser.
❌ - non of them can be used safely with tor, as webRTC can leak IP, as reported.
see for example: tor.stackexchange.com/question
[updated to the correct link]

Tor browser blocks #webRTC.

❌ If you use any browser that supports webRTC and let it run through tor, you're at risk of leaking your ip.

Anyone experience with #qtox for group talks?
How about it's security while using tor?

@hambibleibt @FuckOffGoogleZurich I've tested the video with qTox, but I don't know if it supports groups and I'm not sure what the security is like (i.e. whether the stream is routed via proxy settings).

@bob @FuckOffGoogleZurich
you can change the proxy settings to use torsocks. it works. If it alway works I don't know, but I've been using it in tails, that is forcing everything through tor, or denies connection. After changing the proxy settings, I could connect. So I asume that this works fine.

several from the #whonix community have been advising the use of qtox. I did not came across a deeper research on how tox behaves over tor.
But I kind of asume, that they wouldn't advice such, if there would be a great chance of leaking ip. Maybe I'm wrong.

@hambibleibt @bob @FuckOffGoogleZurich Ordinary messages work fine over Tor, but I'm not sure what happens to video. Often apps will orchestrate audio/video securely but send streams insecurely using UDP for speed.

I'll need to read the code for toxcore to see what actually happens to the video stream.

@hambibleibt @bob @FuckOffGoogleZurich "One of the reasons for making direct connections is that relaying real-time multimedia conversations over anonymity networks is not feasible with the current network infrastructure."

It looks like within the code it uses RTP which probably isn't onion routed. But this may be about as secure as streaming audio/video gets with current technology.

@bob @FuckOffGoogleZurich
they use some form of onion routing. If UDP is not available they fall back to TCP. (haven't checked how this aplies to audio/video calls)

@hambibleibt @bob @FuckOffGoogleZurich From the code my guess is that the security of qTox for audio or video is similar to NextCloud Talk (webRTC) or Mumble.

An adversary may be able to know which peers are exchanging RTP packets, but probably not what the content is. If there is proxying via Tor it will only be the orchestration which is proxied and not the stream itself.

In a browser based system it's easier to know that this won't work entirely through Tor, but with native apps it's not so obvious.

@bob @FuckOffGoogleZurich
this onion routing seems to only aply to friend request, to protect once IP from being connected to once ID being stored in DHT.

Within group chat, it seems to create direct connections between up to 4 peers, that can transfer data to their peers (people they have accepted a friend request) within the group. As I understood neither ip, nor ID needs to be known to everyone in the group, but to your peers.

So if someone is introducing a spy to the group, no one needs to be directly connected to that spy, except the person that introduced them. By that it should prevent some meta data leaks.

...but maybe I got that wrong, I got confused while reading, and also didn't read everything

In case you continue investigating I'd be happy to hear about it.

How is #webRTC choosing who will be connected to whom?

@bob @FuckOffGoogleZurich
found also this:

"With the ever increasing need for anonymity online, Toxcore now supports TCP-only communications to be used through services such as Tor. Tunneling Tox over Tor allows the user to still communicate with non-Tor contacts, unlike I2P, providing the best of both worlds. The following guide will explain how to setup ToT with the various Tox clients. "
wiki.tox.chat/users/tox_over_t

@bob @FuckOffGoogleZurich
some more about #Tox being able to only comunicate over TCP and directly related to #qtox:

"Enable UDP (recommended): If enabled, qTox will use TCP and UDP protocols. If disabled, qTox will only use TCP, which lowers the amount of open connections and slightly decreases required bandwidth, but is also slower and puts more load on other network participants."
github.com/qTox/qTox/blob/mast

@FuckOffGoogleZurich would love to have an option for recording and to store every member of a talk as a single audio track.

Would be perfect for podcasting if your guest isn't sitting in the same studio as you.

@maumau Mumble does *exactly* that, we are using it for our radio shows :)
@FuckOffGoogleZurich

on the website, tox says you can cirumvent the ip leak using tor. so i guess, thats safe.

@FuckOffGoogleZurich Jitsi: ✅ can actually make a call
Not a fan of Jitsi but out of the 5 or so programs I've tested yesterday, #nextcloud talk was the only one which did not work at all, even one way.

@FuckOffGoogleZurich good news: they just removed #Google #STUN servers by default
github.com/jitsi/jitsi-meet/pu

but now the servers need to be updated 🤞

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!