Vouch - Open-Source-System zur Vertrauensverwaltung für Contributoren

• Open Source funktionierte traditionell auf dem Modell trust and verify
• Durch die Verbreitung von AI-Tools sind die Eintrittsbarrieren für Beiträge faktisch verschwunden, sodass das bisherige implizite Vertrauensmodell nicht mehr funktioniert
• Ein Open-Source-System zur Vertrauensverwaltung, das so konzipiert ist, dass eine Teilnahme nur möglich ist, wenn vor dem Beitrag explizit Vertrauen zugesichert (vouch) wird
• Vertrauenswürdige Contributoren können andere Nutzer vouchen, und böswillige Akteure können mit denounce explizit blockiert werden
  • denounce bleibt als öffentlicher Eintrag erhalten, sodass andere Projekte dies als Referenz nutzen können
  • Wer wen und nach welchen Kriterien voucht oder denouncet, entscheidet jedes Projekt selbst
  • Das System erzwingt keine bestimmte Wertehaltung; politische Entscheidungen liegen bei der Community
• Alle Vertrauensdaten werden in der Ablage als eine einzelne Klartextdatei (VOUCHED) zusammen mit dem Code versionsverwaltet, was Transparenz und Portabilität sicherstellt
• Langfristig ist eine Struktur geplant, in der Vertrauensinformationen projektübergreifend über ein Vertrauensnetz (Web of Trust) geteilt werden
  • Ob Entscheidungen übergeordneter Projekte unverändert übernommen werden, entscheidet jedes untergeordnete Projekt selbst
  • Projekte, die leichtfertig vouchen oder denouncen, können auf natürliche Weise aus dem Vertrauensnetz ausgeschlossen werden
• Lässt sich mit GitHub Actions einfach integrieren und kann über Keywords wie lgtm oder denounce in Issue- oder PR-Kommentaren verwaltet werden
• Ghostty hat sein Beitragsmodell auf ein vouch-basiertes System umgestellt
• Inspiriert vom Projekt Pi implementiert und derzeit noch in einer experimentellen Phase

Verfügbare Befehle

• Lokale Datei
  • vouch.nu check <user>: Prüft den vouch-/denounce-Status eines Nutzers
  • vouch.nu add <user>: Nutzer vouchen
  • vouch.nu denounce <user>: Nutzer denouncen
• GitHub-Integration
  • vouch.nu gh-check-pr <pr>: Status des PR-Autors prüfen und automatisch verarbeiten
  • vouch.nu gh-manage-by-issue <issue> <comment>: vouch/denounce auf Basis von Issue-Kommentaren

[kuthia]

Ich denke, das System selbst muss erst Autorität gewinnen, damit es akzeptiert wird.

[xguru]

Es scheint, als gäbe es wegen der Aufmerksamkeit einige Missverständnisse, deshalb wurde ein separates FAQ zusammengestellt.
https://x.com/mitchellh/status/2020628046009831542

• Für Anfänger und neue Mitwirkende ist die Teilnahme schwierig
  • Es gibt überhaupt keinen Grund, warum es schwierig sein sollte, ein Vouch zu bekommen
  • Der Hauptzweck von Vouch ist es, eine gedankenlose Teilnahme ohne eigenen Einsatz zu verhindern
  • In meinen Projekten (einschließlich dieses Projekts) kann man ein Vouch erhalten, wenn man sich in einem Issue kurz vorstellt und knapp erklärt, wie man beitragen möchte
  • Kurz gesagt: Wenn man sich wie im normalen sozialen Miteinander kurz vorstellt, kann man ein Vouch bekommen
  • Wer jedoch seine Rechte innerhalb der Gruppe missbraucht, wird sanktioniert
• Anfällig für Social Engineering
  • Nutzer mit einem Vouch erhalten nur die Berechtigung, am Projekt teilzunehmen
  • Sie erhalten keine Rechte zum Mergen von Pull Requests, zum Pushen von Code oder für Releases
  • All diese Aktionen bleiben durch bestehende Reviews und Systemkontrollen eingeschränkt
  • Außerdem können nur Administratoren/Mitwirkende Nutzer empfehlen
  • Deshalb kann ein problematischer Nutzer, selbst wenn er empfohlen wurde, keine anderen Nutzer empfehlen
