2.8 KiB
Volt-Chat whatsmeow PR 5: establish Signal sessions without sending messages
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | whatsapp-automation |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | feat: establish Signal sessions without sending messages (PR 5) |
| Source URL | https://github.com/Volt-Chat/whatsmeow/pull/5 |
| Source publisher / author | Santiago Santana |
| Source type | repository |
| Source date (published) | 2026-10-23 |
| Date researched | 2026-10-27 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct page fetch (patch) |
| Confidence | High for the premise, Medium for the patch itself (read the prekeys.go diff; the 388-line test file was skimmed, not analyzed) |
| Status | Active |
Summary
The PR states the premise outright: peer messages require an existing Signal session, but callers had no public operation to establish one without sending a message. It adds EnsureSession(device): resolve a phone-number JID through the stored PN-to-LID mapping (an absent mapping is an error), reuse a stored session when present, otherwise fetch the prekey bundle and process it under the send lock. Identity trust failures are returned without deleting identities or sessions.
Key findings
- Device zero selects the primary phone; only user servers (
s.whatsapp.net,lid) are accepted. - PN JIDs must resolve via the stored LID mapping first; encryption always targets the LID identity.
- An incoming message may establish the session during the prekey iq, so the store is re-checked after the fetch.
- Success establishes local encryption state only, not delivery to or acknowledgement by the remote device.
- The author notes live development-account verification remains pending.
Pros / strengths
- Makes explicit what whatsmeow main only implies through
ErrNoSession: a peer send without a session cannot work. - Conservative trust behavior (never deletes identity/session material on this path).
Cons / limitations / caveats
- A fork PR, not merged upstream at time of reading; no live verification claimed.
- Does not change what happens when the phone receives the peer message but never answers; it only guarantees the request can leave.
Relevance to tai
detz already fetched prekeys before a peer send, but trusted the result without checking. Following this PR's premise, WaClient::send_peer_message now verifies a session exists in the store after the fetch, logs the enc type (pkmsg first contact vs msg existing session), and returns failure loudly when there is no session, which triggers the PR-1268 rollback. No separate ensure API was needed: the check lives in the send path.
Changelog
| Date | Change |
|---|---|
| 2026-10-27 | Initial dossier created. |