The scanner waited for four frames when shown a single one. Its chunk assembler was written for SB1, which the generator always cuts into exactly four frames, and its fallback branch claims any non-JSON string longer than 100 characters — which a 151-character SBQ2 invitation is. A complete invitation was filed as chunk 1 of 4, and the scan never finished. SBQ2 payloads are now recognised as complete before any assembly runs, in both the text and raw-byte forms, and the hard-coded frame count is marked as belonging to SB1 so it is not read as a general rule.
Documentation
Technical documentation for SecureBit.chat. Start with the project README if you are looking for an overview or a quick start.
| Document | What it covers |
|---|---|
| ARCHITECTURE.md | How a session is established, verified and torn down, and where each guarantee comes from |
| CRYPTOGRAPHY.md | Key schedule, the Double Ratchet, SAS verification, memory handling |
| DESCRIPTOR-SBQ2.md | The invitation format: wire layout, why it is small, the in-band key exchange, decoder rules |
| CONFIGURATION.md | Deployment, ICE and TURN setup, privacy modes, file transfer policy |
| CALLS.md | Voice and video: codec choices, adaptation, and why each value was picked |
| API.md | Internal interfaces of the WebRTC manager and file transfer system |
| CONTRIBUTING.md | Development workflow and what needs extra review |
| USE-POLICY.md | Terms of use, intended use, and the limits of what the software can protect |
Security policy and vulnerability reporting live in SECURITY.md at the repository root, where GitHub expects to find them.
Keeping this accurate
These documents describe the current release and are expected to change with it. Every value quoted here (limits, timeouts, algorithm parameters) is taken from the source rather than restated from memory, so if you change one in code, change it here in the same commit. CONTRIBUTING.md lists which documents are affected by which areas of the code.