• Es gibt kein Einspruchsverfahren für Denouncing.
  • Das Einspruchsverfahren unterscheidet sich je nach Unterprojekt
  • In meinen Projekten gilt: Wenn ihr uns über Discord, E-Mail oder irgendeinen anderen Weg kontaktiert, wie Menschen mit uns sprecht und euren Fehler einräumt, geben wir euch erneut eine Chance. Das ist nicht schwierig
• Der Kern dieses Projekts ist, dass AI Menschen über API-Aufrufe Informationen bereitstellt und dadurch bestehende natürliche Hürden minimiert
• In einem menschenzentrierten Community-Projekt ist menschliche Interaktion nur an den Grenzen erforderlich

[GN⁺]

Hacker-News-Kommentare

• Ich halte es für riskant anzunehmen, dass ein vertrauenswürdiger Nutzer in einem Projekt automatisch auch in anderen Projekten als vertrauenswürdig gilt
  So eine Struktur könnte für Supply-Chain-Angriffe missbraucht werden. Ein Angreifer könnte sich in mehreren Projekten als „guter Contributor“ Vertrauen aufbauen und sich dann Zugang zum Zielprojekt verschaffen
  Wenn dieses projektübergreifende Vertrauen automatisiert wird, kann jedes einmal vertrauenswürdige Konto zum Angriffsziel werden. Sicherer wäre es meiner Meinung nach, eher mit einer „Misstrauensliste“ als mit einer „Vertrauenskiste“ zu beginnen

  • Der Beschreibung nach scheint der Zweck dieses Systems weniger Vertrauen im sicherheitstechnischen Sinn zu sein als vielmehr ein Spam-Filter, der minderwertige AI-generierte Beiträge aussortiert
  • Diese Sorge ist etwas übertrieben. Vouch ist nur ein Gate, das die Teilnahme einschränkt, es vergibt keine Rechte zum Mergen von Code. Danach bleibt der bestehende Review-Prozess unverändert. Im Grunde ist es eher eine Schicht zur Rauschminimierung
  • Dass Angreifer sich über längere Zeit einen guten Ruf aufbauen, indem sie harmlos wirken, passiert auch in der Realität bereits. Irgendwann merken die Leute dann, dass sich die Person verändert hat. Das ist eine Situation wie in xkcd 810
  • Wenn jemand Vertrauen verliert, verschwindet dieses Vertrauen auch in allen Projekten, die ihm vertraut haben. Das ist eher ein Konzept wie ein Spam-Filter, nicht Vertrauen auf dem Niveau von PGP-Key-Signaturen. Es soll keine staatlichen Angreifer aufhalten, sondern AI-Spam-PRs abwehren
  • Es ist kein perfektes System, aber ich halte es für eine „Verbesserung, die den Aufwand wert ist“. Für echte Contributor ist ein bisschen zusätzlicher Aufwand vertretbar. Ich wäre jedenfalls bereit, das in Kauf zu nehmen

