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

231–240 of 507 posts

Re: Vouch

#231

Post by bastawhiz »

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'll simply never file PRs, then. I'd say 4 out of every 5 PRs I file never get a response. Some on very large projects, and I like to think my PRs are more useful than docs fixes or pointless refactors. I'm simply not going to spend money to have to float around in the void endlessly because a maintainer lost interest in the project and won't ever look at my PR, I'll simply keep my changes on a downstream fork.

Moreover, I'm not interested in having my money get handed over to folks who aren't incentivized to refund my money. In fact, they're paying processing costs on the charge, so they are disincentivized to refund me! There could be an escrow service that handles this, but now there's another party involved: I just want to fix a damn bug, not deal with this shit.

Re: Vouch

#232

Post by Yizahi »

supriyo-biswas wrote: post #64
speps wrote: post #52

Earlier quoted context omitted.

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.

And another practical observation is that not many people have Lobsters account or even heard about it due to that (way less than people who heard about HN). Their "solution" is to make newcomers beg for invites in some chat. Guess what would a motivated malicious actor would do any times required and a regular internet user won't bother? Yeah, that.

Re: Vouch

#233

Post by stavros »

pwdisswordfishs wrote: post #213
stavros wrote: post #187

Earlier quoted context omitted.

People aren't on Github just to implement reputation-based management, though.

What does that observation have to do with the topic under the microscope?

> GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem.

The community might be a problem, but that doesn't mean it's a big enough problem to move off completely. Whitelisting a few people might be a good enough solution.

Re: Vouch

#234

Post by Yizahi »

hobofan wrote: post #49
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

Then you would just un-vouch them? I don't see how its easy to game on that front.

Malicious "enabler" already in the circular vouch system would then vouch for new malicious accounts and then unvouch after those are accepted, hiding the connection. So then someone would need to manually monitor the logs for every state change of all vouch pairs. Fun :)

Re: Vouch

#235

Post by Fogest »

swordsith wrote: post #156
buovjaga wrote: post #134

Earlier quoted context omitted.

One solution is to have a screensharing call with the contributor and have them explain their patch. We have already caught a couple of scammers who were applying for a FOSS internship this way. If they have not yet submitted anything non-trivial, they could showcase personal projects in the same way. FOSS has turned into an exercise in scammer hunting.

I'm not sure if I follow, are the PRs legitimate and they are just being made to buff their resume, or are PRs malicious?

They are becoming AI slop more and more likely in an attempt to buff their resumes by making it look like they contribute to a bunch of open source. Basically low effort low quality submissions for silly things that just waste maintainers time.

Re: Vouch

#236

Post by kleyd »

Thought experiment: strip a forge down to what plain Git can't do: identity (who?), attestations (signed claims about a ref or actor), and policy (do these claims allow this ref update?).

With just those primitives, CI is a service that emits "ci/tested." Review emits "review/approved." A merge controller watches for sufficient attestations and requests a ref update. The forge kernel only evaluates whether claims satisfy policy.

Vouch shifts this even further left: attestations about people, not just code. "This person is trusted" is structurally the same kind of signed claim as "this commit passed CI." It gates participation itself, not just mergeability.

All this should ideally be part of a repo, not inside a closed platform like github. I like it and am curious to see where this stands in 5 years.

Re: Vouch

#237

Post by javier123454321 »

femto113 wrote: post #144

Users already proven to be trustworthy in one project can automatically be assumed trustworthy in another project, and so on. I get the spirit of this project is to increase safety, but if the above social contract actually becomes prevalent this seems like a net loss. It establishes an exploitable path for supply-chain attacks: attacker "proves" themselves trustworthy on any project by behaving in an entirely helpfu…

Yeah, as that's a different problem unrelated to the problem that this is trying to solve.

Re: Vouch

#238

Post by dcre »

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…

“Shrinking since the election”, while technically true, is misleading because the election is when bsky experienced a massive spike in usage that was well over double the average before the election. Usage has been gradually decaying since then to a steady level much higher than it was before the election.

If you zoom out to a few years you can see the same pattern over and over at different scales — big exodus event from Twitter followed by flattening out at level that is lower than the spike but higher than the steady state before the spike. At this point it would make sense to say this is just how Bluesky grows.

https://bsky.jazco.dev/stats

Besides that, the entire point of this project is to increase the barrier to entry for potential contributors (while ideally giving good new people a way in). So I really don’t think they’re worried about this problem.

Re: Vouch

#239

Post by zahrevsky »

bastawhiz wrote: post #231
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'll simply never file PRs, then. I'd say 4 out of every 5 PRs I file never get a response. Some on very large projects, and I like to think my PRs are more useful than docs fixes or pointless refactors. I'm simply not going to spend money to have to float around in the void endlessly because a maintainer lost interest in the project and won't ever look at my PR, I'll simply keep my changes on a downstream fork. More…

The system could be set up to automatically refund, if your PR wasn't checked for over $AVERAGE_TIME_TO_FIRST_REVIEW$ days. The variable is specific to the project, and even can be recalculated regularly and be parameterized with PR size.

Re: Vouch

#240

Post by Fnoord »

To people who don't like this, ask yourself the following: would you complain to someone who had a too strict spam filter or firewall? Or would you be like, we'll work it out? That is how I regard this function: as a (crowdsourced / WoT) spam filter or firewall. Can it be annoying? For sure. Will you work around it if needed? If it is worth the hassle, yes.

How many important emails have been lost due to spam filters, how many important packets have been dropped by firewalls? Or, how much important email or important packets weren't sent because "it wasn't worth the hassle"? I'm sure all of that happened, but to which proportions? If it wasn't worth it, the measures would have been dropped. Same here: I regard it as a test, and if it isn't worth it, it'll be stopped. Personally, I run with a 'no spam' sticker on my physical postbox, as well as a 'no spam' for salesmen the former of which is enforced by national law.

FWIW, it is very funny to me, the people who ignore it: 1) very small businesses 2) shady businesses (possibly don't understanding the language?) 3) some charities who believe they're important (usually a nice response: 'oh, woops') 4) alt-right spammers who complain about the usual shit they find important (e.g. foreigners) 5) After 10 years I can report Jehova's have figured out the meaning of the texts (or remember to not bother here)!

It is my time, it is my door, my postbox. I'm the one who decide about it, not you.

Same here. It is their time, it is their project. They decide if you get to play along, and how. Their rules.

Post reply on HN