Skip to content

Make max fragment length configurable at encode time - #3

Open
n13 wants to merge 1 commit into
mainfrom
feature/configurable-fragment-length
Open

Make max fragment length configurable at encode time#3
n13 wants to merge 1 commit into
mainfrom
feature/configurable-fragment-length

Conversation

@n13

@n13 n13 commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Lets clients choose the bytes per QR fragment instead of the hardcoded 200, so animated QR transfers can use fewer, denser frames (phone-to-phone scanning handles much denser QRs than hardware-wallet cameras).

  • New encode_bytes_with_options / encode_hex_with_options; existing encode_* keep the 200-byte default
  • Decoder accepts fragments up to 4096 bytes; the 200 KiB total-message envelope and all other validation are unchanged
  • Tests: 7219-byte payload → 5 frames at 1500 B/fragment, out-of-range lengths rejected

Add encode_bytes_with_options / encode_hex_with_options taking a
max_fragment_length so clients can trade fragment count for QR density
(fewer, denser frames scan faster phone-to-phone). The plain encode_*
functions keep the 200-byte default.

The decoder's per-fragment bound moves from 200 to 4096 bytes so it
accepts denser frames; the 200 KiB total-message envelope and all other
inbound validation are unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant