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

271–280 of 507 posts

Re: Vouch

#271

Post by 0xbadcafebee »

Use of a single sentence for --reason is an anti-pattern. The reasons for vouches are more important than the vouch themselves, as it gives context to the reader to whether the vouch is valuable or not. You'll see this when you look at other reputational review systems of humans. If there's very shallow vouch reasons (or none at all) it quickly leads to gaming of the system and fraudulent social credit increases. If there's rich vouch reasons, it's much harder to game the system, and easier for other members of the network to avoid fraudulent vouches.

The reason input should require a text field at least 5 lines long and 80 chars wide. This will influence the user to try to fill the box and provide more reason content, which results in higher quality signals.

Trust is a core security mechanism that the entire world depends on. It must be taken seriously and treated carefully.

Re: Vouch

#272

Post by wayeq »

fcantournet wrote: post #261

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…

did you have any actual criticism?

Re: Vouch

#273

Post by Barrin92 »

tmp10423288442 wrote: post #220

What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects? Say what you want about wanting to avoid politically disagreeable people, but Bluesky has been shrinking gradually since the 2024 election, as people interested in political effectiveness or even avoiding a hugbox have drifted away. Or think about how new projects are generally not started as GPL anymore (except if they want to charge…

>What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects?

I don't really see the issue, 'bubble', is a buzzword for what we used to call a community. You want to shrink viral online platforms to health, which is to say to a sustainable size of trusted and high quality contributors. Unqualified growth is the logic of both cancer and for-profit social media platforms, not of a functioning community of human beings.

Bluesky and Mastodon are a significantly more pleasant experience than Twitter or the Youtube comment section exactly because they turn most people away. If I were to manage a programming project, give me ten reliably contributors rather than a horde of slop programmers.

Re: Vouch

#274

Post by beepbooptheory »

tmp10423288442 wrote: post #220

What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects? Say what you want about wanting to avoid politically disagreeable people, but Bluesky has been shrinking gradually since the 2024 election, as people interested in political effectiveness or even avoiding a hugbox have drifted away. Or think about how new projects are generally not started as GPL anymore (except if they want to charge…

What does "interested in political effectiveness" mean? Like as opposed to ineffectiveness? Is it like bluesky is really libertarian now or something?

Re: Vouch

#275

Post by tgsovlerkhgsel »

btown wrote: post #257
tgsovlerkhgsel wrote: post #147

Earlier quoted context omitted.

Based on the description, I suspect the main goal isn't "trust" in the security sense, it's essentially a spam filter against low quality AI "contributions" that would consume all available review resources without providing corresponding net-positive value.

Per the readme: > Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change... So, let's move to an explicit trust model where trusted individuals can vouch for…

I suspect a good start might be engaging with the project and discussing the planned contribution before sending a 100kLOC AI pull request. Essentially some signal that the contributor intends to be a responsible AI driver not just a proxy for unverified garbage code.

Re: Vouch

#276

Post by strken »

Fnoord wrote: post #219
ramon156 wrote: post #186

Earlier quoted context omitted.

Sorry, but this seems like a privileged solution. Let's say you're a one-of-a-kind kid that already is making useful contributions, but $1 is a lot of money for you, then suddenly your work becomes useless? It feels weird to pay for providing work anyway. Even if its LLM gunk, you're paying to work (let alone pay for your LLM).

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

Re: Vouch

#277

Post by tonymet »

andai wrote: post #139

It should just be $1 to submit PR. If PR is good, maintainer refunds you ;) I noticed the same thing in communication. Communication is now so frictionless, that almost all the communication I receive is low quality. If it cost more to communicate, the quality would increase. But the value of low quality communication is not zero: it is actively harmful, because it eats your time.

in the 90s, before bayesian spam filtering, Microsoft proposed a proof of work for email along these lines. it would cost the server a few cents per message to sign and send emails, so spammers would not be able to afford spam, but regular senders could handle a small fee per day.

Re: Vouch

#278

Post by gdiamos »

I feel like a lot of software engineering problems come out of people who refuse to talk to each other than through comments in VCS.

It makes sense if you are collaborating over IRC, but I feel the need to face palm when people sitting next to each other do it.

What is your preferred way to talk to your team?

No English, only code

Slack

Zoom

In a meeting room

Over lunch

On a walk

One thing I’ve learned over time is that the highest bandwidth way of talking is face to face because you can read body language in addition to words. Video chat is okay, but an artificial and often overly formal setting. Phone is faster than text. Text drops the audio/visual/emotional signal completely. Code is precise but requires reverse engineering intent.

I personally like a walk, and then pair programming a shared screen.

Re: Vouch

#279

Post by spruce_tips »

andai wrote: post #139

It should just be $1 to submit PR. If PR is good, maintainer refunds you ;) I noticed the same thing in communication. Communication is now so frictionless, that almost all the communication I receive is low quality. If it cost more to communicate, the quality would increase. But the value of low quality communication is not zero: it is actively harmful, because it eats your time.

I built a side project to solve this for myself that’s basically an inbox toll system. It funnels emails from unknown senders into a hidden mailbox and auto replies to the sender with a payment link. After the sender pays, the email gets released to recipient’s main inbox. Recipient can set custom toll amounts, whitelist, etc.

Would be happy to share the code, just lmk!

Re: Vouch

#280

Post by chillingeffect »

I really like this...I've been trying to come up with a similar system, not necessarily for just gh, but for comms in general. And with groups so e.g. someone from my group can trust someone in the group of a someone I trust. And from there it would be neat to add voting...so someone requires a number of votes before they can be trusted.
Post reply on HN