Skip to content

message: extract privacy tokens from LID-addressed conversations#1148

Open
Wormey1o wants to merge 1 commit into
tulir:mainfrom
Wormey1o:patch/lid-privacy-tokens
Open

message: extract privacy tokens from LID-addressed conversations#1148
Wormey1o wants to merge 1 commit into
tulir:mainfrom
Wormey1o:patch/lid-privacy-tokens

Conversation

@Wormey1o
Copy link
Copy Markdown

Problem

storeHistoricalMessageSecrets (in message.go) filters tcToken extraction to chatJID.Server == types.DefaultUserServer. Accounts that have migrated to LID addressing store their 1:1 chats under types.HiddenUserServer, so the history-sync payload yields zero privacy tokens for those chats.

The downstream effect on a freshly-paired companion device:

  • Receive path works (no tctoken required on inbound).
  • Group sends work (sender-key broadcast doesn't require a per-peer token).
  • 1:1 sends fail — the companion has no valid tctoken for the LID peer, the server returns stanza error 463, and the send is rejected.

The pre-existing tokens on the primary device stay on the primary; only new outbound tokens from the primary propagate to companions via app-state sync. For accounts that haven't sent anything recently, the companion has no path to obtain tokens at all — the bridge is effectively stuck on inbound-only for 1:1.

Fix

Include HiddenUserServer in the filter so LID-addressed chats get the same treatment as DefaultUserServer chats. One-line change.

if (chatJID.Server == types.DefaultUserServer || chatJID.Server == types.HiddenUserServer) && conv.GetTcToken() != nil {

Repro

  1. Pair a fresh whatsmeow companion against a WA account that uses LID addressing (any account whose 1:1 chats now show @lid JIDs — practically every post-LID-migration account).
  2. Wait for history sync to complete.
  3. From the companion, try SendMessage to a 1:1 LID peer that the user has previously messaged from the primary.
  4. WA returns stanza error 463.

After this patch and a re-pair, history sync extracts the tokens and the same send succeeds.

Notes

  • No behavioural change for DefaultUserServer chats.
  • No new dependency; same single comparison, OR'd with the LID-server case.
  • Verified end-to-end on a self-hosted bridge — re-pairing the same companion under the patched code produced three privacy tokens (matching the three expected LID peers) and 1:1 sends to all three succeeded.

storeHistoricalMessageSecrets currently filters tcToken extraction to
chatJID.Server == DefaultUserServer. Accounts that have migrated to LID
addressing store 1:1 chats under HiddenUserServer, so history sync yields
zero privacy tokens for those chats. Companion devices then can't satisfy
the tctoken requirement on outbound 1:1 sends and the server responds with
error 463.

Include HiddenUserServer in the filter so LID-addressed chats get the same
treatment as DefaultUserServer chats. Group sends are unaffected (sender-key
broadcast doesn't require a per-peer token).
@zennn08
Copy link
Copy Markdown

zennn08 commented May 19, 2026

nc work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants