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.
KeithMukai / Keith Mukai
npub1tv…77wn2
2023-09-16 19:55:21
Author Public Key
npub1tv8gmfhalwnxxquxjzeh6gtdsdz6vg7vx0s3rt7s7uuw6aujh32qn77wn2Published at
2023-09-16 19:55:21Event JSON
{
"id": "16dd674931eaba78d31c49016c72613b5153e399e8a7e2702854ba826b56c336",
"pubkey": "5b0e8da6fdfba663038690b37d216d8345a623cc33e111afd0f738ed7792bc54",
"created_at": 1694886921,
"kind": 1,
"tags": [
[
"p",
"f2c96c97f6419a538f84cf3fa72e2194605e1848096e6e5170cce5b76799d400",
"",
"mention"
],
[
"t",
"5"
],
[
"t",
"13"
],
[
"t",
"22`"
],
[
"t",
"22"
],
[
"t",
"4"
]
],
"content": "Last night's nostr:npub17tyke9lkgxd98ruyeul6wt3pj3s9uxzgp9hxu5tsenjmweue6sqq4y3mgl experimental coding results: FASTER(?) QR code transfers back to the coordinator?\n\n(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)\n\nhttps://video.nostr.build/957946b09f316e161ac8727f19aa2e80044a0f6ced993b0cfaea49d3a2d0ed78.mp4\n\nAnd 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%.\n\nThe fountain encoding first figures out how many frames it takes to convey all the info. Call that `n`.\n\nSo, trivially, it starts by showing those `n` frames.\n\nBut after `n`, it starts merging random numbers of random frames (technically XOR).\n\ne.g. `frame #5 + #13 + #22`\n\nIF the decoder already has, say, frame #5 and frame #22, then it can use this merged/XORed frame to reconstruct frame #13.\n\nSo while Specter can accumulate a lot of these XOR frames but seemingly not make much decoding progress.\n\nIt'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.\n\nAs soon as it finally sees #22, now it knows #13. And that then unlocks #4... which unlocks...\n\nAnd 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.\n\nSo not a crash, just a non-intuitive, sudden domino cascade that's hard to convey in a percent status.\n\nYou almost need a sort of potential energy meter: \"I don't know the answers yet, but this dam 'bout to burst, y'all!!\"\n\nAnyway, I still have a lot more to learn here and more testing to try out.\n\nBut 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.",
"sig": "e43e311480ba1e422c91a799514ccb1e0496ed5713d013a916eda7e320120f1d10f645d4eadbf0488549908e7023a14a4bb13f444b1876f047a85a9c14c433f1"
}