Comment by smalltorch
1 day ago
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.
Is audio transmitted while it is being recorded or afterwards? Is it played before everything is received or is everything buffered? In the later case, I find it more akin an audio message on Signal or similar, than as a walkie-talkie, which is much more "dynamic".
It's not streamed. It gets recorded, compressed, (voice effects if you want), encrypted on device, then piped through, reverse process, auto played on reciever end.
Also, once it's decrypted and played back, the message gets destroyed.
Small suggestion, maybe you should send a “key down” notice when you begin recording, that generates a subtle sound on the receiving end. This would act as something like a typing indicator on a text messaging client.
2 replies →
there are ways to help with lag a bit, you can choose the number of hops a HS uses when meeting up. but of course that comes with downsides
Could you use tor to establish a better realtime link using a different protocol like Veilid while maintaining the relative anonymity and security?
edit: https://veilid.com/
Added link for clarity. Seems like you could get more or less realtime, udp streaming, full duplex communication . Once you have the first part of that built, then adding things like voip or video calls or what have you becomes a lot easier.
The problem is the UDP packets from the application will ultimately be in a TCP wrapper over tor. Which will add even more latency.
I know you can set up mumble over Tor but it's going to have the same latency drawbacks.
Another commenter noted the ability to configure only 1 hop instead of the standard 3. I wonder how much latency would be gained back. I want to play around with this.
Sorry if I was unclear, this stuff does get tangled, lol. I was talking about setting up a parallel veilid connection - a private route exchange between the two ends that goes straight over the veilid network, outside of tor. It's got comparable privacy and security assurance. There only a few thousand nodes/peers right now, but it's gaining steam.
You could use tor to anchor a common relay, then do key and route exchange to establish veilid, then the realtime app uses that for a very secure private route unique to the two endpoints.
From what I can tell, because of the design, veilid would be excellent, comparable to many commercial voip offerings, with 150-500ms latency . More nodes and users would quickly ramp that up. There are a ton of downstream benefits of something like this; faster file exchange for ipfs, bittorent, etc, that doesn't gum up the tor layer, a kind of implicit defense in depth, but also low latency, efficient peer to peer routing.
It'd almost be zero knowledge by construction; you could build a multi-hop escrow style key exchange.
If Musk integrated tor relays and veilid peers throughout Starlink, you could get near-native latency for wherever you connect in the world, more than enough to add timing attack noise and layer in other security features.