Live data from Hacker News

Vouch

github.com

281–290 of 507 posts

Re: Vouch

#282
post #91

Earlier quoted context omitted.

I'm guessing denounce is for bad faith behavior, not just low quality contributions. I think it's actually critical to have a way to represent this in a reputation system. It can be abused, but abuse of denouncement is grounds for denouncement, and being denounced by someone who is denounced by trusted people should carry little weight.

IDK about this implementation ... OVER-Denouncing ought to be tracked, too, for a user's trustworthiness profile.

I'm pretty sure this project just does the storage model. It's up to communities that use it to determine the semantics and derive reputation and other higher level concepts from the data.

Re: Vouch

#283

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…

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

Both sides of the equation can be gamed. This has always been the issue with reputation systems.

Re: Vouch

#284
The underlying idea is admirable, but in practice this could create a market for high-reputation accounts that people buy or trade at a premium.

Once an account is already vouched, it will likely face far less scrutiny on future contributions — which could actually make it easier for bad actors to slip in malware or low-quality patches under the guise of trust.

Re: Vouch

#285
post #276
post #219

Earlier quoted context omitted.

It is a privileged solution. And a stupid one, too. Because $1 is worth a lot more for someone in India, than someone in USA. If you want to implement this more fairly, you'd be looking at something like GDP or BBP plus geolock. Streaming services perfected this mechanism already.

This might be by design. Almost anyone writing software professionally at a level beyond junior is getting paid enough that $1 isn't a significant expense, whether in India or elsewhere. Some projects will be willing to throw collaboration and inclusivity out the window if it means cutting their PR spam by 90% and only reducing their pool of available professional contributors by 5%.

Indian here. You are correct. Expecting any employed Indian software developer to not be able to spare 1$ is stupid. Like how exactly poor do you think we are?!

Re: Vouch

#286
This reminds me of the time that Ripple launched a marketing promotion, giving developers some amount of Ripple to encourage micropayments. They defined "developer" as "someone who has had a GitHub account for 1 year prior to this announcement" to stop folks from creating hundreds of new accounts to claim credits. This essentially created a bounty on existing GitHub accounts and led to thousands of account compromises due to poor password hygiene. GitHub account security is much better now than it was back then (Nov 2013), but this solution similarly puts a bounty on highly-vouched accounts.

Re: Vouch

#287

This looks like a fairly typical engineer's solution to a complex social problem: it doesn't really solve the problem, introduces other issues / is gameable, yet unlikely to create problems for the creator. Of course creator answers any criticism of the solution with "Well make something better". That's not the point: this is most likely net negative, at least that is the (imo well supported) opinion of critics. If t…

cons to YOU outway the pros. pros to HIM outway the cons.

Re: Vouch

#288

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…

If we want to make it extremely complex, wasteful, and unusable for 99% of people, then sure, put it on the blockchain. Then we can write tooling and agents in Rust with sandboxes created via Nix to have LLMs maintain the web of trust by writing Haskell and OCaml.

Boring Java dev here. Do I just sit this one out?

Re: Vouch

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

And...that's bad?

Re: Vouch

#290

The underlying idea is admirable, but in practice this could create a market for high-reputation accounts that people buy or trade at a premium. Once an account is already vouched, it will likely face far less scrutiny on future contributions — which could actually make it easier for bad actors to slip in malware or low-quality patches under the guise of trust.

How is that different from what happens now, where someone who contributes regularly to a project faces less scrutiny than a new person?
Post reply on HN