Decimen Optical Transfer: fountain-coded QR file transfer
github.com48 points by ksec 3 days ago
48 points by ksec 3 days ago
Neat, finally an easy way of transferring files between devices that doesn't rely on online services -- no clue why we didn't solve that ages ago.
Adding encryption shouldn't be hard, as long as you can communicate the keys out of band.
Could probably achieve the same result using audio instead of video, but maybe that would be too annoying?
I had a Timex Data Watch over 30 years ago.
https://en.wikipedia.org/wiki/Timex_Datalink
It'd transfer phone numbers and calendar entries to the watch by blinking the screen of your computer. Kinda a 1 pixel version of this.
(I wonder where that ended up? From memory I threw it in a drawer when I finished the Windows 95 project I'd been working on, and switched to Mac. There was no Mac software to talk to it.)
Psion Series 5 and other PDAs had infra red (IrDA) ports for 'beam'ing contacts, transferring files, printing, etc.
1998 - https://groups.google.com/g/comp.sys.psion.misc/c/oFtTHyx6IR...
I have seen digital audio gear that solved firmware transfer like that. You basically go to a website on your phone and it flickers the screen and you hold it in front of a photosensitive bit of the device that needs to be updated for 20 seconds and done.
If your firmware is small enough to fit that model, it isn't a bad variant. Beats downloading a file, transferring it to a USB drive, sticking that in,...
If only they had a clean digital way of getting data into the system.
Listen, you do not want your firmware to be updated by playing a FLAC file.
FLAC? That shows some degree of advanced technology that I would assume the original device in question does not have.
It's "digital audio gear". It receives uncompressed PCM, which could come from your computer playing a FLAC.
right, so a very specific case of playing FLAC via an external device, not on the system itself. Ok, that makes more sense. Still don't get what the issue is. Put the device in the correct mode and play from whatever digital input or playback (CD, DAT etc) the system already has.
Okay, if there's a button you have to hold to enable firmware update then it's more sensible.
Probably still wouldn't want to use digital audio input though. Although it's a perfect digital stream, it's been processed in analog-like ways before it gets to the device - such as filtering and volume changes. So you'd still want to use a modem protocol over it.
That'd be a few 100 bytes at best… what firmware fits into that?
100 bytes in 20 seconds would only be 40 bps. Surely you can do better than that even using only one bit symbols (off/on).
> between devices that doesn't rely on online services -- no clue why we didn't solve that ages ago
Airdrop is a thing, but remember that Android phones are controlled by the online services company that wants you to use online services.
Actually it's the opposite - Airdrop is controlled by the vendor lock-in company that wants you to only buy its hardware.
> by the online services company that wants you to use online services
Do you mean the one that went to all the trouble to reverse engineer Airdrop so that people could access Apple's vendor-locked walled garden without the use of online services?
Bluetooth is a thing too and I think it is even faster than this qr code video transfer method. Of course still slower than Airdrop.
Indeed encryption should not be hard yet which situation do you have in mind where simply pulling away the emitting phone would not be enough? AFAIK the normal scenario is two persons in the same physical space so I am not sure what encryption would add.
Other cameras could presumably be snooping on the data transfer.
Realistically speaking with another phone in front and imagining how close one has to be for it to work reliably (as it is not a 64x64 pixels image) I think it would be really hard not to notice.
The same way you whisper to say something secret in a public space I would expect people who transfer something private in public would have the presence of mind not let other snoop on and react accordingly.
They could, you're right.
Usability is important though. If you have to type in a bunch of hex digits before sending, it won't be used.
As someone who has implemented acoustic modems (underwater comms)... yes, yes very annoying. It's like a demonic dolphin.
Bringing it into the ultra sonic band would help.
Fun fact about underwater acoustic data transfer and sonar: the extreme volumes used (130dB+) kill fish in the area.
You can do PSK31 across a room with just audio, but it is a kind of annoying noise after a while.
It's interesting that you learn to recognise patterns in the burbling tones after a while. "CQ CQ CQ" is very distinctive and after a while you can hear your own callsign in it. I guess it's not that different to very fast Morse.
Or SSTV! I recall a demo years ago where someone had SSTV running between a speaker at the focus of a small dish, across to the room to another small dish with a microphone...
There's a track on an Aphex Twin CD (yeah well it would be, eh?) called Bonus High Frequency Sounds that's an SSTV pic of him in his studio.
>Neither mode is encrypted: whatever is on the sending screen is readable by any camera pointed at it.
Something like this would be good for transferring the public key(s) associated with some cryptographic messaging identity. This would allow that to happen entirely offline. The optical nature of the transfer would prevent a potential MITM. The idea that an identity is being transferred would be fairly easy to impart to the user.
So the lack of encryption would be a feature and not a bug. This would enable later encryption which could then use any medium for the transfer in a completely secure way.
The actual article explaining the use for fountain codes in this use case: https://divan.dev/posts/fountaincodes/
Oooooooooooo.
I bet that's how satellite radios get their firmware updates and stuff.
Actually I bet it's how they get almost everything aside from the audio streams themselves. Metadata. Channel art. Subscription info. Traffic data. Weather maps. Receiver firmware... The satellite is a textbook-perfect fountain, and the receiver may tune in at any time during the stream, and may miss any random number of packets, but fairly quickly it has what it needs.
I believe the various categories of metadata are sent at different rates according to how promptly a newly-awakened receiver should be able to update itself, so what's actually on the air is an interleaved collection of fountain streams, yeah? Hmm.
I bet they don't, because they didn't know about it or didn't think of it.
I know GPS is a slow repeating stream (the ephemeris repeats every 30 seconds and the almanac every 12.5 minutes) but that probably came before fountain codes.
Speculation about the past is probably unnecessary.
Reed-Solomon/erasure codes have been in operations since the 1960s
https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_cor...
Although a repetition of any high-rate erasure code can act similarly to a fountain code, they aren't classed as such.
> The receiver can start receiving blocks from any point, receive blocks in any order, with any erasure probability – fountain codes will work as soon as you received K+ different blocks.
Thats just cool.
Apparently if you combine LT with a Reed-Solomon pre-coding stage, then it's a raptor code, which is better because it has a cooler name.
Is there a way to negotiate ongoing FPS? I was sending at 60 but only receiving at 40. When I changed TX to 30 the speed went though the roof! I better call a builder.
Otherwise ridiculously cool project. May author's pillow always be cool on both sides.
Naturally the first thing to test should be how far of a link can you create with LOS.
Radio's get intercepted, this is a cheap laser link.
I visual reminder that perfect compression is indistinguishable from random noise.
It is. Though there's almost always some uncompressed header so you know how to decompress it.
Fountain codes are so lit