Proposal: UX enhancement for when Multipart frame cannot be scanned in time

[pmespresso]

This is a transferred from this issue in Parity Signer novasamatech/parity-signer#320. Low priority but food for thought.

as discussed with Maciej, there is a possibility that multipart payloads could get stuck infinitely with a particular fps.

for an example with 3 frames:

1. frame 1 cannot be scanned to completion before the the next frame is shown by hot wallet
2. hot wallet loops through the other frames, cold signer successfully scans them
3. we are now at 2/3 progress of scanning the frames
4. hot wallet loops back to 1st frame, cold signer fails to scan it in time yet again,
5. repeat steps 1 - 4 forever or till user gives up, cold signer remains at 2/3 progress, user is confused

The potential solutions brought up were to either:

• show the user a slider to slow down the FPS after a few cycles
• gradually slow down the FPS every cycle
• show toggle for frame size

[jacogr]

The auto-slowdown after a cycle may not be a bad thing. No clutter UI-wise.

[pmespresso]

One more thing I forgot to note: - Give user ability to skip to any particular frame number. novasamatech/parity-signer#426

This could be done without cluttering the UI if we just have a single slider.

[pmespresso]

recap on chat with @burdges, there are several variations of fountain codes that would provide much more practical UX improvements than having to scroll back to some frame index after missing it - novasamatech/parity-signer#457

I did some research on RaptorQ fountain codes; the only caveat is that the Offline Signer needs to initialize the Decoder with the Encoder's configuration, in other words, the encoder needs to transmit the configuration information over some reliable channel. I think the way to do that would be over a single frame QR.

So the process would look like:

Hot Wallet	Cold Signer
let encoded = Encoder::encode(payload)
QRDisplay(Encoder::get_config())
	Scan Encoder Config, i.e. ObjectTransmissionInformation
	Decoder::new(config)
QRDisplay(encoded)
	do the actual decoding

Maybe (likely) that I'm overlooking something, but according to these benchmarks this would be a huge improvement for things like offline metadata updates, system.setCode, contracts.upload (from minutes to seconds).

[burdges]

Is there entropy in the config or something that prevents it being fixed?

We should not require any setup round trip with most erasure codes, although they do need to know the size of what they're decoding, but presumably you can report that in every frame. In other words, a frame is (num_shards,shard_idx,shard_data).

[jacogr]

Can implement whatever the uos spec specifies, have no specific horse in the race. (Would just suggest updating the spec and then opening a specific issue).

[pmespresso]

there is no entropy in the config, it just needs to know the size of the data, but the RaptorQ library doesn't allow for configuring the extra shard info like that out of the box though maybe they're accepting PRs. So w.r.t to the UOS multipart spec, we'd just change the terminology a bit, i.e. (frame_idx, frame_count, part_data) to (shard_idx, shard_count, shard_data).