Two issues found during view-once testing on linked devices:
1. msmsg block removal:
The "temporary fix" that discarded all msmsg-type encrypted messages
was also blocking legitimate view-once messages. On linked devices,
view-once arrives as msmsg encryption type. The block was originally
added to prevent crashes from missing messageSecret, but the existing
try/catch in the decrypt path already handles those errors gracefully
by marking the message as a CIPHERTEXT stub.
2. view_once_unavailable_fanout emission:
When a linked device receives a view-once, the WA server sends only
<unavailable type="view_once"/> (no <enc> with actual media content).
Previously this was silently acknowledged without emitting any event,
so consumers (zpro, astra-api, etc.) never knew a view-once arrived.
Now it emits the message as a CIPHERTEXT stub with key.isViewOnce=true
so consumers can display "view-once message received" in their UI.
Co-Authored-By: Renato Alcara
Two issues found during view-once testing on linked devices:
1. msmsg block removal:
The "temporary fix" that discarded all msmsg-type encrypted messages
was also blocking legitimate view-once messages. On linked devices,
view-once arrives as msmsg encryption type. The block was originally
added to prevent crashes from missing messageSecret, but the existing
try/catch in the decrypt path already handles those errors gracefully
by marking the message as a CIPHERTEXT stub.
2. view_once_unavailable_fanout emission:
When a linked device receives a view-once, the WA server sends only
<unavailable type="view_once"/> (no <enc> with actual media content).
Previously this was silently acknowledged without emitting any event,
so consumers (zpro, astra-api, etc.) never knew a view-once arrived.
Now it emits the message as a CIPHERTEXT stub with key.isViewOnce=true
so consumers can display "view-once message received" in their UI.
Co-Authored-By: Renato Alcara
* fix: respect caller-provided waveform for PTT audio messages
When sending PTT audio with an explicit waveform, Baileys unconditionally
overwrites it with getAudioWaveform() which returns undefined when
audio-decode is not installed — resulting in a flat line on WhatsApp.
Now only invokes getAudioWaveform() when no waveform is already provided,
matching the existing pattern used for jpegThumbnail (line 241).
Validated via CDP + Frida interception: WhatsApp waveform format is
64 bytes Uint8Array, values 0-99, byte-for-byte identical between
Android (audio_data table) and WA Web (model-storage IDB).
Ref: WhiskeySockets/Baileys#2443
Co-Authored-By: Renato Alcara
- 3841abca35 / ad5ea817f7: WA version updates — applied separately via our own version bumps
- d077902695: WA version update — same as above
- c4e5d1262a: Fix ack handling — high-risk 2718-line diff in messages-recv.ts, intentionally skipped
- 802d5f6efa: Fix mentions regression — already covered by existing rsalcara contextInfo logic
- 6afde71691: feat groups mentionAll — applied in previous commit
- Add mentionAll?: boolean to Mentionable type (upstream 6afde71691)
- Set contextInfo.nonJidMentions=1 for @everyone group mentions
- Use viewOnceMessageV2 (field 55) wrapper instead of legacy viewOnceMessage (field 37)
- Set viewOnce=true on inner imageMessage/videoMessage/audioMessage
- Route view-once media uploads to /o1/mms/* CDN via mediaTypeOverride
Co-Authored-By: Renato Alcará
Full rewrite covering all 8 interactive message types:
1. Menu Texto
2. Botões Quick Reply (tested up to 16 buttons)
3. Botões CTA — URL, Copy, Call
4. Lista Dropdown (10 sections × 3 rows = 30 items max)
5. Enquete/Poll
6. Apenas Botões Reply sem CTA
7. Apenas CTAs sem Quick Reply
8. Carrossel com Imagens (up to 10 cards)
Each type includes:
- Complete curl example with realistic data
- All parameters documented with types and limits
- Webhook payload structure received on click/select
- JavaScript helpers to parse each response type
Also includes:
- Platform compatibility table (Android / iOS / WA Web)
- Universal webhook router for all interactive response types
- Complete limits table per message type
- Account restrictions (hosted vs non-hosted)
Co-Authored-By: Renato Alará
Accounts registered as hosted (Meta Business Cloud API) have view-once
blocked by the WA server for all clients (Android, iOS, Web).
This is a server-side policy with no code workaround.
Added prominent warning block in section 1 and dedicated row in the
limitations table.
Co-Authored-By: Renato Alcará
Renato Alcara