The QUIC "Anywhere Mode" is the part I'm most curious about. Direct phone-to-phone over the internet usually dies on NAT traversal - two devices on different mobile networks can't easily see each other. Are you doing hole-punching with a lightweight signaling server just for the handshake, or is there a relay fallback when a direct connection can't be established? Trying to understand where "zero-cloud" holds and where it has to bend a little.
You hit the nail on the head! The NAT traversal was absolutely the hardest architectural challenge of building the 'Anywhere' mode.
To handle this, we are leveraging Iroh (written in Rust) under the hood for robust hole punching. It does a fantastic job establishing direct QUIC connections across most standard network topologies.
However, you are completely right—when dealing with strict Symmetric NATs on certain mobile carriers or restricted corporate LANs, direct hole punching will inevitably fail. In those specific edge cases, we do gracefully fall back to a lightweight relay server to ensure the transfer still succeeds.
So, where does the 'zero-cloud' promise stand? For us, 'zero-cloud' strictly means zero storage and zero visibility. The relay server acts purely as a dumb pipe forwarding packets. Because the QUIC tunnel is End-to-End Encrypted (E2EE) directly between the two client devices, the relay server cannot see the file content, and the files are absolutely never stored on disk anywhere.
It's a slight "bend" in pure direct P2P routing when a fallback is forced, but it strictly maintains the 100% zero-knowledge privacy guarantee!
Great concept but the Play Store page needs work. Screenshots are basic. No demo video. Needs more info on how the Anywhere mode actually works without a server. Also privacy policy? If it's truly P2P, what are you collecting? Answer those and you'll get more trust
Thank you for the brutally honest feedback! This is exactly why I posted here.
Video & Screenshots: The promotional video is currently in production and will be uploaded to the Play Store listing this week to properly demonstrate the transfer process.
Architecture: You're right that I need to explain the 'Anywhere' mode better in the main description. Because it is true P2P, we use Iroh for NAT hole-punching and QUIC for E2EE tunnels. I'll update the Play Store description to make this architecture clear so people don't have to guess.
Privacy Policy & Data: The Privacy Policy is actually already linked at the very bottom of the Play Store page in the 'Developer contact' section! But you can also find it, along with more technical details, directly on our website at airlynk.in. Because of the P2P architecture, we collect absolutely zero file data. The only thing the app collects is basic anonymous crash logs (via Firebase) to help me fix bugs.
I really appreciate you taking the time to point these things out!
The “upload to the cloud just so someone nearby can download it” problem is very real. The zero cloud approach sounds interesting, especially for large videos. Curious how it performs across different devices and network conditions.
Exactly! That specific frustration was the entire reason I started building this.
Regarding performance, it's highly dependent on the network environment, which is why we built two distinct routing modes:
Local Network Conditions (Nearby Mode): If the devices are in the same room, the app completely bypasses the internet using Wi-Fi Direct. Speeds are blazing fast (often 250+ Mbps depending on the phone's hardware), and large 4K videos transfer in seconds, completely offline.
Internet Conditions (Anywhere Mode): If they are remote, we use Iroh for NAT hole-punching over the internet. Here, speed is entirely bottlenecked by the sender's ISP upload speed. However, because the QUIC tunnel streams concurrently (the receiver downloads the exact second the sender starts uploading), it still mathematically cuts the total wait time in half compared to cloud storage!
Across different devices: This is actually why I wrote the core engine in Rust instead of just using standard Flutter packages. Bridging Rust to Flutter keeps the memory footprint incredibly low and stable, so even older Android devices don't overheat or crash when transferring massive 10GB+ files!
The zero-cloud approach is a pretty compelling difference, especially for large videos where uploading everything first feels unnecessarily slow.
Curious how the Anywhere Mode performs in real-world conditions compared with Nearby Mode. That seems like it could be a very different experience depending on the connection.
Thank you! That "upload-first" bottleneck is the exact frustration that made me start building this. Waiting for a 4GB video to upload to the cloud just so the other person can finally start downloading it is maddening.
Regarding real-world performance, you are spot on—they are very different experiences, mostly governed by the physics of the network:
Nearby Mode: Since this uses Wi-Fi Direct, we are transferring over a local ad-hoc network. Speeds are completely decoupled from the internet and regularly hit 250+ Mbps depending on the phone's hardware. A massive 4K video transfers in seconds.
Anywhere Mode: Because this routes over the internet, the speed is entirely bottlenecked by the sender's ISP upload speed and the receiver's download speed.
However, even on a mediocre connection, it is still significantly faster than the cloud. With cloud storage, your total wait time is (Upload Time) + (Download Time). With AirLynk's direct P2P QUIC tunnels, the transfer streams concurrently. Your total wait time is just the longest(Sender Upload Time, Receiver Download Time).
It effectively cuts the total waiting time in half, and you never have to sit around waiting for server-side video processing to finish!
About
AirLynk exists because I was tired of messaging apps ruining video quality and cloud drives acting as slow middlemen. I wanted a fast, 100% private, zero-cloud way to share files of any size.
8 Comments
The QUIC "Anywhere Mode" is the part I'm most curious about. Direct phone-to-phone over the internet usually dies on NAT traversal - two devices on different mobile networks can't easily see each other. Are you doing hole-punching with a lightweight signaling server just for the handshake, or is there a relay fallback when a direct connection can't be established? Trying to understand where "zero-cloud" holds and where it has to bend a little.
You hit the nail on the head! The NAT traversal was absolutely the hardest architectural challenge of building the 'Anywhere' mode.
To handle this, we are leveraging Iroh (written in Rust) under the hood for robust hole punching. It does a fantastic job establishing direct QUIC connections across most standard network topologies.
However, you are completely right—when dealing with strict Symmetric NATs on certain mobile carriers or restricted corporate LANs, direct hole punching will inevitably fail. In those specific edge cases, we do gracefully fall back to a lightweight relay server to ensure the transfer still succeeds.
So, where does the 'zero-cloud' promise stand? For us, 'zero-cloud' strictly means zero storage and zero visibility. The relay server acts purely as a dumb pipe forwarding packets. Because the QUIC tunnel is End-to-End Encrypted (E2EE) directly between the two client devices, the relay server cannot see the file content, and the files are absolutely never stored on disk anywhere.
It's a slight "bend" in pure direct P2P routing when a fallback is forced, but it strictly maintains the 100% zero-knowledge privacy guarantee!
Great concept but the Play Store page needs work. Screenshots are basic. No demo video. Needs more info on how the Anywhere mode actually works without a server. Also privacy policy? If it's truly P2P, what are you collecting? Answer those and you'll get more trust
Thank you for the brutally honest feedback! This is exactly why I posted here.
Video & Screenshots: The promotional video is currently in production and will be uploaded to the Play Store listing this week to properly demonstrate the transfer process.
Architecture: You're right that I need to explain the 'Anywhere' mode better in the main description. Because it is true P2P, we use Iroh for NAT hole-punching and QUIC for E2EE tunnels. I'll update the Play Store description to make this architecture clear so people don't have to guess.
Privacy Policy & Data: The Privacy Policy is actually already linked at the very bottom of the Play Store page in the 'Developer contact' section! But you can also find it, along with more technical details, directly on our website at airlynk.in. Because of the P2P architecture, we collect absolutely zero file data. The only thing the app collects is basic anonymous crash logs (via Firebase) to help me fix bugs.
I really appreciate you taking the time to point these things out!
The “upload to the cloud just so someone nearby can download it” problem is very real. The zero cloud approach sounds interesting, especially for large videos. Curious how it performs across different devices and network conditions.
Exactly! That specific frustration was the entire reason I started building this.
Regarding performance, it's highly dependent on the network environment, which is why we built two distinct routing modes:
Local Network Conditions (Nearby Mode): If the devices are in the same room, the app completely bypasses the internet using Wi-Fi Direct. Speeds are blazing fast (often 250+ Mbps depending on the phone's hardware), and large 4K videos transfer in seconds, completely offline.
Internet Conditions (Anywhere Mode): If they are remote, we use Iroh for NAT hole-punching over the internet. Here, speed is entirely bottlenecked by the sender's ISP upload speed. However, because the QUIC tunnel streams concurrently (the receiver downloads the exact second the sender starts uploading), it still mathematically cuts the total wait time in half compared to cloud storage!
Across different devices: This is actually why I wrote the core engine in Rust instead of just using standard Flutter packages. Bridging Rust to Flutter keeps the memory footprint incredibly low and stable, so even older Android devices don't overheat or crash when transferring massive 10GB+ files!
The zero-cloud approach is a pretty compelling difference, especially for large videos where uploading everything first feels unnecessarily slow.
Curious how the Anywhere Mode performs in real-world conditions compared with Nearby Mode. That seems like it could be a very different experience depending on the connection.
Thank you! That "upload-first" bottleneck is the exact frustration that made me start building this. Waiting for a 4GB video to upload to the cloud just so the other person can finally start downloading it is maddening.
Regarding real-world performance, you are spot on—they are very different experiences, mostly governed by the physics of the network:
Nearby Mode: Since this uses Wi-Fi Direct, we are transferring over a local ad-hoc network. Speeds are completely decoupled from the internet and regularly hit 250+ Mbps depending on the phone's hardware. A massive 4K video transfers in seconds.
Anywhere Mode: Because this routes over the internet, the speed is entirely bottlenecked by the sender's ISP upload speed and the receiver's download speed.
However, even on a mediocre connection, it is still significantly faster than the cloud. With cloud storage, your total wait time is
(Upload Time) + (Download Time). With AirLynk's direct P2P QUIC tunnels, the transfer streams concurrently. Your total wait time is just thelongest(Sender Upload Time, Receiver Download Time).It effectively cuts the total waiting time in half, and you never have to sit around waiting for server-side video processing to finish!