Vouch - sistema de gestión de confianza para contribuidores de código abierto

• El código abierto ha funcionado tradicionalmente sobre un modelo de trust and verify
• Con la expansión de las herramientas de IA, la barrera de entrada para contribuir prácticamente desapareció, y el modelo implícito de confianza existente ya no funciona
• Un sistema de gestión de confianza para código abierto diseñado para que solo se pueda participar si la confianza se avala explícitamente (vouch) antes de contribuir
• Los contribuidores de confianza pueden hacer vouch por otros usuarios, y los actores maliciosos pueden ser bloqueados explícitamente con denounce
  • denounce se mantiene como un registro público para que otros proyectos puedan consultarlo
  • Cada proyecto decide de forma autónoma quién puede hacer vouch/denounce y con qué criterios
  • El sistema no impone una visión de valores específica; las decisiones de política quedan en manos de la comunidad
• Todos los datos de confianza se gestionan por versiones junto con el código dentro del repositorio en un solo archivo de texto plano (VOUCHED), garantizando transparencia y portabilidad
• A largo plazo, la idea es compartir información de confianza entre proyectos mediante una red de confianza (Web of Trust)
  • Los proyectos descendientes eligen si aceptan o no tal cual los criterios de un proyecto superior
  • Los proyectos que hagan vouch/denounce de forma irresponsable pueden quedar excluidos naturalmente de la red de confianza
• Puede integrarse fácilmente con GitHub Actions y administrarse desde comentarios en issues o PR con palabras clave como lgtm y denounce
• Ghostty cambió su modelo de contribución a un sistema basado en vouch
• Implementado con inspiración en el proyecto Pi, y actualmente se encuentra en etapa experimental

Comandos disponibles

• Archivo local
  • vouch.nu check <user>: comprobar el estado de vouch/denounce de un usuario
  • vouch.nu add <user>: hacer vouch por un usuario
  • vouch.nu denounce <user>: hacer denounce de un usuario
• Integración con GitHub
  • vouch.nu gh-check-pr <pr>: comprobar el estado del autor del PR y procesarlo automáticamente
  • vouch.nu gh-manage-by-issue <issue> <comment>: hacer vouch/denounce a partir de comentarios en issues

[kuthia]

Creo que el propio sistema tendría que ganarse autoridad para que sea aceptado.

[xguru]

Parece que, como está recibiendo atención, hubo algunos malentendidos, así que organizaron un FAQ por separado
https://x.com/mitchellh/status/2020628046009831542

• Es difícil participar para principiantes y nuevos colaboradores
  • No hay ninguna razón para que sea difícil recibir un Vouch
  • El objetivo principal de Vouch es impedir la participación irreflexiva y sin esfuerzo
  • En mis proyectos (incluido este), puedes recibir un Vouch si te presentas en un issue y explicas brevemente cómo te gustaría contribuir
  • En pocas palabras, si te presentas como en una interacción social normal, puedes recibir un Vouch
  • Pero si abusas de tus privilegios dentro del grupo, serás sancionado
• Es vulnerable a la ingeniería social
  • Los usuarios que reciben un Vouch solo obtienen permiso para participar en el proyecto
  • No obtienen permisos para fusionar pull requests, hacer push de código ni publicar releases
  • Todas esas acciones siguen estando restringidas mediante la revisión existente y los controles del sistema
  • Además, solo los administradores y colaboradores pueden recomendar usuarios
  • Por lo tanto, aunque un usuario problemático haya sido recomendado, no podrá recomendar a otros usuarios
• No existe un proceso de apelación para el denouncing.
  • El proceso de apelación varía según el subproyecto
  • En el caso de mis proyectos, si se comunican con nosotros por Discord, correo electrónico o cualquier otro medio, hablan con nosotros como personas y reconocen su error, les daremos otra oportunidad. No es difícil
• La esencia de este proyecto es que la IA minimice las barreras naturales existentes al proporcionar información a las personas mediante llamadas a la API
• En los proyectos comunitarios centrados en las personas, la interacción humana solo es necesaria en los bordes

[GN⁺]

Comentarios en Hacker News