• Ich finde die Idee gut, für das Einreichen eines PRs 1 $ Gebühr zu verlangen
  Wenn der PR valide ist, erstattet der Maintainer das Geld zurück
  Kommunikation ist inzwischen viel zu einfach geworden, deshalb gibt es massenhaft minderwertige Kommunikation. Das ist nicht nur wertlos, sondern ein zeitfressender Schaden

  • Diese Denkweise führt am Ende zum Staking-Konzept aus der Krypto-Welt. Man sperrt Token, und wenn der PR gemergt wird, bekommt man sie zurück. Technisch elegant, aber sobald Geld hineinkommt, verdirbt es das Produktdesign. Das sollte man auf keinen Fall tun
  • „Wenn du meinen Kommentar lesen willst, zahl 1 $“ ist als Witz gemeint, bringt aber den Kern der Idee gut auf den Punkt
  • Kommunikation mit Kosten zu belegen hat auch negative Effekte. Wichtig ist das richtige Gleichgewicht bei der angemessenen Gebühr. Minderwertige Gespräche mit nahestehenden Menschen sind okay, aber die Twitter-Kommunikation von Politikern dürfte gern weniger werden
  • Im Kern ist das ein Problem der Externalisierung von Kosten. Das passiert in der Fertigung, in der Kommunikation, bei der Code-Generierung und überall sonst. Inzwischen kostet sogar persönliche Reputation fast nichts mehr
  • In so einer Struktur würde ich wahrscheinlich überhaupt keine PRs mehr einreichen. Schon jetzt bleiben viele PRs unbeantwortet; wenn ich dafür auch noch zahlen müsste, würde ich lieber einfach im Fork Änderungen machen. Wenn es keinen Anreiz zur Rückerstattung gibt, ist das erst recht unfair. Selbst mit einem Escrow-Service würde es nur komplizierter. Ich will einfach nur einen Bug beheben und mag solche Verfahren nicht

• Ich frage mich, wie neue Contributor ohne Netzwerk diese Eintrittshürde überwinden sollen
  Auch wenn es viel von AI erzeugtes Rauschen gibt, ist das nicht die Lösung

  • In meinen OSS-Projekten bevorzuge ich, dass Vorschläge zuerst über Issues oder Diskussionen eingebracht werden statt direkt per PR. PRs passen oft nicht zur Ausrichtung des Projekts und bringen einen dann in die unangenehme Lage, sie ablehnen zu müssen
  • Man kann Contributor auch den Patch in einem Videoanruf erklären lassen. Ich habe auf diese Weise tatsächlich schon betrügerische Bewerber herausgefiltert. FOSS ist inzwischen fast zu einem Spiel der Betrugserkennung geworden
  • Das wirkt wie eine Struktur mit stufenweise eingeschränktem Zugang. Man könnte zum Beispiel erst in einer Staging-Umgebung validieren und danach Zugriff auf Production erlauben. In der Ops-Welt ist das längst üblich
  • Das hängt von der Vouch-Konfiguration ab. Manche können völlig geschlossen sein, andere lassen Issues und Diskussionen offen und beschränken nur PRs. Man kann das wie unter Linux an die Praxis jedes Projekts anpassen

• Ich stimme der Aussage nicht zu, dass „Open Source auf einem System aus Vertrauen und Verifikation basiert“
  Im Idealfall sollte man den Code selbst beurteilen können
  Wenn ich mir einen PR ansehe, entscheide ich innerhalb weniger Sekunden, ob ich ihn merge oder nicht. Der schwierige Teil ist, die Ablehnungsbegründung höflich zu formulieren
  (Siehe: openpilot-Repository)

  • Ich habe mir den openpilot-Code vor Kurzem angesehen; die Struktur mit msgq/cereal, Params, visionipc ist interessant
  • Wenn Zeit da ist, wird reviewed, und wenn keine Zeit da ist, läuft es eben über Vertrauen

• Ich frage mich, wie das Vouch-Projekt verhindert, zu einer abgeschotteten Blase wie Bluesky zu werden
  Bluesky schrumpft seit der Wahl immer weiter. Solches soziales Filtern könnte neue Beiträge blockieren

  • Dass es nach der Wahl zurückgegangen ist, stimmt, aber die Nutzerzahl liegt immer noch über der von davor. Die Statistiken zeigen ein Muster aus Spike und anschließender Stabilisierung
    Außerdem ist das Ziel von Vouch von vornherein, die Eintrittshürde zu erhöhen, daher dürfte man sich um dieses Problem wohl kaum sorgen
  • Jedes Projekt kann ein eigenes Vouch-System haben. Die Community kann über Issues oder PRs auch Einwände vorbringen
  • Es gibt auch die Sichtweise: „Was, wenn eine Blase wie Bluesky entsteht?“ → „Vielleicht ist genau das beabsichtigt“
  • Interessant ist, dass auf Bluesky der am häufigsten geblockte Account ein offizieller Regierungsaccount ist. Das zeigt eine Seite geschlossener Communities

