KeithMukai on Nostr: Last night's SeedSigner experimental coding results: FASTER(?) QR code transfers back ...
Last night's SeedSigner (npub17ty…3mgl) experimental coding results: FASTER(?) QR code transfers back to the coordinator?
(shot from the exciting confines of my covid-induced hotel room isolation in Nashville! Basically a whole lost week reduced to napping and some coding when my energy held up)
And I think I was wrong when I called the abrupt Specter scanning exit a "crash". The fountain encoding used by these animated QRs is complicated; it's possible that Specter really was finished scanning, despite the percent readout only being ~30%.
The fountain encoding first figures out how many frames it takes to convey all the info. Call that `n`.
So, trivially, it starts by showing those `n` frames.
But after `n`, it starts merging random numbers of random frames (technically XOR).
e.g. `frame #5 + #13 + #22`
IF the decoder already has, say, frame #5 and frame #22, then it can use this merged/XORed frame to reconstruct frame #13.
So while Specter can accumulate a lot of these XOR frames but seemingly not make much decoding progress.
It's like setting up dominoes; the scene is being set for lots of cascading effects to happen, a whole sequence waiting to be unlocked if it can just get the starting point to trigger.
As soon as it finally sees #22, now it knows #13. And that then unlocks #4... which unlocks...
And so when I pressed the button to restart the fountain encoding, I started supplying it with those first n complete frames and the unlocks could then cascade like crazy.
So not a crash, just a non-intuitive, sudden domino cascade that's hard to convey in a percent status.
You almost need a sort of potential energy meter: "I don't know the answers yet, but this dam 'bout to burst, y'all!!"
Anyway, I still have a lot more to learn here and more testing to try out.
But I think the inherent design of fountain encoding plus a well-applied restart to the sequence could make a lot of sense for this use case.
(shot from the exciting confines of my covid-induced hotel room isolation in Nashville! Basically a whole lost week reduced to napping and some coding when my energy held up)
And I think I was wrong when I called the abrupt Specter scanning exit a "crash". The fountain encoding used by these animated QRs is complicated; it's possible that Specter really was finished scanning, despite the percent readout only being ~30%.
The fountain encoding first figures out how many frames it takes to convey all the info. Call that `n`.
So, trivially, it starts by showing those `n` frames.
But after `n`, it starts merging random numbers of random frames (technically XOR).
e.g. `frame #5 + #13 + #22`
IF the decoder already has, say, frame #5 and frame #22, then it can use this merged/XORed frame to reconstruct frame #13.
So while Specter can accumulate a lot of these XOR frames but seemingly not make much decoding progress.
It's like setting up dominoes; the scene is being set for lots of cascading effects to happen, a whole sequence waiting to be unlocked if it can just get the starting point to trigger.
As soon as it finally sees #22, now it knows #13. And that then unlocks #4... which unlocks...
And so when I pressed the button to restart the fountain encoding, I started supplying it with those first n complete frames and the unlocks could then cascade like crazy.
So not a crash, just a non-intuitive, sudden domino cascade that's hard to convey in a percent status.
You almost need a sort of potential energy meter: "I don't know the answers yet, but this dam 'bout to burst, y'all!!"
Anyway, I still have a lot more to learn here and more testing to try out.
But I think the inherent design of fountain encoding plus a well-applied restart to the sequence could make a lot of sense for this use case.