WaWeb canonical pipeline

Do socket à mensagem

Como o WhatsApp Web sai do nada e chega a mandar e receber uma mensagem: abre um canal seguro, pede autorização ao celular principal, autentica a sessão, baixa o estado da conta e troca mensagens.

Envio e recebimento de mensagens

Detalhes do envio principal, ack/receipt, fanout e mensagem recebida do celular auxiliar.

Detalhes nesta página

Cada link abaixo abre um bloco analítico com leitura didática, contrato observado e mini pipeline.

Blocos Mensagem principal Ack + receipt do envio Preparação do fanout Fanout Dispositivo auxiliar envia Mensagem recebida Receipt de recebimento Sync pós-recebimento

Mensagem principal

observadorótulo inferidostanza 165 · seq 355

Leitura

Esse é o primeiro sent message do cliente no baseline. Chamamos de mensagem principal porque ela aparece antes do envio marcado com device_fanout; o rótulo é leitura do fluxo.

Attrsid, peer_recipient_pn, to, type.
Filhosparticipants com dois to; device-identity em bytes redigidos.

Mini pipeline

StanzaSeqContrato
165355sent message / participants+device-identity.
166-168357-360Resposta relacionada a tokens de negócio e ack de notificação.

peer_recipient_pn é nome estrutural; o telefone real não deve aparecer no HTML público.

Ack + receipt do envio

observadostanzas 169-176

Leitura

Confirmações não são uma coisa só. ack confirma processamento de stanza; receipt comunica estado de mensagem; e ainda há uma troca curta de iq/add no meio do bloco.

A captura passiva mostrou que acks e receipts de fundo também aparecem fora do envio de texto, normalmente em resposta a lote offline ou notificação.

AckStanza 169 tem phash; stanzas 171 e 175 são acks enviados pelo cliente, com attrs diferentes.
ReceiptStanzas 170, 174 e 176 comunicam estado/recibo.

Mini pipeline

StanzaSeqContrato
169363recv ack, attrs incluem phash.
170365recv receipt, attrs incluem recipient.
171367sent ack com attrs [class,id,to,type].
172-173369-371sent iq / add e resposta recv iq vazia.
174-176373-377recv receipt, sent ack sem type, e sent receipt.

Preparação do fanout

observadostanzas 177-187

Leitura

Entre o envio primário e o device_fanout, o cliente consulta estado de usuários, chaves, query, sync e addons. Essa etapa evita tratar o fanout como uma repetição cega.

Consultasusync, key, query, sync, my_addons.
Respostasusync, result, sync, list, my_addons.

Mini pipeline

StanzaSeqContrato
177-179379-383sent iq / usync, recv ack e resposta recv iq / usync.
180-184385-392key, query, sync, result, my_addons.
185-187395-399sync e list finais antes do fanout.

Fanout

observadosemântica inferidastanzas 188-199

Leitura

O fato observado é um segundo sent message com attr device_fanout. A leitura de que ele replica a mensagem para dispositivos vem do nome do atributo e do contrato multi-device.

Stanza 188sent message, attrs incluem device_fanout, filhos participants e device-identity.
Depoismy_addons, sync, ack, receipt, tokens e acks finais.

Mini pipeline

StanzaSeqContrato
188401sent message / device_fanout.
189-190403-405recv iq / my_addons e recv iq / sync.
191-196407-417ack, receipt, sent ack, add, receipt, sent ack.
197419recv iq vazio.
198-199421-422notification / tokens e respectivo ack.

Dispositivo auxiliar envia

evento externoantes da stanza 200

Leitura

Este bloco é contexto do cenário de teste, não um evento do contrato de pipeline. A primeira evidência observada no protocolo é a mensagem recebida na stanza 200.

Não vem do JSONLAção do Android auxiliar.
Primeiro efeitorecv message / enc+url_text+url_number+reporting.

Mini pipeline

MarcoOrigemContrato
externocenárioDispositivo auxiliar de teste envia a mensagem.
200 / 425pipelinePrimeiro efeito observável no WebSocket.

Mensagem recebida

observadostanza 200 · seq 425

Leitura

A conta em teste recebe uma stanza message cifrada. Ela traz o envelope enc e filhos estruturais como url_text, url_number e reporting. O conteúdo real não é publicado.

Attrsfrom, id, notify, sender_pn, sts, t, type.
Filhosenc, url_text, url_number, reporting.

Mini pipeline

StanzaSeqContrato
200425recv message, conteúdo em filhos, enc em bytes.
201427sent receipt confirma recebimento.

A presença de url_text e url_number é estruturalmente relevante; valores ficam redigidos.

sender_pn é apenas o nome do atributo observado; o número real não é publicado.

Receipt de recebimento

observadostanza 201 · seq 427

Leitura

O cliente confirma para o servidor que recebeu a mensagem. Esse recibo é curto e não carrega o conteúdo da mensagem.

Stanzasent receipt, attrs [id,to].
DepoisO cliente continua com consultas de sincronização e identidade.

Mini pipeline

StanzaSeqContrato
201427sent receipt, sem filhos.
202-203429-431sent iq vazio e resposta recv iq vazia.

Sync pós-recebimento

observadorótulo inferidostanzas 202-211

Leitura

O protocolo não emite um “fim” explícito aqui. Chamamos de sync pós-recebimento a sequência final de iq, usync, identity, receipt, ack e list antes do encerramento do navegador.

Esse comportamento conversa com o sync de app-state: mesmo depois de uma mensagem recebida, a sessão ainda ajusta identidade, lista e estado local.

IQ curtoStanzas 202-203: ida e volta vazia antes do usync final.
UsyncStanzas 204-207: duas consultas e duas respostas.
Identity/listStanzas 208 e 211 trabalham identidade e lista com 203 usuários estruturais.

Mini pipeline

StanzaSeqContrato
202-203429-431sent iq vazio e resposta recv iq vazia.
204-207433-439usync enviado/recebido.
208441sent iq / identity, 203 filhos user.
209-211443-447receipt, ack, recv iq / list.
-449chromium_closed encerra a captura.