Mitchell HashimotoFeb 7

AI eliminated the natural barrier to entry that let OSS projects trust by default. People told me to do something rather than just complain. So I did. Introducing Vouch: explicit trust management for open source. Trusted people vouch for others. https://github.com/mitchellh/vouch

The idea is simple: Unvouched users can't contribute to your projects. Very bad users can be explicitly "denounced", effectively blocked. Users are vouched or denounced by contributors via GitHub issue or discussion comments or via the CLI.

Integration into GitHub is as simple as adopting the published GitHub actions. Done. Additionally, the system itself is generic to forges and not tied to GitHub in any way.

Who and how someone is vouched or denounced is up to the project. I'm not the value police for the world. Decide for yourself what works for your project and your community.

All of the data is stored in a single flat text file in your own repository that can be easily parsed by standard POSIX tools or mainstream languages with zero dependencies.

My hope is that eventually projects can form a web of trust so that projects with shared values can share their vouch lists with each other (automatically) so vouching or denouncing a person in one project has ripple effects through to other projects.

The idea is based on the already successful system used by @badlogicgames in Pi. Thank you Mario.

Ghostty will be integrating this imminently.

GitHub - mitchellh/vouch: A community trust management system based on explicit vouches to participate.

A community trust management system based on explicit vouches to participate. - mitchellh/vouch

GitHub
Show threadScott FrancisFeb 7
@mitchellh reminds me of early PGP Web of Trust days and keysigning parties
Show threadMitchell HashimotoFeb 7
@darkuncle That was exactly the inspiration.
Show threadScott FrancisFeb 7
@mitchellh this seems like it would take off much more easily without the requirement for offline in-person key review and comparison too (one of the big drags on adoption for PGP Web of Trust). And without the invariably awkward "parties" :)
Show threadMitchell Hashimoto
@darkuncle That's my hope for this project :) (since it requires none of that)
Feb 7 at 9:48pmWeb
Show threadNeal Gompa (ニール・ゴンパ) Feb 7

@mitchellh @darkuncle This has given me a lot of thought. The rise of code slop has definitely started to take a toll on me, and I wonder if there's a feasible way to bootstrap this mechanism so that I don't necessarily wipe out all interactions with new contributors just out of the gate.

But otherwise, I think this is at least walking down the right path.

Show threadque :verifried:Feb 7
@neal @mitchellh @darkuncle go through old
submissions/responses, if they were accepted/positive then "autovouch" them?
Show threadGozzFeb 8
@mitchellh This is great for ease of adoption, but to avoid getting locked into a forge, are there any plans to support vouching signing keys? There's possibly not much point denouncing signing keys.
Show threadMitchell HashimotoFeb 8
@gozz it already is forge agnostic, see the spec. But yes also want to support keys
Show threadGozzFeb 8
@mitchellh Neat! To clarify, I meant as in having a long-curated list of vouched GitHub users and then, if you decide to move elsewhere, having to match vouched contributors to new IDs. Doable, but friction.
Show threadayhonFeb 8
@gozz @mitchellh Sounds like Public Key Transparency to me. There's this project https://github.com/fedi-e2ee/public-key-directory-specification who has been recently trying to address it.
GitHub - fedi-e2ee/public-key-directory-specification: Specification for a Fediverse Directory Server for Public Keys

Specification for a Fediverse Directory Server for Public Keys - fedi-e2ee/public-key-directory-specification

GitHub