• Spöttischer Kommentar, dass so ein System in einer dramafreien Open-Source-Community natürlich ganz sicher niemals missbraucht werden würde
  Ob wohl schon irgendwo eine Blacklist von Entwicklern geteilt wurde

• Ich denke, ein vertrauensbasiertes System funktioniert nur dann, wenn es zwingend mit Risiken verbunden ist
  Wenn ich für jemanden bürge und diese Person Probleme verursacht, sollte auch meine Reputation sinken
  Umgekehrt sollte meine Reputation leiden, wenn ich jemanden grundlos beschuldige und sich diese Person als in Ordnung herausstellt
  Andernfalls wird Bürgschaft verantwortungslos missbraucht werden

  • Genau deshalb muss man vorsichtig sein. Aber wenn ich für jemanden bürge und dabei etwas Gutes herauskommt, könnte auch meine Reputation steigen. So funktionieren menschliche Beziehungen ebenfalls
    So eine Struktur ließe sich vielleicht als blockchainbasierter Trust-Graph umsetzen
  • So wie man in Unternehmen Referenzen angibt, bürgt man eben, weil man auch selbst profitiert, wenn man zusammenarbeitet
  • Wenn die Person, für die ich gebürgt habe, gute Beiträge liefert und dadurch auch mein Score steigt, wäre das ein guter Anreiz
  • Allerdings birgt so ein System das Risiko, wie bei Fällen wie Epstein wegen vieler Verbindungen den falschen Leuten einen Freifahrtschein zu geben. Umgekehrt könnten introvertierte, aber kompetente Menschen ausgeschlossen werden
  • Solche Vertrauensnetze kann man als Graphdurchsuchungsproblem betrachten. Über die Beziehungen von Menschen, denen ich vertraue, zu Menschen, denen diese vertrauen, lässt sich indirektes Vertrauen berechnen

• Das System erinnert mich an Dating-Apps
  Es gibt viele übereifrige, aber ungeeignete Kandidaten, die herausgefiltert werden müssen, und am Ende entstehen wohl Muster wie bezahlte Teilnahme, Standortbezug, Identitätsprüfung und soziale Bepunktung
  In letzter Zeit ist es ermüdend, dass Leute auf GitHub um jeden Preis Reputation aufbauen wollen und deshalb sinnlose Beitragsanfragen spammen

• Ich stelle mir eine minimale Forge-Struktur vor, die nur das ergänzt, was Git von Haus aus nicht kann
  Die Kernelemente wären Identity, Attestation und Policy
  Vouch behandelt davon die Signaturen über Personen — eine Signatur wie „Diese Person ist vertrauenswürdig“ ist strukturell dasselbe wie eine Signatur wie „Dieser Commit hat die Tests bestanden“
  Es ist also eine Policy-Schicht, die schon die Teilnahme selbst steuert
  So etwas sollte nicht auf einer geschlossenen Plattform wie GitHub liegen, sondern als Metadaten im Repository selbst existieren
  Ich bin gespannt, wie weit sich dieses Konzept in fünf Jahren entwickelt haben wird

  • Wenn man solche Metadaten in standardisierter Form wie in einem .github/-Ordner speichert, wird ein plattformunabhängiges Vertrauensmodell möglich
    In einer Zeit, in der immer mehr Code von LLMs erzeugt wird, könnte so eine Reputationsinfrastruktur zu einem unverzichtbaren Bestandteil des Internets werden

• Am Anfang klang es gut, aber letztlich läuft es wohl auf eine Struktur hinaus, in der nur vertrauenswürdige Personen beitragen können

  • Weniger Innovation als vielmehr gut gestaltete Umsetzungskraft ist hier der entscheidende Punkt
  • Das erinnert an killfiles aus dem alten Usenet oder an Spam-RBL-Listen
    (killfile-Wiki, DNS-Blocklist)
  • Für große Projekte ist so eine Struktur besser geeignet. Minderwertige PRs werden standardmäßig blockiert, und Zugriff bekommen nur Menschen, die Vertrauen bei den zentralen Maintainern aufgebaut haben