Vouch

174 pointsby dboon2026. 2. 8.39 comments

<a href="https://x.com/mitchellh/status/2020252149117313349" rel="nofollow">https://x.com/mitchellh/status/2020252149117313349</a><p><a href="https://nitter.net/mitchellh/status/2020252149117313349" rel="nofollow">https://nitter.net/mitchellh/status/2020252149117313349</a><p><a href="https://github.com/ghostty-org/ghostty/pull/10559" rel="nofollow">https://github.com/ghostty-org/ghostty/pull/10559</a>

요약

Vouch는 AI 도구로 가능해진 저품질 기여를 막기 위해 설계된 실험적인 프로젝트 신뢰 관리 시스템입니다. 이를 통해 프로젝트는 사용자를 명시적으로 보증하거나 거부하여 서로 다른 프로젝트 간에 공유될 수 있는 신뢰 네트워크를 구축할 수 있습니다. 이 시스템은 구성 가능하며 GitHub 액션과 CLI를 통해 GitHub와 통합되며, 신뢰 목록을 관리하기 위한 간단한 파일 형식을 사용합니다.

quantumwoke•3시간 전

Previous discussion: https://news.ycombinator.com/item?id=46930961

toomim•2시간 전

From just 14 hours ago!?

abracos•2시간 전

Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors

[삭제된 댓글]

DJBunnies•2시간 전

Indeed, it's relatively impossible without ties to real world identity.

smotched•2시간 전

you can't really build a perfect system, the goal would be to limit bad actors as much as possible.

dboon•2시간 전

You can't get perfection. The constraints / stakes are softer with what Mitchell is trying to solve i.e. it's not a big deal if one slips through. That being said, it's not hard to denounce the tree of folks rooted at the original bad actor.

hobofan•2시간 전

Then you would just un-vouch them? I don't see how its easy to game on that front.

speps•2시간 전

The usual way of solving this is to make the voucher responsible as well if any bad actor is banned. That adds a layer of stake in the game.

mjr00•2시간 전

At a technical level it's straightforward. Repo maintainers maintain their own vouch/denouncelists. Your maintainers are assumed to be good actors who can vouch for new contributors. If your maintainers aren't good actors, that's a whole other problem. From reading the docs, you can delegate vouching to newly vouched users, as well, but this isn't a requirement.

The problem is at the social level. People will not want to maintain their own vouch/denounce lists because they're lazy. Which means if this takes off, there will be centrally maintained vouchlists. Which, if you've been on the internet for any amount of time, you can instantly imagine will lead to the formation of cliques and vouchlist drama.

IshKebab•2시간 전

> Who and how someone is vouched or denounced is left entirely up to the project integrating the system.

Feels like making a messaging app but "how messages are delivered and to whom is left to the user to implement".

