Live data from Hacker News

Vouch

github.com

461–470 of 507 posts

Re: Vouch

#461
We need this for social media.

I've theorized what a solution would look like, though it'd have a different end goal to ignore bots so true discourse could be achieved. The theorized solution would be less communal though - instead, institutions would be "vouchers" and be provided the ability to confirm individuals as a real person. This could be colleges, workplaces, unions, banks, etc. There'd be no "denouncing", only "vouching" the individual as a real person. The individual's identity would never exposed - social media platforms would use a key, such as an e-mail, to verify the individual's existence as a real person, not their identity. Platforms could identify what rules would qualify an individual's recognized "existence", such as what institutions they allow, minimum number of institutions, etc. In theory, the individual "existence" could be built before they ever register for a platform. This could go way beyond social media platforms too - some examples could be vetting job applications, accepting contributors on OSS projects.

This would create a digital fingerprint of a real individual using their unique identifiers (email, phone number, etc) which may be undesirable, but individuals would absolutely have the ability to revoke their unique identifiers from participating in the program if they desire.

Re: Vouch

#462
post #353

Earlier quoted context omitted.

Sure, but your average developer doesn't have a lot of agency in if the US invades another country in order to increase the value of the coin they got for having a PR merged. But with crypto they do. See for example all the BAGS coins that get created for random opensource projects and the behavior that occurs because of that.

Just use a stablecoin, don't float a "utility token" those things are stupid. Have a smart contract receive a USDC deposit. If the maintainer "times out" reviewing your PR, the contract returns all the deposit. If the maintainer does not accept your PR, the contract burns 0.5x of the deposit and returns the rest. Maintainers can decide to turn off the time-out for very popular projects where you probably would have d…

You don't even need to burn it, just send it to someone other than the developers, like the EFF, so the developers aren't given a perverse incentive.

Re: Vouch

#463

Earlier quoted context omitted.

I mean to well meaning contributors, I understand the goal of vouch, I think it goes too far and you'll turn off said well meaning contributors I certainly have dropped off when projects have burdensome rules, even before ai slop fest

These projects would rather miss out on a few good people to stop the bad ones over the alternative.

I think there are better alternatives, we'll let the market weed things out

For example, I will keep making them spin wheels and burn tokens / money, a sort of honeypot, adversarial shadowban. This is even better for disincentivizing them.

Will automate it if it ever gets bad

Re: Vouch

#464

OSS was already brutal for new contributors before AI. You'd spend hours on a good-faith PR and get ignored for months, or get torn apart in review because you didn't know the unwritten conventions. The signal-to-noise ratio sucked but at least maintainers would eventually look at your stuff. Now with AI-generated spam everywhere, maintainers have even more reason to be suspicious of unknown names. Vouch solves their…

Building projects, especially larger ones, has not been solely about writing code. I don't see how anything you are saying is a bad thing at all. Drive-by PRs and similar practices are bad. A high barrier is a feature, not a bug.

Re: Vouch

#465

OSS was already brutal for new contributors before AI. You'd spend hours on a good-faith PR and get ignored for months, or get torn apart in review because you didn't know the unwritten conventions. The signal-to-noise ratio sucked but at least maintainers would eventually look at your stuff. Now with AI-generated spam everywhere, maintainers have even more reason to be suspicious of unknown names. Vouch solves their…

The comment I read about this that I liked was that they want to push the idea of starting with an Issue and a discussion before going straight to a PR. That way you can build reputation by contributing to a discussion first. Maybe you could "earn" a temporary Vouch like this that lets you start submitting. Still open to attack but the attack is at least more difficult.

Re: Vouch

#468
post #51

Earlier quoted context omitted.

> Indeed, it's relatively impossible without ties to real world identity. I don't think that's true? The goal of vouch isn't to say "@linus_torvalds is Linus Torvalds" it's to say "@linus_torvalds is a legitimate contributor an not an AI slopper/spammer". It's not vouching for their real world identity, or that they're a good person, or that they'll never add malware to their repositories. It's just vouching for the…

That’s not the point. Point is: when @lt100, @lt101, … , @lt999 all vouch for something, it’s worthless.

That's really easy to clean up, if you maintain the tree of trust. If a parent node gets whacked, all the child nodes do, too.

Re: Vouch

#469

Earlier quoted context omitted.

> "it's a donation to a project you care about" But I'm already donating my time by creating a PR, it definitely would disincentivize me to make PRs if I had to also pay in addition to already doing the actual work. Just always such a shame that the good people have to suffer because of the actions of the shitty people...

Nope. From the POV of the maintainer, you are creating extra, and probably unnecessary, work for them.

If that's actually the opinion of the maintainer, why even accept PRs at all? At that point, just categorically deny any. I was thinking more of actual community projects that _want_ community PRs. Those seem to have welcomed my contributions in the past, but of course they were not just AI slop or other low effort PRs.

Re: Vouch

#470
post #345

Earlier quoted context omitted.

I think something people are missing here is, this is a response to the groundswell in vibecoded slop PRs. The point of the vouch system is not to blindly merge code from trusted individuals; it's to completely ignore code from untrusted individuals, permitting you to spend more time reviewing the MRs which remain.

Would it not be better to report accounts then?

To whom? It's not against Github's ToS to submit a bad PR. Anyway, bad actors can just create new accounts. It makes more sense to circulate whitelists of people who are known not to be bad actors.

I also like the flexibility of a system like this. You don't have to completely refuse contributions from people who aren't whitelisted, but since the general admission queue is much longer and full of slop, it makes sense to give known good actors a shortcut to being given your attention.

Post reply on HN