Vouch - sistema de gestão de confiança para contribuidores de código aberto

• O código aberto tradicionalmente tem operado sobre um modelo de trust and verify
• Com a disseminação de ferramentas de IA, a barreira de entrada para contribuir praticamente desapareceu, e o antigo modelo implícito de confiança já não funciona mais
• Um sistema de gestão de confiança para código aberto projetado para permitir participação somente após uma garantia explícita de confiança (vouch) antes da contribuição
• Contribuidores confiáveis podem dar vouch a outros usuários, e agentes maliciosos podem ser bloqueados explicitamente com denounce
  • denounce é mantido como registro público, permitindo que outros projetos o usem como referência
  • Quem pode dar vouch/denounce, e com quais critérios, é uma decisão autônoma de cada projeto
  • O sistema não impõe valores específicos, e as decisões de política cabem à comunidade
• Todos os dados de confiança são versionados junto com o código em um único arquivo de texto simples (VOUCHED) dentro do repositório, garantindo transparência e portabilidade
• No longo prazo, a estrutura pretende compartilhar informações de confiança por meio da formação de uma rede de confiança (Web of Trust) entre projetos
  • Cabe aos projetos dependentes decidir se aceitam ou não integralmente os julgamentos de projetos superiores
  • Projetos que fazem vouch/denounce de forma indiscriminada podem ser naturalmente excluídos da rede de confiança
• Pode ser integrado facilmente com GitHub Actions e gerenciado em comentários de issues ou PRs com palavras-chave como lgtm e denounce
• O Ghostty migrou seu modelo de contribuição para um sistema baseado em vouch
• Implementado com inspiração no projeto Pi, e no momento está em fase experimental

Comandos disponíveis

• Arquivo local
  • vouch.nu check <user>: verifica o estado de vouch/denounce do usuário
  • vouch.nu add <user>: dá vouch ao usuário
  • vouch.nu denounce <user>: faz denounce do usuário
• Integração com GitHub
  • vouch.nu gh-check-pr <pr>: verifica o estado do autor do PR e processa automaticamente
  • vouch.nu gh-manage-by-issue <issue> <comment>: faz vouch/denounce com base em comentários de issue

[kuthia]

Parece que o próprio sistema precisa conquistar autoridade para ser aceito.

[xguru]

Parece que o assunto gerou interesse, mas também alguns mal-entendidos, então ele organizou um FAQ separado.
https://x.com/mitchellh/status/2020628046009831542

• Iniciantes e novos participantes têm dificuldade para participar
  • Não há absolutamente nenhum motivo para ser difícil receber um Vouch
  • O principal objetivo do Vouch é impedir participação aleatória e sem esforço
  • Nos meus projetos (incluindo este), basta se apresentar na issue e explicar brevemente como gostaria de contribuir para poder receber um Vouch
  • Em resumo, como na vida social comum, se você se apresentar, pode receber um Vouch
  • Mas, se abusar das permissões dentro do grupo, estará sujeito a sanções
• É vulnerável a engenharia social
  • Usuários que recebem um Vouch apenas obtêm permissão para participar do projeto
  • Eles não recebem permissões para mesclar pull requests, fazer push de código ou realizar releases
  • Todas essas ações continuam restritas pelos processos de revisão existentes e pelos controles do sistema
  • Além disso, apenas administradores/colaboradores podem recomendar usuários
  • Portanto, mesmo que um usuário problemático receba uma recomendação, ele não poderá recomendar outros usuários
• Não há procedimento de recurso para denúncias.
  • O processo de recurso varia conforme o subprojeto
  • No caso dos meus projetos, se você entrar em contato conosco por Discord, e-mail ou qualquer outro meio, conversar como uma pessoa e reconhecer o erro, damos outra chance. Não é difícil
• O ponto central deste projeto é que a IA fornece informações às pessoas por meio de chamadas de API, minimizando as barreiras naturais já existentes
• Em projetos comunitários centrados em humanos, a interação humana só é necessária nos pontos de fronteira

[GN⁺]

Comentários do Hacker News