• Me parece riesgoso asumir que un usuario de confianza en un proyecto quede automáticamente como confiable en otros proyectos.
  Una estructura así puede explotarse para ataques a la cadena de suministro. Un atacante podría ganarse la confianza como “buen contribuidor” en varios proyectos y luego acercarse al proyecto objetivo.
  Si esa confianza cruzada se automatiza, cualquier cuenta que haya sido confiable хотя sea una vez puede convertirse en objetivo de ataque. Me parece más seguro empezar con una lista de desconfianza que con una “lista de confianza”.

  • Por la descripción, parece que el objetivo de este sistema no es tanto la confianza en sentido de seguridad, sino más bien un filtro de spam para bloquear contribuciones de baja calidad generadas por IA
  • Esa preocupación tiene algo de exageración. Vouch solo es una puerta que restringe la participación, no otorga permisos para fusionar código. Después de eso, el proceso normal de revisión sigue igual. Al final, puede verse como una capa para minimizar ruido
  • Que un atacante finja ser buena persona durante mucho tiempo para construir reputación ya pasa en la vida real. Al final, la gente se da cuenta cuando cambia. Es una situación como xkcd 810
  • Si alguien pierde la confianza, esa confianza desaparece también en todos los proyectos que confiaban en esa persona. Esto se parece más a un filtro de spam que a un nivel de confianza tipo firma de clave PGP. No busca detener a atacantes estatales, sino frenar PRs de spam hechos con IA
  • No es un sistema perfecto, pero me parece una “mejora que vale la pena por la molestia”. Si eres un contribuidor real, vale la pena hacer un pequeño esfuerzo extra. Yo estaría dispuesto a asumirlo

• Creo que sería bueno imponer un costo de $1 por enviar un PR.
  Si el PR es válido, el mantenedor lo reembolsa.
  Ahora comunicarse es demasiado fácil, así que hay un exceso de comunicación de baja calidad. Esto no solo carece de valor, sino que es un perjuicio que te consume tiempo

  • Esa forma de pensar termina llevándote al concepto de staking del mundo cripto. Bloqueas un token y, si el PR se fusiona, te lo devuelven. Técnicamente puede verse elegante, pero cuando entra dinero, el diseño del producto se corrompe. Nunca debería hacerse así
  • “Si quieres leer mi comentario, págame $1” es una broma, pero muestra bien la esencia de la idea
  • Ponerle costo a la comunicación también tiene efectos negativos. Lo importante es el punto de equilibrio del costo adecuado. Las conversaciones “de baja calidad” con gente cercana están bien, pero ojalá hubiera menos interacción de políticos en Twitter
  • Al final esto es un problema de externalización de costos. Pasa en manufactura, comunicación, generación de código y en todos lados. Ahora incluso la reputación personal casi no tiene costo
  • Yo no mandaría PRs en una estructura así. Ya hay muchos PRs que no reciben respuesta; si además tengo que pagar, mejor lo arreglo en mi fork. Si no hay incentivo para reembolsar, es todavía más injusto. Incluso con un servicio de escrow se vuelve más complejo. Yo solo quiero arreglar un bug, no pasar por todo ese proceso

• Me pregunto cómo un contribuidor nuevo, sin red de contactos, podría romper la barrera de entrada.
  Aunque haya mucho ruido generado por IA, esto no me parece la solución

  • En mi proyecto OSS prefiero que primero propongan algo vía issue o discusión antes que por PR. Los PRs muchas veces no encajan con la dirección del proyecto y rechazarlos se vuelve incómodo
  • Otra opción es pedirle al contribuidor que explique el parche por videollamada. De hecho, ya he filtrado postulantes fraudulentos de esa manera. Hoy en día FOSS casi se volvió un juego de detección de fraude
  • Parece una estructura donde el acceso se restringe por etapas. Por ejemplo, primero validar en un entorno de staging y después permitir acceso a producción. Eso ya es común en el mundo de ops
  • Depende de cómo se configure Vouch. Algunos pueden cerrarlo por completo, y otros pueden dejar abiertos los issues y discusiones, limitando solo los PRs. Se puede abordar según las prácticas de cada proyecto, como Linux

• No estoy de acuerdo con la idea de que “el open source funciona sobre un sistema de confiar y verificar”.
  Idealmente, el código debería poder evaluarse por sí mismo.
  Cuando veo un PR, en pocos segundos decido si se fusiona o no. Lo difícil es redactar con cortesía la razón del rechazo.
  (Referencia: repositorio de openpilot)

  • Revisé hace poco el código de openpilot, y la estructura de msgq/cereal, Params, visionipc me pareció interesante
  • Cuando hay tiempo se revisa, y cuando no lo hay, se confía

