lockbitchat
e00c3bd413
A group is an orchestration layer over the pairwise sessions the app already holds. It owns no transport and no shared key: every frame leaves over a chat that is already SAS-verified and already ratcheted, so a removed member simply stops being sent anything. Membership is a roster the admin signs, ordered by epoch, and the safety code is a commit-then-reveal round over every member's fingerprint and nonce. Delivery was the part that did not match its own description. The admin held a link to everyone and nobody else held a link to anybody, so the relay path — the documented fallback — was in fact the entire topology, and the admin going away partitioned the group. Now, once the code is confirmed, each pair without a link dials one over that relay path. The descriptors are compact enough to ride a group frame and are signed with the sender's group identity key, so the relaying member can drop a dial but cannot substitute one. The member with the smaller fingerprint dials, which is the whole glare protocol. Mesh links are released without a human comparing digits. Twenty-eight codes for a group of eight is not a check anyone performs; the guarantee moves rather than disappears, since the descriptor was signed by a key the signed roster names and the group code covers. markGroupLinkVerified refuses any session whose in-band exchange has not completed and whose peer has not proved possession of that key. An existing 1:1 chat between two members is adopted instead of re-dialled, via a probe bound to that session's own key fingerprint so it cannot be replayed onto another chat to impersonate its author. Security fix: g_hello was accepted on any session from anyone who knew the group id, so any member could publish an identity the admin never invited and have the admin sign and broadcast a roster containing it. It is now accepted only on a session an invitation went out on, which also confines it to a direct link. Mesh connections are kept out of the chat registry and muted from the document events the header listens to, so a routing detail cannot tear down the display of a conversation the user actually opened.
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.