I think "who and how someone is vouched" is like 99.99% of the problem and they haven't tried to solve it so it's hard to see how much value there is here. (And tbh I doubt you really can solve this problem in a way that doesn't suck.)

[삭제된 댓글]

skeeter2020•2시간 전

Agree! Real people are not static sets of characteristics, and without a immutable real-world identity this is even harder. It feels like we've just moved the problem from "evaluate code one time" to "continually evaluate a persona that could change owners"

vips7L•2시간 전

Love seeing some nushell usage!

[삭제된 댓글]

aatd86•2시간 전

Does is overlap with Contributor License Agreement?

throwaway150•2시간 전

[dupe] https://news.ycombinator.com/item?id=46930961

quotemstr•2시간 전

Fortunately, as long as software is open sourced, forking will remain a viable way to escape overzealous gatekeeping.

skeeter2020•2시간 전

Doesn't this just shift the same hard problem from code to people? It may seem easier to assess the "quality" of a person, but I think there are all sorts of complex social dynamics at play, plus far more change over time. Leave it to us nerds to try and solve a human problem with a technical solution...

mjr00•1시간 전

> Leave it to us nerds to try and solve a human problem with a technical solution...

Honestly, my view is that this is a technical solution for a cultural problem. Particularly in the last ~10 years, open source has really been pushed into a "corporate dress rehearsal" culture. All communication is expected to be highly professional. Talk to everyone who opens an issue or PR with the respect you would a coworker. Say nothing that might offend anyone anywhere, keep it PG-13. Even Linus had to pull back on his famously virtiolic responses to shitty code in PRs.

Being open and inclusive is great, but bad actors have really exploited this. The proper response to an obviously AI-generated slop PR should be "fuck off", closing the PR, and banning them from the repo. But maintainers are uncomfortable with doing this directly since it violates the corporate dress rehearsal kayfabe, so vouch is a roundabout way of accomplishing this.

dom96•2시간 전

Initially I liked the idea, but the more I think about it the more this feels like it just boils down to: only allow contributions from a list of trusted people.

3371•1시간 전

Well a lot of useful things are not useful because they are innovative, but well designed an executed.

ramses0•1시간 전

It's similar to old Usenet "killfiles" - https://en.wikipedia.org/wiki/Kill_file

...or spam "RBL" lists which were often shared. https://en.wikipedia.org/wiki/Domain_Name_System_blocklist

rvz•1시간 전

This makes a lot more sense for large scale and high profile projects, and it eliminates low quality slop PRs by default with the contributors having to earn the trust of the core maintainers to contribute directly to the project.

jprosevear•2시간 전

Prior art? https://en.wikipedia.org/wiki/Advogato

thenaturalist•1시간 전

Dupe of https://news.ycombinator.com/item?id=46930961

HiPhish•1시간 전

Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongthinkers. Said something double-plus-ungood on Twitter? Denounced. Accepted contribution from someone on a prominent denouncelist? Denouced. Not that it was not possible to create such lists before, but it was all informal.

The real problem are reputation-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea:

- The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop)

- Depending on how the PR was closed the reputation rises or drops

- Reputation can only be raised or lowered when interacting with another repo

The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.

zozbot234•1시간 전

GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"

adeebshihadeh•1시간 전

"Open source has always worked on a system of trust and verify"

Not sure about the trust part. Ideally, you can evaluate the change on its own.

In my experience, I immediately know whether I want to close or merge a PR within a few seconds, and the hard part is writing the response to close it such that they don't come back again with the same stuff.

(I review a lot of PRs for openpilot - https://github.com/commaai/openpilot)

rafram•1시간 전

> In my experience, I immediately know whether I want to close or merge a PR within a few seconds

Not sure this is what I want to hear about a system that people entrust their lives to on the highway…

BiteCode_dev•1시간 전

Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.

staticassertion•1시간 전

Reminds me a bit of cargo-crev.

1a527dd5•1시간 전

I think denouncing is an incredibly bad idea especially as the foundation of VOUCH seems to be web of trust.

If you get denounced on a popular repo and everyone "inherits" that repo as a source of trust (e.g. think email providers - Google decides you are bad, good luck).

Couple with the fact that usually new contributors take some time to find their feet.

I've only been at this game (SWE) for ~10 years so not a long time. But I can tell you my first few contributions were clumsy and perhaps would have earned my a denouncement.

I'm not sure if I would have contributed to the AWS SDK, Sendgrid, Nunit, New Relic (easily my best experience) and my attempted contribution to Npgsql (easily my worst experience) would have definitely earned me a denouncement.

Concept is good, but I would omit the concept of denouncement entirely.

rvz•1시간 전

This makes sense for large-scale and widely used projects such as Ghostty.

It also addresses the issue in tolerating unchecked or seemingly plausible slop PRs from outside contributors from ever getting merged in easily. By default, they are all untrusted.

Now this social issue has been made worse by vibe-coded PRs; and untrusted outside contributors should instead earn their access to be 'vouched' by the core maintainers rather than them allowing a wild west of slop PRs.

A great deal.

Vouch

요약

댓글 (42)