Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vouch

github.com

Post reply on HN
Print view View original

61–70 of 507 posts

Re: Vouch

#61

Post by ibrahima »

Animats wrote: post #29
alexjurkiewicz wrote: post #11

The Web of Trust failed for PGP 30 years ago. Why will it work here? For a single organisation, a list of vouched users sounds great. GitHub permissions already support this. My concern is with the "web" part. Once you have orgs trusting the vouch lists of other orgs, you end up with the classic problems of decentralised trust: 1. The level of trust is only as high as the lax-est person in your network 2. Nobody is p…

> The Web of Trust failed for PGP 30 years ago. Why will it work here? It didn't work for links as reputation for search once "SEO" people started creating link farms. It's worse now. With LLMs, you can create fake identities with plausible backstories. This idea won't work with anonymity. It's been tried.

I guess this is why Sam Altman wants to scan everyone's eyeballs.

Re: Vouch

#63

Post by skeeter2020 »

IshKebab wrote: post #47

> 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 pro…

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"

Re: Vouch

#64

Post by supriyo-biswas »

speps wrote: post #52
abracos wrote: post #42

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

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.

A practical example of this can be seen in lobsters invite system, where if too many of the invitee accounts post spam, the inviter is also banned.

Re: Vouch

#65

Post by anupamchugh »

dboon wrote: post #48
abracos wrote: post #42

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

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.

> The interesting failure mode isn’t just “one bad actor slips through”, it’s provenance: if you want to > “denounce the tree rooted at a bad actor”, you need to record where a vouch came from (maintainer X, > imported list Y, date, reason), otherwise revocation turns into manual whack-a-mole. > > Keeping the file format minimal is good, but I’d want at least optional provenance in the details field > (or a sidecar) so you can do bulk revocations and audits.

Re: Vouch

#66

Post by 3371 »

dom96 wrote: post #60

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.

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

Re: Vouch

#67

Post by HiPhish »

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.

Re: Vouch

#68

Post by mjr00 »

skeeter2020 wrote: post #59

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...

> 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.

Re: Vouch

#69

Post by ramses0 »

dom96 wrote: post #60

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.

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

Re: Vouch

#70

Post by adeebshihadeh »

"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)

Post reply on HN