Hacker News

The real world delay is about 2-3 seconds your spot on. I initially started with a full duplex version but it was absolutely terrible. Walkie talkie kinda forces the recieve, listen, response from the users so the latency isn't as much of an issue.

STUN/TUN are important because of bandwidth. With STUN the bandwidth used is only between the two connected devices, with VPN like Tor there is a bandwidth cost on all the servers where this data is passing. This is a big blocker for anyone hosting the service on a VPS with a few GB of traffic data per month.

Why not stream anyway? adding to the latency by turning it to audio messages sounds more frustrating. At some point a message would be better.

Modulo cool project love show HN etc.

Beep boop

The library is openssl and that comes with all these ciphers available. No other reason than because we can!

I wish AES-GCM was available...but openssl can't do it on its own without further dependencies to parse the authentication correctly.

Really this whole layer is complelty redundant actually. It's already E2EE without openssl via Tor. I like that it's encrypted before I hit the network pipe though.

I think that's great. Cipher fixation is a vulnerability as the enemy knows what to attack.

Thanks! My realistic use case is that I am already speaking to someone who I know and trust, so ideally exchange credentials in person. A preferred out of band secure messanger of choice is probably fine.

You could put your onion address into an “oh by code”[1] and just write it down … or chalk it on the sidewalk for someone to see … post it on a physical bulletin board.. hold it up on a sign…

This way you could establish communication with an unknown future party, totally offline.

[1] https://0x.co

This was another one of those things I built in because we can. I really don't know... But the Tor developers built this in as an option on the torrc so there must be something to it. We know there are definitely compromised nodes...I think it's just neat that you can have that level of control regardless if it's effective.

It might not help for controlled nodes, but it does help avoid ISPs controlled by said governments from seeing it

It's strickly 1 on 1 for now but I do plan on exploring the group call scenario.

I don't think E2EE works that way.

Yes it's encoding in opus, and optionally you can configure encoding quality from 6kbs to 64kbs.

I was really surprised at the intelligability even at 6kbs.

The caviot is if your on termux we have to use the seperate termux API application to pipe audio to termux, and ffmpeg to convert MP4 to opus. Unfortunately termux cannot activate the mic on its own.

you're not just formulaic, you're an entirely ai-generated comment

I love it for the same reason I love email and text communication. Think about what you want to say before you say it. Exclude the useless tangents: formalities, movie quotes, humble brags, cliches, etc. A few second delay is enough to get even the worst offenders to get to the point.

Oh I’m curious. Love bash, and learning new things about it.

I can understand why [ is not ideal. Can you explain the rest to me? I use || true for custom error handling often (with the right set -euo pipefail of course)

You may like this one then. It's kinda the same thing, but text only and multiple people can connect at once. It's setup so anyone can be a host, or a client.

Basically IRC, but for Tor.

https://gitlab.com/here_forawhile/torch

the data is already encrypted

by the spooks that wrote it. no harm in having another turtle in the stack.

The base64 encoding adds about 30% overhead. It's not ideal but it was a limitation of bash. Passing raw binary does not work in bash (or I couldn't get it to work).

To expound on the other questions.

To receive a call, you either need to be online and actively listening for calls, or optionally, you can enable auto listening. When another user calls you it will automatically put you in the call. On end call you will be put back in listening mode. I'm not really sure a great way to get around this without overly complicating it.

I believe because of the small overhead that's added there is just no reason not to layer encryption. At the end of the day I just wanted to see the bits I'm sending over the wire with my own eyes for assurance it's protected regardless of the fact that tor is protecting the data.

The streaming would be a nice improvement for latency. I would have to look into how this would work for the optional audio processing. Having one set file for transport also simplifys the some of the flow with encryption like salting and optional hmac authentication as these are derived from the sum of the entire file, not a portion of it.