• Me pregunto cómo evitarán que el proyecto Vouch se convierta en una burbuja cerrada como Bluesky.
  Bluesky se ha ido reduciendo poco a poco después de las elecciones. Este tipo de filtrado social también podría bloquear nuevas contribuciones

  • Sí hubo una baja después de las elecciones, pero aun así sigue teniendo más usuarios que antes. Si ves las estadísticas, el patrón es de pico seguido de estabilización.
    Además, el objetivo de Vouch desde el inicio es justamente elevar la barrera de entrada, así que probablemente no les preocupe ese problema
  • Cada proyecto podría tener su propio sistema de vouch independiente. La comunidad también podría expresar objeciones en issues o PRs
  • También está la visión de: “¿Y si se forma una burbuja como Bluesky?” → “Quizá esa sea precisamente la intención”
  • Es interesante que la cuenta más bloqueada en Bluesky sea una cuenta oficial del gobierno. Muestra una cara de las comunidades cerradas

• Se comenta con sarcasmo que un sistema así jamás dejaría espacio para abusos en una comunidad open source sin dramas.
  Se preguntan si acaso ya se compartió alguna lista negra de desarrolladores

• Creo que un sistema basado en confianza solo funciona si necesariamente conlleva riesgo.
  Si yo avalo a alguien y esa persona causa problemas, mi reputación también debería caer.
  Al contrario, si acuso a alguien sin fundamento y resulta ser una buena persona, mi reputación también debería verse afectada.
  Si no, los avales se usarán irresponsablemente y en exceso

  • Por eso hay que ser cuidadosos. Pero si avalo a alguien y el resultado es bueno, yo también podría ganar reputación. Las relaciones humanas también funcionan así.
    Una estructura así incluso podría implementarse como un grafo de confianza basado en blockchain
  • Igual que cuando en una empresa das una referencia, avalas a alguien porque si trabajas con esa persona, tú también obtienes beneficio
  • Si hubiera una estructura donde mi puntaje también sube cuando alguien a quien avalé hace una buena contribución, eso sí motivaría
  • Pero una estructura así también corre el riesgo de dar inmunidad a personas equivocadas solo porque tienen muchas conexiones, como en casos tipo Epstein. Y al mismo tiempo, podría excluir a personas competentes pero introvertidas
  • Esta red de confianza puede verse como un problema de recorrido de grafos. A través de la relación de personas confiables por gente en quien confío, se podría calcular un nivel de confianza indirecto

• Este sistema se siente parecido a una app de citas.
  Hay demasiados candidatos no aptos pero demasiado entusiastas que filtrar, y parece que al final surgirán patrones como participación pagada, ubicación, verificación de identidad y puntajes sociales.
  Últimamente cansa ver gente que quiere ganar prestigio en GitHub dejando solicitudes de contribución sin sentido

• Imagino una forja minimalista que solo conserve lo que Git por sí mismo no puede hacer.
  Lo central sería Identidad (Identity), atestaciones firmadas (Attestation) y política (Policy).
  Vouch, entre esas piezas, se ocupa de las firmas sobre personas: una firma de “esta persona es confiable” es estructuralmente igual a una firma de “este commit pasó las pruebas”.
  Es decir, es una capa de política que controla la participación misma.
  Este tipo de función debería existir como metadatos dentro del repo, no en una plataforma cerrada como GitHub.
  Me da curiosidad hasta dónde evolucionará esta idea en cinco años

  • Si estos metadatos se guardaran en una forma estandarizada, como la carpeta .github/, sería posible un modelo de confianza independiente de la plataforma.
    En una era donde el código generado por LLM va en aumento, esta infraestructura de reputación podría volverse un elemento esencial de internet

• Al principio parecía razonable, pero al final da la impresión de desembocar en una estructura donde solo puede contribuir gente de confianza

  • Aunque no sea innovador, tiene valor en que importa más la ejecución bien diseñada que la novedad
  • Se parece al killfile del antiguo Usenet o a las listas RBL de spam
    (wiki de killfile, DNS blocklist)
  • Este tipo de estructura encaja mejor en proyectos grandes. Bloquea por defecto los PRs de baja calidad y permite acceso solo a quienes han construido confianza con los mantenedores principales