I can only suggest his definition of cross platform may actually mean "works on iOS in compliance with Apple policies".
While those all will work well on major PC OSes and for the most part on Android devices, Apple's policies are quite strict about running compilers and interpreters on device last I checked. Meaning you need compiled code in some way, shape or form.
Apple removed the blank ban on interpreters more than five years ago. The restriction now only applies to interpreters running user-provided/dynamic code. If you're bundling it with the application, as you would here, it's allowed -- and many popular games rely on this.
Somehow Kivy applications are allowed permitting a bundled python interpreter... I've never looked into the rules but know of examples in the app store.
> I need an explanation how these implementations are not "cross-platform" yet his Go implementation is.
OP here. I agree the wording is a bit unfortunate here, as all languages mentioned were designed to be cross-platform. I was referring rather to the practical complexity of using the code in different environments - native desktop, mobile (Android/iOS) and Web (JS/WASM).
With Go you can take normal Go code and build it for iOS/Android/Web in a few seconds with a minimal effort. I personally don't know if this even possible for Java/Python/JS, let alone with such an ease.
Hah, cool! This reminds me of an old 4chan thread where people were trying to get free file storage on YouTube by uploading video's of QR code sequences with files encoded into them. Much less useful than Txqr, but fun nonetheless.
Holy crap, I remember that exact thread, I was part of it. The OP made a program that just encodes files into a series of QR codes, but I told them that with some additional effort, encoding it into a format that would get less manged by YouTube's compression would make it a lot better.
Nice, thanks for the link – I did pretty extensive search, but haven't found this one. I like how similar was path from naive implementation to the fountain codes as with txqr.
Great stuff! QR code is optimized for low error rates when the channel is a digital camera-based, single photo capture. If one uses a code designed for multiple capture over time (some video code), the transfer speed could be increased significantly. Thinking of it like a very noisy fibre optic channel, there's plenty of room for improvement.
Nope. Apple Watch pairing is unidirectional and low-bandwidth, and uses extremely cool patented technique with hiding data in luminance changes. It's exploiting the fact that human eye is so much more sensitive to the chrominance changes, rather than luminance, but computers is not.
http://www.iphonehacks.com/2015/05/new-apple-patents-explain...
What’s the transfer speed, are there practical file size limits? Do you have to wait for it to loop or can the reader pick up in the middle of the stream?
Fountain codes are made so the receiver can pick up anywhere in a stream, and pick up the data with 0.1% to a few percent overhead (depending on luck and loss rate). This particular implementation loops the same set of encoded packets as QR codes, but with a faster processor you’d want to generate a pseudo infinite stream of encoded packets. If your data size was 1MB with 10kb packet size, readers can decode it with any 100(+ a couple percent) packets.
There was a follow-up post[1] where the author switched to fountain codes (a type of erasure coding that is perfect for this use-case) and apparently the speed is now closer to 25kbps. Pretty neat.
Never knew about this, but of course it exists! In the digital video tape world, it was common to do backups to tape. The old Flame/Inferno systems would do archives to D1 by laying down all of the video elements including the mattes as video, and then save the actual project code as data afterwards. When played back, it would look like black&white snow/noise. Maybe it was at the beginning, don’t remember exactly. However, at the time, I had just assumed it was just noise, but now wonder if the black&white patterns was the data like a QR code. A blank VHS tape would display static as well, but a blank digital tape would not. That’s what made these archives stand out to me.
I understand the challenges involved, but if an algorithm were fault tolerant enough to handle a flip book of qr codes, one could manually animate a file transfer. :)
QR codes are fault tolerant enough that I was able to hand-draw (pen on paper) a 25x25 code as part of a christmas gift this year. I wasn't very precise either. For animation I think the main drawback is the slow speed of typical scanner apps.
Me and a friend put together this basic idea a few years ago at a hackathon. At the time we thought it was very funny to code something so useless (no offense to OP). Looks like we missed out on some sweet HN karma!
This oddly overlapped with just learning about bitcoinfibre [1], which uses forward error correction (FEC) to fill packets with extra data to speed up network transfers by preventing retransmissions.
I had already begun using QR codes to provide signed urls to images (graphs showing data and the like). Something like this permits transferring the graph image directly. Walk up to a smart device and retrieve its data without any convoluted pairing process.
Back in the early days of smartphones (iPhone, iPhone 3, iPhone 3GS era), Marshall Field's flagship department store in Chicago experimented with this.
Each display window had a bunch of stickers on it, similar to QR codes. You could use the app on your phone to point your camera at one of the stickers and get more information about different products on display.
They also tried something similar with a different app and some kind of Bluetooth connection.
All of this was still early days, so it didn't work very well. It would probably be OK now that the technology has matured.
I’ve been contemplating writing this same thing for the past few years. Thanks! Although the security implications to many businesses that think they’ve locked down their end clients will be huge. Most SIEMs looking for data exfiltration will analyze email attachments, outbound network connections, etc. This is a new vector that’s extremely hard to police. Can you scale the QR codes up to higher resolution, increasing the bandwidth you can transfer over the video interface?
I can't think of any actually useful applications (the one given only makes vague sense if you pretend bluetooth doesn't exists), but it's a cool demo anyway and the linked blog posts are excellent.
Offline data sync from an old device to a new one. Many phone carriers provide for something similar in a QR code. My team has an app we developed that has a similar function because the private keys and all of the wallet items are exclusively offline. We show an qr code today. The issue we have hit lately is that the amount of data we have is more than a single code. Depending on the number of wallet items the users have. The animated QR is a good solution for this.
If someone is interested in how we got an amazingly small QR using base-91 and some other cool methods here is a good read with demo code
Why not just use a single code for bluetooth/wifi hand shaking? Wouldn't that be more efficient by any metric and almost as compatible? What device has a solid camera and no wireless communication?
Why not both? There is always the potential that there is an actual reason to upgrade - and borked motherboards where any such modules are damaged as a potential reason.
If this was more widespread or built into phones like QR code scanning is in the camera app, it could be an interesting way to share data with many people at once (something like a concert for example)
But I agree it's more interesting from a technical point of view over a practical one...
Bluetooth pairing isn't really as easy as this would be in theory (especially if we're talking about a situation where you want to send a message through a crowd of people -- so congestion will be pretty bad).
A device would only need a camera to receive information, and yes, at the point you need bidirectional transfer, I'd concede that this isn't the best method.
However, adding a small lcd display allows the presentation of human readable data as well, and many devices already have screens on them.
(I always thought serial over TRS (headphone) cable would be an interesting option as well.)
Face-to-face key signing/exchange, or any other kind of in person secret sharing, perhaps?
BT/Wifi methods will broadcast data to anyone within radio range, but optical data exchange like this can take place under your coat, or using some easy means of protecting the transfer against 3rd party listeners.
It should have a multitude of applications where pairing is difficult, but physical presence of the device is necessary.
Some applications from the top of my head.
1. Access to buildings/restricted areas etc. can be made more secure, by using higher data content with animated codes, foregoing the requirement of the device having an internet connection.
2. Transfer data to a large crowd of people, say at a concert, etc.
3. Pairing of devices where one device cannot have bluetooth or other wireless hardware (due to power / security constraints)
Honestly, this is another channel of communication between devices and it's exciting.
wat. I need an explanation how these implementations are not "cross-platform" yet his Go implementation is.
1 - from the author's blog post at https://divan.github.io/posts/animatedqr/