Reference
Versions and release notes
A source version, an archived app and a deployed service are different things. This record is checked through September 5, 2026.
Current version record
| Version | Repository-recorded state | What that establishes |
|---|---|---|
| Build 148 client | In development | Current source, including review fixes and cap9 migration refinements. No archive or distribution is established by the source version. |
| Build 147 client | Archived beta | Archived September 3; recorded service update target. This does not establish that every tester installed it. |
| Build 146 client | Archived / submitted | Recorded minimum accepted build. Older clients are below the current service floor. |
| Build 148 server changes | Deployment recorded September 4 | Server-side remediation and update messaging. Client build 148 remains a separate release. |
No production system or tester phone was inspected for this documentation review. These states come from the project’s release record; they are not a fresh operational attestation.
Recent protocol milestones
Build 147 · capability 9
Per-run protected post-quantum header keys replace a session-stable protection key on capable pairs. The hybrid inner transport adds ML-KEM-768 inputs alongside X25519 when the endpoint has the required pinned KEM key. Migration and retained-key behavior matter: follow-up build 148 changes must not be attributed to the archived build.
Build 146 · capability 8
The beta floor moved the first-contact KEM to ML-KEM-1024, introduced a sealed initial and a salted message-encryption format, and reduced the message plaintext padding bucket to 512 bytes. The passphrase path uses vendored Argon2 reference source. Fresh random salts reduce accidental key/nonce reuse risk; they do not establish complete rollback safety.
Earlier beta work
Earlier builds added authenticated first-contact transcripts, anonymous queues, retry wrapping, call-attempt proof handling, recovery state machines and local-history controls. Historical build notes are evidence of work at that time, not a statement that every old build remains supported.
Version numbers inside a session
pv identifies a protocol profile, capability versions advertise behavior, and the envelope format identifies message encoding. They are not interchangeable with the app build number. Current released work uses pv4; the v5 research papers describe a separate frozen candidate, not “build 148’s protocol.”
See the wire reference and evidence policy before attaching a security claim to a version.
Reviewed · Review scope and versions