• Acho arriscado presumir que um usuário confiável em um projeto será automaticamente confiável em outros projetos
  Esse tipo de estrutura pode ser explorado em ataques à cadeia de suprimentos. Isso porque um atacante pode construir confiança como um “bom contribuidor” em vários projetos e depois se aproximar do projeto-alvo
  Se essa confiança cruzada for automatizada, qualquer conta que tenha sido confiável ao menos uma vez pode virar alvo de ataque. Em vez de começar com uma “lista de confiança”, parece mais seguro começar com uma “lista de desconfiança”

  • Pela descrição, o objetivo desse sistema parece ser menos confiança no sentido de segurança e mais um filtro de spam para barrar contribuições ruins geradas por IA
  • Essa preocupação é um pouco exagerada. O Vouch é só um gate que restringe a permissão de participação, não concede permissão para fazer merge de código. Depois disso, o processo normal de revisão continua igual. No fim, dá para ver isso como uma camada de minimização de ruído
  • Atacantes fingirem ser bons por muito tempo para acumular reputação já é algo que acontece no mundo real. No fim, as pessoas percebem quando ele mudou. É uma situação tipo xkcd 810
  • Se alguém perde a confiança, ela desaparece também em todos os projetos que confiavam nessa pessoa. Isso é mais um conceito de filtro de spam do que um nível de confiança como assinatura de chave PGP. Não é para deter atacantes de nível estatal, e sim para bloquear PRs de spam gerados por IA
  • Não é um sistema perfeito, mas acho que é uma “melhoria que vale o incômodo”. Se for um contribuidor de verdade, vale a pena fazer um pequeno esforço extra. Eu mesmo toparia isso

• Acho que seria bom cobrar um custo de US$ 1 para enviar um PR.
  Se o PR for válido, o mantenedor devolve o valor.
  Hoje em dia comunicar ficou fácil demais, então estamos inundados por comunicação de baixa qualidade. Isso não é apenas algo sem valor, é um mal que consome tempo

  • Esse tipo de pensamento acaba levando ao conceito de staking do mundo cripto. Você trava tokens e, se o PR for merged, recebe de volta. Tecnicamente é elegante, mas quando dinheiro entra, o design do produto se corrompe. Isso jamais deveria ser feito
  • “Se quiser ler meu comentário, pague US$ 1” é uma piada, mas mostra bem a essência da ideia
  • Cobrar pela comunicação também tem efeitos negativos. O importante é o ponto de equilíbrio do custo adequado. Conversa “de baixa qualidade” com pessoas próximas tudo bem, mas eu gostaria que diminuísse a comunicação de políticos no Twitter
  • No fim isso é uma questão de externalização de custos. Acontece em manufatura, comunicação, geração de código e em todo tipo de área. Agora até reputação pessoal quase não tem custo algum
  • Numa estrutura dessas, acho que eu simplesmente não enviaria PR. Já há muitos PRs sem resposta; se eu ainda tiver que pagar, então simplesmente corrigiria no fork. Se não houver incentivo para reembolso, fica ainda mais injusto. Mesmo que exista um serviço de escrow, tudo fica mais complexo. Eu só quero corrigir um bug, não gosto desse tipo de processo

• Fico me perguntando como um novo contribuidor sem rede de contatos conseguiria romper a barreira de entrada.
  Mesmo que haja muito ruído gerado por IA, essa não é a solução

  • Nos meus projetos OSS, prefiro que a proposta venha primeiro por issue ou discussão, em vez de PR. PRs muitas vezes criam uma situação desconfortável, em que fica difícil rejeitar algo que não combina com a direção do projeto
  • Também existe a possibilidade de pedir para o contribuidor explicar o patch em uma chamada de vídeo. Já filtrei candidatos fraudulentos dessa forma. Hoje em dia o FOSS quase virou um jogo de detecção de fraude
  • Parece uma estrutura em que o acesso é restringido por etapas. Por exemplo, validar primeiro em um ambiente de staging e depois permitir acesso à produção. Isso já é comum no mundo de ops
  • Depende da configuração do Vouch. Alguns podem fechar tudo completamente, outros podem deixar issues e discussões abertas e restringir apenas PRs. Dá para adaptar às práticas de cada projeto, como no Linux

• Não concordo com a frase “open source funciona sobre um sistema de confiar e verificar”.
  Idealmente, o próprio código deveria poder ser avaliado por si só.
  Quando vejo um PR, decido em poucos segundos se vou fazer merge ou não. O difícil é escrever de forma educada o motivo da rejeição.
  (Referência: repositório openpilot)

  • Dei uma olhada no código do openpilot recentemente e a estrutura de msgq/cereal, Params, visionipc é interessante
  • Quando há tempo, reviso; quando não há, funciona na base da confiança

