phantomstars

Detecção e rastreamento automatizados de engajamento falso no GitHub

Um projeto do JS Labs — parte da iniciativa AI Slop Intelligence.
Executa todos os dias. Pontua todas as contas suspeitas. Detecta campanhas coordenadas de bots.
Abre issues diretamente em repositórios comprometidos para que mantenedores possam agir.

---

Apoie este projeto

BTC   3QjWqhQbHdHgWeYHTpmorP8Pe1wgDjJy54
ETH   0x5851e6145F4773d1585b8686095FB16E368a4dA1
ZEC   t1KSR5YkNPbjqRSCoLKo5AddFWdm9Kzxh1B

---

Por que isso existe

As estrelas do GitHub são um sinal de confiança. São como desenvolvedores decidem o que avaliar, do que depender e o que recomendar. Esse sinal está sendo sistematicamente corrompido.

Durante o boom de IA de 2024-2026, surgiu uma indústria de fazendas de bots para fabricar credibilidade para repositórios de baixa qualidade, muitas vezes maliciosos. Um projeto com 800 estrelas em 48 horas parece legítimo para um desenvolvedor examinando resultados de pesquisa. Esse é o ponto. O objetivo do engajamento falso não são as estrelas em si; é a prova social que essas estrelas produzem e as decisões a jusante que essa prova social influencia.

O padrão é identificável. Contas criadas na mesma semana, sem biografia, sem seguidores, sem repositórios originais, estrelando os mesmos 15 repositórios dentro de uma janela de 2 horas. Não uma campanha, mas dezenas executadas simultaneamente, todos os dias, em milhares de contas. Os dados mostram repositórios onde 185 de 185 engajadores são bots. Uma taxa de falsidade de 100%. Colocações inteiras de trending construídas sobre nada.

phantomstars foi criado porque esse problema é tratável. A relação sinal-ruído na API pública do GitHub ainda é, por enquanto, alta o suficiente para que campanhas coordenadas deixem impressões digitais claras. Este projeto lê essas impressões, publica os dados brutos e notifica os mantenedores dos repositórios afetados diretamente.

Isso faz parte do trabalho mais amplo do AI Slop Intelligence no JS Labs, uma pesquisa contínua sobre os mecanismos e efeitos mensuráveis do conteúdo de baixa qualidade gerado por IA inundando ecossistemas de desenvolvedores. Engajamento falso não é um problema periférico. É o mecanismo de distribuição que coloca o "slop" na frente de usuários reais.

---

O que ele faz

O phantomstars executa um job diário do GitHub Actions que:

1. Coleta a página do GitHub Trending em busca de repositórios ganhando estrelas hoje
2. Consulta a API de Pesquisa do GitHub por repositórios criados nos últimos 7 dias com atividade repentina de estrelas (a janela maior captura campanhas de vários dias perdidas por varreduras de apenas 24h)
3. Semeia repositórios candidatos adicionais a partir de postagens recentes no Reddit em r/osinttools e r/coolgithubprojects, extraindo links de repositórios GitHub dos últimos 2 dias
4. Obtém eventos recentes de engajamento (estrelas, forks) via API de Eventos (últimas 24 horas por repositório)
5. Busca o perfil completo de cada conta engajadora via GraphQL: data de criação da conta, contagens de seguidores/seguindo, biografia, histórico de repositórios
6. Pontua cada conta com um modelo heurístico composto: idade da conta, completude do perfil, padrões de repositório e histórico de atividade
7. Detecta campanhas coordenadas usando agrupamento de timestamps e union-find: clusters de contas suspeitas que engajaram dentro de uma janela de 3 horas
8. Aplica a lista de permissões de falsos positivos antes de escrever no ledger, proporções por repositório, dashboards e notificações, para que toda métrica visível use a mesma população
9. Adiciona todos os suspeitos a um ledger JSONL somente de acréscimo, commitado de volta a este repositório
10. Publica um feed de inteligência por repositório mostrando quais repositórios estão sendo alvo, quais fontes de descoberta os encontraram e se a janela da API de Eventos estava completa ou limitada
11. Abre issues do GitHub diretamente nos repositórios alvo para que mantenedores vejam os dados da campanha em seu próprio rastreador de issues
12. Escreve um relatório de varredura formatado no resumo do job do GitHub Actions

Sem servidores. Sem bancos de dados. Sem custo de infraestrutura.

---

Perguntas frequentes

Ele notifica o repositório alvo?

Sim. Quando a taxa de falsidade de um repositório excede 40% ou uma campanha coordenada é detectada, o phantomstars abre uma issue diretamente naquele repositório. A issue contém a tabela completa de suspeitos, associação à campanha, pontuações compostas e datas de criação das contas: tudo que um mantenedor precisa para investigar e reportar ao GitHub.

Se as issues estiverem desabilitadas no repositório alvo, a notificação é ignorada silenciosamente e registrada no log de varredura.

Posso solicitar uma verificação para um repositório específico?

Sim.

• Para uma verificação única normal, envie um repositório no formato proprietario/repo e execute uma varredura direcionada.
• Para uma solicitação de auditoria vitalícia, use o modo vitalício único. Ele é separado da varredura diária.

Por que a separação:

• O modelo de varredura normal foi projetado para engajamento público recente e baixo custo operacional.
• Uma auditoria vitalícia pode envolver dezenas de milhares de estrelas e milhares de forks em repositórios maiores.
• Isso é viável para uma investigação única, mas é muito caro e muito lento para o caminho padrão diário.
• Portanto, solicitações vitalícias são executadas apenas no modo único explícito com salvaguardas.

Posso relatar um falso positivo?

Sim. Se sua conta aparecer em data/suspects.jsonl e você acreditar que a classificação está incorreta, abra uma issue de falso positivo usando o template fornecido. Os relatos são revisados manualmente antes de qualquer adição à lista de permissões. A lista de permissões está armazenada em data/allowlist.txt; as contas listadas lá são excluídas de todas as varreduras futuras e do ledger de suspeitos.

O que é o ID da campanha?

Um ID de campanha (ex.: c-a3f9b2e1) é uma impressão digital hexadecimal determinística de 8 caracteres derivada do hash SHA-256 do conjunto ordenado de logins dos membros daquela campanha. O mesmo grupo de contas produzirá o mesmo ID de campanha em execuções de varredura independentes, permitindo rastreamento longitudinal. Não é um nome de repositório, um nome de usuário ou qualquer identificador externo.

Estabilidade: o ID é estável enquanto o conjunto de membros da campanha permanecer inalterado. Se bots forem adicionados ou suspensos entre varreduras, o ID muda porque a associação mudou. Isso é esperado e reflete a deriva real na composição da fazenda de bots.

Ele verifica as datas de criação das contas?