Using a v3 onion address as both the cryptographic identity and the NAT traversal layer is such a clean architectural choice. No STUN/TURN servers, no hole punching, you just boot the script and Tor handles routing.
For those who use Tor regularly for things other than web browsing: how bad is the real-world latency for pushing a ~20KB Opus audio chunk over Tor these days? Are we talking a 2-3 second delay, or is it much worse?
show comments
iamnothere
Very cool, happy to see more IRL applications of onion services as a backend. Arti onion client support should soon be available, which will make Tor embeddable in applications as a Rust library. Hopefully this encourages even more usage.
More applications using the network means more cover traffic as well.
show comments
lxgr
> 21 curated ciphers are available
Why!? That sounds like approximately 20 too many.
show comments
aitchnyu
Tangential, did Gitlab become faster than a while back or is it an illusion from their lazy loading?
marcosqanil
I love this. In your view, how would users go about securely swapping credentials ? PGP over email ?
show comments
rustyhancock
> Exclude Countries -- Exclude specific countries from your Tor circuits. Presets for Five Eyes, Nine Eyes, and Fourteen Eyes alliances, or enter custom country codes. Uses ExcludeNodes with StrictNodes in the torrc.
Interesting that people do this, I wonder how much it improves security? Afterall, any serious surveillance would involve running relays and exits in foreign lands.
show comments
chasd00
Forgive my ignorance, but can this be setup for a group like how a group can all be on the same frequency with walkie talkies? Or it is strictly one to one. Either way, it’s a really cool concept.
show comments
decker_dev
The walkie-talkie model is a smart design choice given Tor's latency profile. Real-time bidirectional audio has pretty unforgiving requirements (~150ms round-trip max before it feels awkward), and Tor typically adds 50-200ms per hop. Going store-and-forward sidesteps the whole problem—you're not fighting the network's characteristics, you're designing around them.
Curious what codec you're using for the audio compression. Opus would be the obvious choice for speech but the tradeoffs change a bit when you're not doing real-time streaming.
I worked on text chat ages ago over TOR. Honestly so happy to see that the ecosystem is still going!
show comments
Tepix
Interesting to implement this as a shell script.
Still: Using a line based protocol and base64 encoding the audio data? Not my first choice.
The README doesn't mention it, but I assume both parties have to be online at the same time?
Regarding encryption - what's the point? When communicating with a tor hidden service, the data is already encrypted.
Only starting the sending audio data after the speaker has stopped talking means much longer delays than necessary. Imagine someone talking for a minute.
show comments
ProofHouse
This is rad
sourcegrift
Sorry for hijacking but I came across a firefox send replacement which worked in linux command line. Anyone know what it was? (It was online though, as in no storage for later)
show comments
mrexcess
Looks awesome in many ways. The use of a shared secret instead of PKI limits the real-world applications pretty severely, but adding PKI support doesn't seem too difficult. If the PKI key was only used to establish the session "shared secret", virtually no changes would be needed in the main code.
Using a v3 onion address as both the cryptographic identity and the NAT traversal layer is such a clean architectural choice. No STUN/TURN servers, no hole punching, you just boot the script and Tor handles routing.
For those who use Tor regularly for things other than web browsing: how bad is the real-world latency for pushing a ~20KB Opus audio chunk over Tor these days? Are we talking a 2-3 second delay, or is it much worse?
Very cool, happy to see more IRL applications of onion services as a backend. Arti onion client support should soon be available, which will make Tor embeddable in applications as a Rust library. Hopefully this encourages even more usage.
More applications using the network means more cover traffic as well.
> 21 curated ciphers are available
Why!? That sounds like approximately 20 too many.
Tangential, did Gitlab become faster than a while back or is it an illusion from their lazy loading?
I love this. In your view, how would users go about securely swapping credentials ? PGP over email ?
> Exclude Countries -- Exclude specific countries from your Tor circuits. Presets for Five Eyes, Nine Eyes, and Fourteen Eyes alliances, or enter custom country codes. Uses ExcludeNodes with StrictNodes in the torrc.
Interesting that people do this, I wonder how much it improves security? Afterall, any serious surveillance would involve running relays and exits in foreign lands.
Forgive my ignorance, but can this be setup for a group like how a group can all be on the same frequency with walkie talkies? Or it is strictly one to one. Either way, it’s a really cool concept.
The walkie-talkie model is a smart design choice given Tor's latency profile. Real-time bidirectional audio has pretty unforgiving requirements (~150ms round-trip max before it feels awkward), and Tor typically adds 50-200ms per hop. Going store-and-forward sidesteps the whole problem—you're not fighting the network's characteristics, you're designing around them.
Curious what codec you're using for the audio compression. Opus would be the obvious choice for speech but the tradeoffs change a bit when you're not doing real-time streaming.
Looks fun, I've yet to test it but I did skim it.
'|| true' 76 matches 'echo ""' 50 matches ' [ ' 261 matches '=$(' 90 matches
I worked on text chat ages ago over TOR. Honestly so happy to see that the ecosystem is still going!
Interesting to implement this as a shell script.
Still: Using a line based protocol and base64 encoding the audio data? Not my first choice.
The README doesn't mention it, but I assume both parties have to be online at the same time?
Regarding encryption - what's the point? When communicating with a tor hidden service, the data is already encrypted.
Only starting the sending audio data after the speaker has stopped talking means much longer delays than necessary. Imagine someone talking for a minute.
This is rad
Sorry for hijacking but I came across a firefox send replacement which worked in linux command line. Anyone know what it was? (It was online though, as in no storage for later)
Looks awesome in many ways. The use of a shared secret instead of PKI limits the real-world applications pretty severely, but adding PKI support doesn't seem too difficult. If the PKI key was only used to establish the session "shared secret", virtually no changes would be needed in the main code.
Thanks for contributing!