It pretty much feels like the file is just uploaded and a link (string) is generated to communicate that over sound. The receiving browser then just uses that "download link" to download the actual file. The file uri also just downloads a file from their servers.
Just saying, as it's not really mentioned on the site as far as i can see.
Yeah. I transferred a music file at ~6mb. Sure enough a binary payload of that size is POSTed to their `/api/upload` and then downloaded from a CDN on the receiving side.
This is basically an ordinary file upload service using sound instead of sharing QR-codes or public links.
My disappointment is immeasurable and my day is ruined.
EDIT: My spidey sense was tingling when a 6mb file was transferred "via sound" in seconds. That would've been pretty incredible.
Yeah, I was experimenting with a similar thing a while back. The idea was to use camera equipped devices looking at each other to negotiate data transfer through dense QR-codes. Even with that substantially larger data frame support, transfer speed was abysmal at best.
Wow! One of those moments when you realize that someone is doing exactly what you have been doing. My hobby project was seriously called QRTX. And each data frame started with ###-- where # are padded frame numbers. Pretty much identical to this guys project. Thanks for that find, I'm chuckling.
Points of difference: I was using a leading metadata frame with filename and total number of frames etc, and the receiving device were ACK'ing frame decodes with its own QR codes. Still, wow.
It's been over two years since I looked at it, but from memory I wanted a 8 KiB key pair that I could engrave. One was to be the public key that would be scannable, the other was the private key that would be kept in a safety deposit box.
The practical limit was 3KiB for the qr code and there was some metadata in the key I didn't want to lose. I can't remember if it was the private or public key that was giving me the most trouble. But the idea of just having something to point your phone at on a wall and read a signed message from me wasn't practical.
Compare also the FT8 weak signal radio protocol. Remarkably robust but serves a max of 77 bits per 15 seconds (and also hard codes radio specific codes/IDs in the message, it's not even general purpose)
The author (allegedly) confirms that this is what happens at [1]:
> it uses the internet to transfer the file while only sending the file's id though sound. The purpose of the project was to pair devices that are near each other without requiring the user to sign in to any accounts.
No wonder the audio sounded like a loop. I was wondering about what kind of encoding was being used, for this sound to be generated. Initially I thought it was related to the mp3 file I was "sending" (my computer has no mic), that it may have a pattern in it, but after attempting to send a pdf, the pattern was still there.
Feels like a ripoff, since if it uses the internet, it can't be used offline as the title suggests.
The dutch national broadcasting service had a program around 1980 where BASICODE (https://en.wikipedia.org/wiki/BASICODE) for homecomputers was transmitted.
Lots of home computers (ZX Spectrum, C64 etc) had audio I/O for storage on cassette tapes.
This is something with a completely unknown usecase to me but I'm amazed at how good it works and it seems like a really fun project, thanks for posting it!
Just saying, as it's not really mentioned on the site as far as i can see.