Filtragem de eventos

O cliente controla o tráfego de Dispatches através de assinaturas do Lazy Request e da lista ignored_events enviada no Identify. A disponibilidade dos servidores, permissões e o sharding também delimitam a entrega.

O Decoding Chat não possui campo intents, código de fechamento de intent nem aprovação de intents privilegiadas. Clientes portados de protocolos que usam intents substituem essa máscara pelos mecanismos descritos aqui.

As barreiras (gates)

O Decoding Chat avalia um Dispatch com escopo de servidor através destas barreiras em ordem:

Barreira	Nome	O que determina
1	Disponibilidade do servidor	Se o servidor envia qualquer evento além de Guild Update
2	Permissão e visibilidade	Quais sessões têm permissão para ver o evento
3	Estado da assinatura do servidor	Se uma sessão passiva em um servidor com mais de 250 membros recebe o evento, conforme Servidores ativos e passivos
4	Filtros em nível de sessão	Se o filtro de shard e, em seguida, a lista `ignored_events` descartam o evento dentro da sessão após os destinatários terem sido selecionados

Servidores com os recursos UNAVAILABLE_FOR_EVERYONE ou UNAVAILABLE_FOR_EVERYONE_BUT_STAFF são barrados na barreira 1. UNAVAILABLE_FOR_EVERYONE_BUT_STAFF determina o que a sessão recebe ao conectar (sessões da equipe recebem o estado completo e as demais recebem um stub unavailable). A barreira 1 não possui isenção para a equipe durante transmissões ao vivo.

Dispatches em nível de conta ignoram as barreiras 1 a 3 e são submetidos apenas à barreira 4 (ex.: mensagens diretas, alterações de amizades/relacionamentos e dados da conta).

Permissão e visibilidade

O servidor resolve cada evento para um destes conjuntos de destinatários:

Classe do evento	Eventos	Destinatários
Escopo de canal	Channel Create, Channel Update, Channel Delete¹, Message Create, Message Delete Bulk, Typing Start, Channel Pins Update, Webhooks Update	Sessões que podem visualizar o canal
Filtrado por acesso a mensagens	Message Update, Message Delete, Message Reaction Add, Message Reaction Remove, Message Reaction Remove All, Message Reaction Remove Emoji	Sessões que podem visualizar o canal e têm acesso àquela mensagem
Convite	Invite Create, Invite Delete	Sessões com `MANAGE_CHANNELS` no canal do convite
Registro de auditoria	Guild Audit Log Entry Create	Sessões com `VIEW_AUDIT_LOG` no servidor
Geral do servidor	Todos os demais	Todas as sessões conectadas ao servidor

¹ Channel Delete é filtrado contra o estado do servidor anterior à exclusão, garantindo que as sessões que viam o canal sejam notificadas de sua remoção

Todos esses conjuntos excluem sessões que ainda não tenham recebido o estado inicial do servidor.

Visibilidade de canal requer a permissão VIEW_CHANNEL no canal. Categorias ficam visíveis se ao menos um de seus canais filhos for visível. Usuários com conexão de voz ativa mantêm acesso virtual ao canal enquanto a chamada durar, mesmo se perderem VIEW_CHANNEL.

Acesso a mensagens requer READ_MESSAGE_HISTORY no canal. Sem essa permissão, sessões recebem eventos de mensagens apenas se forem mais recentes que o corte de histórico configurado no servidor.

Voice State Update segue caminho dedicado, sendo transmitido diretamente para sessões que visualizam o canal de voz envolvido.

Excluindo a sessão emissora

Message Reaction Add e Message Reaction Remove aceitam um session_id na requisição HTTP original. O Decoding Chat exclui essa sessão do Dispatch gerado. Todas as demais alterações entregam seus Dispatches normalmente para a própria sessão emissora.

Servidores ativos e passivos

Sessões de usuário iniciam no estado passivo em todos os servidores até que um Lazy Request marque o servidor com active: true. Sessões de bot nunca são passivas. Servidores com até 250 membros são sempre ativos para todas as sessões.

Portanto, uma sessão de usuário passiva em um servidor grande (> 250 membros) recebe exclusivamente:

Guild Update
Guild Delete
Guild Role Update e Guild Role Update Bulk
Channel Create, Channel Update, Channel Update Bulk e Channel Delete
Guild Audit Log Entry Create
Passive Updates
Message Create quando a mensagem mencionar o usuário da sessão
Guild Member Update e Guild Member Remove quando o alvo for o próprio usuário da sessão

Todos os outros Dispatches do servidor são suprimidos (edição/exclusão de mensagens, reações, convites, bans, novos membros, etc.).

A cada 30 segundos, sessões passivas recebem Passive Updates com os marcadores last_message_id dos canais que podem visualizar e estados de voz atualizados, mantendo contadores de mensagens não lidas corretos.

Digitação é tratada separadamente

Typing Start respeita o campo typing configurado no Lazy Request. Se não houver configuração explícita, segue o estado ativo/passivo do servidor.

Listas de membros

Guild Member List Update requer assinatura explícita via member_list_channels, além de permissões VIEW_CHANNEL e VIEW_CHANNEL_MEMBERS. Cada sessão retém no máximo uma assinatura de lista de membros por servidor.

Assinaturas de presença

Presence Update é entregue apenas para sessões que solicitaram explicitamente o usuário no array members de um Lazy Request e que compartilham canais visíveis com ele.

Bots não possuem amigos nem DMs em grupo com presenças automáticas, recebendo presenças exclusivamente por assinaturas em servidores.

Eventos ignorados

O Identify aceita o array ignored_events com até 256 nomes de eventos. Nomes são normalizados em maiúsculas e desduplicados. Dispatches listados são descartados e nunca entram no buffer de replay.

{
  "op": 2,
  "d": {
    "token": "...",
    "properties": {"os": "Linux", "browser": "bot", "device": "bot"},
    "ignored_events": ["TYPING_START", "PRESENCE_UPDATE"]
  }
}

Message Create é a única exceção: mesmo quando ignorado, ele é entregue se a mensagem mencionar diretamente o usuário da sessão, @here ou @everyone.

Dispatches suprimidos não consom números de sequência.

Filtro de Shard

Sessões identificadas com shard_id diferente de 0 descartam todos os Dispatches que não possuam vínculo com servidores. Notificações em nível de conta, DMs e chamadas chegam exclusivamente no shard 0.

Recomendações para Bots

Sessões de bot nunca são passivas e não precisam de Lazy Request para tráfego comum. O controle de volume é feito com ignored_events e paginação com Request Guild Members.

Bots que não tratam digitação ou reações economizam tráfego ignorando TYPING_START, MESSAGE_REACTION_ADD e MESSAGE_REACTION_REMOVE. Ignorar PRESENCE_UPDATE em bots é redundante, pois bots não recebem presenças até que as assinem explicitamente.