Live data from Hacker News

Vouch

github.com

121–130 of 507 posts

Re: Vouch

#121
post #112

Earlier quoted context omitted.

> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway. Good reason to be careful. Maybe there's a bit of an upside to: if you vouch for someone who does good work, then you get a little boost too. It's how personal relationships work anyway. ---------- I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good us…

I don't think that trust is easily transferable between projects, and tracking "karma" or "reputation" as a simple number in this file would be technically easy. But how much should the "karma" value change form different actions? It's really hard to formalize efficiently. The web of trust, with all intricacies, in small communities fits well into participants' heads. This tool is definitely for reasonably small "cor…

> I don't think that trust is easily transferable between projects

Not easily, but I could imagine a project deciding to trust (to some degree) people vouched for by another project whose judgement they trust. Or, conversely, denouncing those endorsed by a project whose judgement they don't trust.

In general, it seems like a web of trust could cross projects in various ways.

Re: Vouch

#122
post #113

"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/o…

When there's time, you review, when there isn't you trust...

That's the issue here.

Even if I trust you, I still need to review your work before merging it.

Good people still make mistakes.

Re: Vouch

#123

IMO: trust-based systems only work if they carry risk. Your own score should be linked to the people you "vouch for" or "denounce". This is similar to real life: if you vouch for someone (in business for example), and they scam them, your own reputation suffers. So vouching carries risk. Similarly, if you going around someone is unreliable, but people find out they actually aren't, your reputation also suffers. If vo…

> trust-based systems only work if they carry risk. Your own score should be linked to the people you "vouch for" or "denounce"

This is a graph search. If the person you’re evaluating vouches for people those you vouch for denounce, then even if they aren’t denounced per se, you have gained information about how trustworthy you would find that person. (Same in reverse. If they vouch for people who your vouchers vouch for, that indirectly suggests trust even if they aren’t directly vouched for.)

Re: Vouch

#125
Why in nushell? Not in go?

But I like the idea and principle. OSS need this and it's traded very lightly.

Re: Vouch

#126
Central karma database next, please. Vouch = upvote, denounce = downvote

Re: Vouch

#127
post #67

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

>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR

Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.

Re: Vouch

#128

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…

I'm not convinced that just because something didn't work 30 years ago, there's no point in revisiting it.

There's likely no perfect solution, only layers and data points. Even if one of the layers only provides a level of trust as high as the most lax person in the network, it's still a signal of something. The internet will continue to evolve and fracture into segments with different requirements IMHO.

Re: Vouch

#129
post #96

Earlier quoted context omitted.

Why? I don't appreciate comments that cast doubt on decent technical contributors without any substance to back it up. It's a cheap shot from anonymity.

I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes. If you had left it at know you want to reject a PR within a few seconds, that'd be fine. Although with safety critical systems I'd probably want each contributor to have some experience in the field too.

Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos

Re: Vouch

#130

I don't know if this is the right solution, but I appreciate the direction. It's clear that AI slop is trading on people's good names and network reputation. Poisoning the well. The dead internet is here. In multiple domains people are looking for a solution to "are you someone/something worthy of my emotional investment." I don't think code can be held to be fully AI-free, but we need a way to check that they are em…

That's what I thought of right away as well. We may end up with a blacklist of "known AI slop peddlers".
Post reply on HN