Group calls are a new capability, and 6.6.6 only landed as a patch because the
version was bumped once per deploy while the feature was being tested. The
number is the release's, not the deploy's.
No code changes: version, badge, changelog heading, docs and build stamp.
Claude-Session: https://claude.ai/code/session_01XSxAkET3hQTkYDQfbjCQwZ
A group call is N-1 ordinary 1:1 calls, one to each other member, each riding
the pairwise session that member already has — a transport a human already
authenticated by comparing the safety code. No mixer, no SFU, no point at which
two people's media meets anywhere but on a device.
Call control is separate from call media, because the two reach different sets
of people. Who opened a call, who joined and who left travels as group frames
signed with the sender's group identity key, so it reaches members currently
reachable only through a relay — and a relaying member can drop one but cannot
write one. Media flows only where a direct link exists, so a member without one
shows as connecting rather than being omitted. Frames carry a per-sender
sequence checked before the action, so a captured leave cannot end a later call,
and simultaneous calls converge on the lower random call id.
One capture is shared across every leg rather than one getUserMedia per member,
and legs answer without prompting: the flag permitting that is set only locally,
only while this user is in the call, and cleared when they leave.
UI: a gallery that sizes itself from the space it has, a spotlight view, an
active-speaker indicator read from the waveform, and the call surface in the
same visual language as the 1:1 one.
Also in this commit, the v6.5.0 language-suggestion work that had not been
pushed yet; its notes are in the changelog. And two fixes: the safety-code input
asks for digits rather than text, and starting a new chat from inside a group no
longer creates it behind the group where it cannot be seen — which had made it
impossible to connect to anyone new, or to add anyone to a group, while a group
was open.
Claude-Session: https://claude.ai/code/session_01XSxAkET3hQTkYDQfbjCQwZ
Four right-to-left languages at /ar/, /he/, /fa/ and /ur/ — thirteen in all.
The layout no longer has a left and a right, it has a start and an end: the
margins, insets and corners are CSS logical properties now, so they follow
dir on <html>. Directional glyphs flip; keys, safety codes and session
descriptors are pinned left-to-right so bidi cannot reorder what two people
compare against each other's screens.
Also fixed: the Service Worker was registered as './sw.js', which 404s from
every locale subdirectory, so twelve of the thirteen pages had no worker at
all. And the bundler ran before the dictionaries were generated, so a newly
added language could reach the page ahead of the app that renders it.
The site now speaks German, French, Spanish, Ukrainian, Russian, Chinese,
Korean and Hindi alongside English — 623 strings per language, 5,607
translations, covering the landing page, the key exchange, the chat, group
calls and every error along the way.
Each locale is a real page at a real URL (/de/, /fr/, …), generated at build
time from locales/*.json. That is the whole point: the app is client-rendered,
so a language that only swaps strings at runtime has no address for a crawler
to index and no link anyone can share. Each page carries its own canonical, a
reciprocal hreflang cluster and translated schema.org.
The URL decides the language, always. A stored preference only applies where
the address does not say, and nothing ever redirects on Accept-Language —
that is how sites become invisible to search engines outside one country.
robots.txt and sitemap.xml did not exist before; both are generated now.
Bugs found on the way, each with a test that would have caught it:
- partner logos used page-relative paths and 404'd from any /xx/ page
- post-build stamped ?v= only into the root shell, leaving locales behind
- "Back online" appeared on every page load, not just after being offline
- update timestamps were hard-coded to US format for every reader
- t() threw on a partial window, taking whole components down with it
The mobile menu becomes a surface you drag rather than one that appears and
vanishes: it tracks the finger, carries its velocity when flicked, can be caught
mid-flight, and resists past the edge instead of stopping dead. Buttons react on
press rather than on release, and the browser's tap delay is gone — nothing here
zooms, so the wait bought nothing.
prefers-reduced-motion, prefers-reduced-transparency and prefers-contrast are
now respected instead of ignored: looping decoration stops, transitions fade
rather than slide, the chat jumps to the newest message, frosted panels turn
solid and edges get drawn. What stops is the movement, never the information —
recording indicators and other status stay.
Also bumps the desktop download buttons to 0.5.0. The version lives in one
constant per source file and tests/desktop-download-links.test.mjs fetches every
generated URL, so the links are proven to serve a real asset rather than merely
looking well-formed.
Claude-Session: https://claude.ai/code/session_01ARFZ9G6P1e1B4w75kFaeNw
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.
The chat did not lay out correctly on phones, iPhone worst of all: the header
would not stay at the top, and the layout shifted as you scrolled or opened the
keyboard.
The root cause was a floor, not a position. The app shell and column both carry
.minimal-bg, which sets min-height:100vh — and min-height always beats height. On
iOS 100vh is the URL-bar-retracted *large* viewport, so with the bar showing the
shell was held some 60-100px taller than the visible area. That surplus made the
document scrollable, and a scrolling document is how the header rode off the top.
It also left the visual-viewport tracking inert: forcing --sb-vh to 700px left the
shell at 844px. With the floor removed it follows to 700px and the document does
not scroll.
Also: the app shell is now sized from visualViewport rather than pinned, the
message list is the only scroller and can actually shrink, safe-area padding
applies (viewport-fit=cover) and collapses under the keyboard, and the
online/offline toast no longer sits on top of the header.
Adds ?preview=chat, which renders the chat layout with canned content and no
connection — presentational only, no peer manager, keys, or network.
Verified in an emulated iPhone viewport at rest and with the keyboard open:
header pinned at 0-64, composer flush to the keyboard line, document unscrollable.
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.
The README, ARCHITECTURE.md and CRYPTOGRAPHY.md still described the old
handshake: keys and a session salt travelling inside the invitation, and a safety
code derived from the two DTLS fingerprints. None of that has been true since
5.9.0.
Adds a "The invitation" section to the README covering what the exchange was
reduced to and why that is a security change and not only a smaller QR code:
less material exposed before anyone is authenticated, the DTLS fingerprint as the
anchor, substituted keys failing closed on the commitment instead of on a human
comparison, a safety code that now covers the whole transcript rather than two
fingerprints, and the plain fact that a single QR is scanned in person where a
four-frame animated one pushes people to paste the invitation through a chat app.
Session lifecycle in ARCHITECTURE.md gains the in-band key exchange as its own
step. CRYPTOGRAPHY.md now states that the salt is derived from the transcript
rather than transmitted, and describes the transcript SAS and the signature that
replaced the challenge/response. DESCRIPTOR-SBQ2.md is listed in the doc index
and in the CONTRIBUTING impact table.
The invitation carried the whole session: both public keys, their signatures, a
salt, a challenge and the full SDP. It now carries only what brings up DTLS —
ICE credentials, the certificate fingerprint, candidates, an expiry — plus a
16-byte commitment to the key material. The key material itself moves to the
DataChannel and is checked against that commitment before it is parsed.
Measured on the live site: 2274 characters across 4 animated QR frames became
151 characters in a single frame.
The safety code is now computed over a transcript of both descriptors and both
key blobs, and the HKDF salt is derived from that same transcript instead of
being transmitted. authProof is replaced by one signature over it.
SBQ2_SEND_ENABLED is the single value that reverts new invitations to SB1.
Live cross-browser testing found three defects in the SBQ2 SDP template, all
invisible to Chrome and all fatal to Firefox.
The candidate lines omitted raddr/rport on srflx and relay candidates. RFC 8839
section 5.1 makes rel-addr and rel-port mandatory for non-host candidates even
though ICE never reads them; Chrome tolerates the omission and Firefox drops the
candidate. Relay-only connections to Firefox failed 0/8 against 8/8 for the
browser's own SDP. The STUN and TURN profiles hid it because a host pair
connected instead -- the relay candidates were never actually needed there.
The template also advertised ice-options:trickle without ever closing the
candidate set, though a descriptor is a complete one-shot set with no channel to
trickle over, and hard-coded the m= port and c= line to the 9 / 0.0.0.0 null
default candidate, which is the trickle convention for "nothing gathered yet".
Both are now correct: no trickle, an explicit a=end-of-candidates, and the most
publicly reachable candidate as the default.
All three are serializer-side and cost zero descriptor bytes; sizes are
unchanged at 98-149 bytes, QR version 6-8. Verified 48/48 across all 16
combinations of {Chrome, Firefox} squared and four network profiles, with every
relay-only pair now connecting over the relay.
The SB1 invitation runs 2000-2400 characters and needs QR version 38-40, past
the point where a single code is scannable, so the app falls back to an
animated multi-frame QR. SBQ2 is a fixed binary layout carrying only what
brings up DTLS -- ICE credentials, certificate fingerprint, candidates -- with
the SDP rebuilt from a template by a strict serializer. Measured on real Chrome
and Firefox SDP across four network profiles: 98-149 bytes, QR version 6-8.
Key material is meant to move to the DataChannel, bound by a commitment in the
descriptor. That half does not exist yet, so nothing calls this module: the
format is landed for review and freeze, not wired into the connection path.
doc/DESCRIPTOR-SBQ2.md records the gate on phase 3.
The decoder is a parser of hostile input: fixed offsets, explicit lengths,
deny-by-default on reserved values and unknown TLV extension types, trailing
bytes rejected, ICE credentials alphabet-checked so a CRLF cannot reach the
serializer. No compression -- DEFLATE adds bytes on this payload, and dropping
it removes the decompression-bomb surface with it.
Candidate pruning keeps coverage before count: one candidate per (family, type,
transport) survives before any surplus, so an IPv6-only or UDP-blocked path
cannot be pruned away by a v4-first sort.
Tests cover round-trip against captured Chrome and Firefox SDP, IPv6 and NAT64
addresses, ICE-TCP candidates, the TLV area, clock skew, one-shot binding and
SAS transcript coverage.
No protocol or message-protection changes.
The version in the application header was a literal and had fallen behind,
showing v5.6.0 while running 5.7.1. It now comes from package.json, and a test
fails if a hard-coded one reappears or if meta.json, the README badge, the
changelog and the docs disagree about the release.
Documentation reorganised so that everything technical lives in doc/ with an
index, and the root keeps only what belongs there by convention: README,
SECURITY, CHANGELOG and LICENSE.
- SECURITY.md rewritten. It listed a supported release line three major versions
out of date and made claims the software does not make. It now states what is
guaranteed, what is not, and how to report a problem.
- SECURITY_DISCLAIMER.md and RESPONSIBLE_USE.md merged into doc/USE-POLICY.md,
which says what the software cannot protect against rather than listing
generic advice.
- doc/SECURITY-ARCHITECTURE.md renamed to doc/ARCHITECTURE.md and rewritten
around the session lifecycle, what verification gates, and how recovery works.
- doc/CRYPTOGRAPHY.md rewritten: key schedule, the Double Ratchet, framing, and
memory handling, with values taken from the source rather than restated.
- doc/CONFIGURATION.md rewritten with the real file-type policy, ICE and TURN
guidance, and the deployment caching rules that matter.
- docs/webrtc-config.md moved to doc/CALLS.md and rewritten; the obsolete
docs/webrtc-audit.md, a working document full of stale line numbers, removed
along with the docs/ directory.
- doc/CONTRIBUTING.md records what the recent regressions taught us about
writing tests that can actually fail.
- doc/README.md added as an index.
Internal security review notes are excluded from the repository via .gitignore.
Those describe attack paths against specific releases in enough detail to
reproduce them, which is useful privately and harmful in public while users are
still updating.
Adds the Double Ratchet (Signal's design) on top of the existing ECDH session
keys, so message protection no longer rests on one set of keys lasting the whole
conversation. Every message gets its own key, derived through a one-way function
and discarded after use, and each change of direction introduces a fresh ECDH
key pair that re-keys the session root.
The ratchet needed no handshake change: both peers already hold each other's
authenticated ECDH public key, and the safety code compared during verification
covers exactly those keys. Its root is derived from the existing shared secret
through its own branch of the key schedule.
Support is negotiated in the invitation and response and used only when both
sides have it; a peer on an earlier release falls back to per-session keys. The
security panel reports which of the two is actually in force.
Out-of-order delivery is supported within fixed bounds (512 skipped keys per
chain, 1024 retained, five-minute expiry), and inbound frames are authenticated
before any ratchet state is committed, so a malformed frame cannot desynchronise
a live session.
Also in this release:
- Verification is enforced as a gate, not a label: control frames (reconnection
signalling, call setup, message deletion, delivery receipts) are acted on only
after both peers have compared the safety code, and verified state is set in a
single guarded place.
- Chat content reaches the interface through one authenticated path; an older,
weaker inbound path was retired.
- The security panel measures what it displays — several checks previously
returned a fixed result and now exercise the subsystem they describe.
- Invitation data is no longer kept in local storage, and entries left by earlier
versions are cleared on first launch.
- View-once and disappearing messages no longer place their text in system
notifications.
- Shared-secret buffers are overwritten once derivation completes; scanned QR
codes are decompressed with a size limit; voice notes are validated against
audio type and size budgets before skipping the consent prompt; the master
password is collected by the app rather than a browser dialog.
- Connection setup no longer fails on networks where STUN/TURN are unreachable:
it proceeds as soon as usable candidates exist and only waits while there are
none.
Test suite grows from 27 to 41 files, covering forward secrecy, post-compromise
re-keying, out-of-order delivery across ratchet steps, the skipped-key bounds,
tamper resistance, negotiation fallback, and byte-level key-derivation
compatibility with 5.6.0.
- Record voice notes in-browser, sent over the chunked AES-GCM file-transfer
channel (per-file session key + signed SHA-256 integrity).
- Captured as PCM and encoded to WAV for universal playback (incl. iOS/Safari);
auto-accepted and played inline from an in-memory blob, never written to disk.
- Composer mic button with live waveform + timer; desktop shows mic + send side
by side, mobile swaps mic to send when typing.
- CSP media-src now allows blob: so recorded/received audio can play.
- Roadmap: Desktop Edition -> 5.0, new 5.5 'Secure Voice & Calls', later
milestones shifted; version bumped to 5.4.5.
- Update README, docs (security/API/cryptography), and CHANGELOG.
- Implemented proper RFC 5869 compliant HKDF key derivation process
- Added Perfect Forward Secrecy (PFS) key for enhanced session security
- Improved key separation using unique info parameters for each derived key
- Enhanced salt size from 32 to 64 bytes for increased entropy
- Added comprehensive key validation and error handling
- Implemented proper ECDH + HKDF integration following Web Crypto API best practices
- Added metadata encryption key for enhanced data protection
- Improved compatibility with modern cryptographic standards (RFC 7748, NIST SP 800-56A)
-Enhanced logging and debugging capabilities for cryptographic operations
- Maintained backward compatibility while upgrading security infrastructure
Security improvements:
- Cryptographic isolation between different key purposes
- Enhanced protection against cross-key attacks
- Improved resistance to future key compromise scenarios
- Better compliance with OWASP cryptographic storage guidelines
Technical details:
- Refactored deriveSharedKeys() method for proper HKDF implementation
- Updated WebRTC manager to use new messageKey API
- Added comprehensive error handling and validation
- Improved browser compatibility with standardized cryptographic operations
- This update strengthens the existing security foundation with modern cryptographic practices while maintaining full system compatibility.
BREAKING CHANGE: Project renamed from LockBit.chat to SecureBit.chat
- Changed project name to avoid confusion with LockBit ransomware group
- Updated all documentation, branding, and references
- Maintained all existing functionality and security features
- Domain migration planned to securebit.chat
Reason: The LockBit name became associated with a notorious ransomware
group, causing conflicts on platforms and potential confusion for users.
SecureBit better reflects our mission of providing secure P2P messaging
while avoiding negative associations.
This change affects:
- README.md and all documentation
- Package.json name field
- Brand assets and logos
- Website references
- Social media handles
Core functionality remains unchanged:
✅ 12-layer military-grade security
✅ Lightning Network integration
✅ P2P WebRTC architecture
✅ Open source MIT license
SecureBitChatVolodymyr