all 11 comments

sorted by: hot top controversial new old
[–] 6 points 5 months ago (1 child)
  • [–] 2 points 5 months ago

    That looks like a way more involved and complex project that requires an app to function. This is just a single static HTML page.

    Sender and receiver visit the same page, select the appropriate tab, sender selects the file and clicks play, receiver starts the camera and points at sender's screen.

    I do wish it had a mechanism to download the generated images/video without needing to grab each frame individually, but overall it works surprisingly well for something so simple.

  • source
  • parent
  • [–] 4 points 5 months ago (6 children)

    So, anyone knows where the data is stored in between?

  • source
  • hideshow 6 child comments
  • [–] 10 points 5 months ago (5 children)

    Based on my brief browsing of the code, it looks like it's all in the browser cache itself. The bytes are split into numbered chunks, converted to b64, and then a sequence of QR codes are generated from the b64. At the end the received data is crc32 checked for validation. There are adjustable parameters and a progress bar, making it easy to retransmit any chunk that wasn't properly received.

    The code is incredibly easy to read, everything is in a single HTML file with zero obfuscation (unless you count the two minified QR code dependencies that also include links to the un-minified versions).

  • source
  • parent
  • hideshow 5 child comments
  • [–] 2 points 5 months ago (4 children)

    You mean it's all in the QR codes? Interesting, but also insane lol 😆

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 5 months ago (3 children)

    Well yes, but also no.

    The data is all contained in the QR codes, but it's also contained in the cache of the sender (which is how any chunk can be arbitrarily retransmitted), and also in the cache of the receiver (which is how the data is validated).

  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 5 months ago (2 children)

    Well it's kind of obvious the sender has the plain data right 😌 and temporarily stored in the receiver somewhere.

    Does it play like a qrcode video, or is it more manual?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 5 months ago

    I suppose that's true lol.

    Yes, it plays a video with an adjustable speed, or you can have it show a specific frame. The receiver has a grid that fills in as the data is received, making it easy to tell what data was or wasn't successfully received.

  • source
  • parent
  • [–] 1 point 5 months ago

    Janky ass CDS

    NOW implement bi-directional transport

  • source
  • [–] 1 point 5 months ago

    Woah! That's really cool!

  • source
  • 1 comment in c/programming@lemmy.ml view that post
    [–] 3 points 5 months ago* (last edited 5 months ago)

    Hmm, interesting project!

    Now I have to figure out how to send the program itself over qr codes ;)

    Edit: After playing around with it for a bit, I have some questions. Mostly, what's the real use case for this?

    A 1MB file turns into 4k-10k pictures depending on how many characters you choose. My camera keeps auto-adjusting and it misses most of the frames. I could place my phone on a stable surface, angled just right, and leave it overnight/a long time period to finish the transfer. But why would I do that?

    If I have no bluetooth, couldn't I just use sftp (or some even simpler protocol) over wifi , which should be supported even on ancient devices? Suppose wifi doesn't work either. How do I transfer the program itself?

    Even if I manage to transfer it, I couldn't run it directly on Ironfox, only on Via, so not all browsers support opening local files. I can run it on a local http server like apache, but if I can run that I probably can just transfer files via sftp.

    And even if somehow bluetooth, wifi and all the wireless connectivity fails... couldn't I just use a cable?

    I only can imagine 2 use cases:

    • Your phone's wireless connectivity is busted, you have a charging cable but it doesn't transmit data, and you manage to get the app on the phone somehow (maybe typing the code by hand). If you can even run the app, then you can painfully transfer files with it.
    • You want to transfer a very small file (in the order on 50-200KiB), you don't have easy access to sftp and your charging cable doesn't support data transfer or you can't be bothered to look for it. You can then use this app to transfer the file, in a reasonable amount of time (~1 min)

    Disclaimer: I tried this on a 10y/o phone running Android 7, and tried to open it on my current phone too but couldn't, and I couldn't be bothered to set up an http server to run it, or self-signed certs to run it from my pc.

    Sorry for the rant, I do think it's a neat project! I just can't find its usefulness other than being a fun trick xP

  • source