SecureBit.chat - P2P Encrypted Messenger Files

A one-frame invitation is now scanned in one go.

The bug

Since 5.9.0 an invitation is a single QR code, but the scanner still expected four.

Its chunk assembler was written for the old SB1: payload, which the generator always cuts into exactly four frames, so the expected count was hard-coded to 4. The assembler's fallback branch claims any non-JSON string longer than 100 characters — and an SB2: invitation is 151 to 170 characters. A complete, single-frame invitation was therefore filed as "chunk 1 of 4", and the scan sat waiting for three frames that do not exist.

Pasting the code as text was unaffected; only the camera path was.

The fix

SBQ2 payloads are recognised as complete before any chunk assembly runs, in both the text (SB2:) and raw-byte (0x02) forms. The branch clears any partial chunk buffer first, so a stray frame from an earlier attempt cannot be spliced onto a complete invitation.

The hard-coded frame count is now explicitly marked as belonging to SB1, which still uses the four-frame animated path.

Note

Both peers must be on 5.9.0 or newer. A client older than that cannot read an SBQ2 invitation at all.