• Fico curioso sobre como o projeto Vouch pretende evitar virar uma bolha fechada, como o Bluesky.
  O Bluesky vem encolhendo desde a eleição. Esse tipo de filtragem social também pode bloquear novas contribuições

  • É verdade que caiu depois da eleição, mas ainda tem mais usuários do que antes. Pelas estatísticas, o padrão foi de pico seguido de estabilização.
    Além disso, como o objetivo do Vouch desde o início é elevar a barreira de entrada, provavelmente isso nem seria visto como problema
  • Cada projeto pode ter seu próprio sistema de vouch independente. A comunidade também pode apresentar objeções por meio de issues ou PRs
  • Também existe a visão de “e se surgir uma bolha tipo Bluesky?” → “talvez essa seja exatamente a intenção”
  • É interessante que a conta mais bloqueada no Bluesky seja uma conta oficial do governo. Isso mostra um lado de comunidades fechadas

• Um comentário sarcástico: claro que um sistema desses jamais seria abusado em uma comunidade open source sem dramas.
  Fico me perguntando se por acaso já compartilharam uma lista negra de desenvolvedores

• Acho que um sistema baseado em confiança só funciona de verdade se envolver risco.
  Se eu garantir alguém e essa pessoa causar problemas, minha reputação também deveria cair.
  Por outro lado, se eu acusar alguém sem fundamento e essa pessoa for ok, minha reputação também deveria ser reduzida.
  Caso contrário, o aval será usado de forma irresponsável e abusiva

  • Por isso é preciso cautela. Mas, se eu avalio alguém e isso gera um bom resultado, eu também poderia ganhar reputação. Relações humanas funcionam assim.
    Talvez uma estrutura dessas pudesse ser implementada como um grafo de confiança baseado em blockchain
  • Assim como indicar alguém em uma empresa, você dá aval porque se trabalharem juntos eu também ganho algo
  • Se a pessoa que eu avaliei fizer uma boa contribuição e minha pontuação também subir, isso parece um bom incentivo
  • Mas uma estrutura assim corre o risco de dar passe livre para a pessoa errada só porque ela tem muitas conexões, como em casos como o de Epstein. Por outro lado, pessoas competentes mais introvertidas podem acabar excluídas
  • Essa rede de confiança pode ser vista como um problema de travessia de grafo. Dá para calcular confiança indireta por meio das relações entre pessoas em que eu confio e pessoas em quem elas confiam

• Esse sistema lembra um app de namoro.
  Há muitos candidatos desqualificados excessivamente motivados que precisam ser filtrados, e parece que no fim vão surgir padrões como participação paga, baseada em localização, verificação de identidade e pontuação social.
  Hoje em dia é cansativo ver gente tentando ganhar fama no GitHub com pedidos de contribuição sem sentido

• Imaginei uma estrutura mínima de forge que deixasse só o que o Git não consegue fazer por padrão.
  O núcleo seriam identidade (Identity), atestados assinados (Attestation) e política (Policy).
  O Vouch lida, entre essas coisas, com assinaturas sobre pessoas — uma assinatura dizendo “essa pessoa é confiável” tem estruturalmente o mesmo formato que uma assinatura dizendo “este commit passou nos testes”.
  Ou seja, é uma camada de política para controlar a própria participação.
  Esse tipo de funcionalidade deveria existir como metadados dentro do repositório, não em uma plataforma fechada como o GitHub.
  Fico curioso para ver até onde essa ideia vai evoluir nos próximos 5 anos

  • Se esses metadados forem armazenados em um formato padronizado, como uma pasta .github/, seria possível um modelo de confiança independente de plataforma.
    Numa era em que o código gerado por LLM só aumenta, esse tipo de infraestrutura de reputação pode se tornar um elemento essencial da internet

• No começo parecia ok, mas no fim isso parece resultar em uma estrutura de “só pessoas confiáveis podem contribuir”

  • Mesmo sem ser inovador, há valor no fato de que o importante aqui é uma execução bem feita
  • É parecido com o antigo killfile do Usenet ou com listas RBL de spam
    (killfile wiki, DNS blocklist)
  • Para projetos grandes, uma estrutura assim parece mais adequada. Ela bloqueia por padrão PRs de baixa qualidade e só permite acesso a quem construiu confiança com os mantenedores principais