Sibil attack in 3...2...1....
Vouch
251–260 of 507 posts
Re: Vouch
#252What'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…
[flagged]
Re: Vouch
#253Users 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…
> attacker "proves" themselves trustworthy on any project by behaving in an entirely helpful and innocuous manner, then leverages that to gain trust in target project (possibly through multiple intermediary projects).
Well, yea, I guess? That's pretty much how the whole system already works: if you're an attacker who's willing to spend a long time doing helpful beneficial work for projects, you're building a reputation that you can then abuse later until people notice you've gone bad.
This feels a bit https://xkcd.com/810/
Re: Vouch
#254Earlier quoted context omitted.
Vouch is forge-agnostic. See the 2nd paragraph in the README: > The implementation is generic and can be used by any project on any code forge, but we provide GitHub integration out of the box via GitHub actions and the CLI. And then see the trust format which allows for a platform tag. There isn't even a default-GitHub approach, just the GitHub actions default to GitHub via `--default-platform` flag (which makes sen…
I would rather stop contributing to open source rather than interact with your gatekeeping social experiment.
That’s fine and doesn’t bother me one bit.
Re: Vouch
#255Re: Vouch
#256It 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.
This thought pattern leads to crypto. In that world there's a process called "staking" where you lock some tokens with a default lock expiry action and a method to unlock based on the signature from both participants. It would work like this: Repo has a public key. Submitted uses a smart contract to sign the commit with along with the submission of a crypto. If the repo merges it then the smart contract returns the t…
It feels like the problem here comes from the reluctance to utilize a negative sum outcome for rejection. Instead of introducing accidental perverse incentives, if rejected your stake shouldn't go to the repo, 50% could be returned, and 50% deleted. If it times out or gets approved you get 100% back. If a repo rejects too often or is seen doing so unfairly reputation would balance participation.
Re: Vouch
#257Users 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…
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 others, and those vouched individuals can then contribute.
And per https://github.com/mitchellh/vouch/blob/main/CONTRIBUTING.md :
> If you aren't vouched, any pull requests you open will be automatically closed. This system exists because open source works on a system of trust, and AI has unfortunately made it so we can no longer trust-by-default because it makes it too trivial to generate plausible-looking but actually low-quality contributions.
===
Looking at the closed PRs of this very project immediately shows https://github.com/mitchellh/vouch/pull/28 - which, true to form, is an AI generated PR that might have been tested and thought through by the submitter, but might not have been! The type of thing that can frustrate maintainers, for sure.
But how do you bootstrap a vouch-list without becoming hostile to new contributors? This seems like a quick way for a project to become insular/isolationist. The idea that projects could scrape/pull each others' vouch-lists just makes that a larger but equally insular community. I've seen well-intentioned prior art in other communities that's become downright toxic from this dynamic.
So, if the goal of this project is to find creative solutions to that problem, shouldn't it avoid dogfooding its own most extreme policy of rejecting PRs out of hand, lest it miss a contribution that suggests a real innovation?
Re: Vouch
#258Earlier quoted context omitted.
I had this idea / pet project once where I did exactly this for email. Emails would immediately bounce with payment link and explanation. If you paid you get credit on a ledger per email address. Only then the mail goes through. You can also integrate it in clients by adding payment/reward claim headers.
Scammers (and spammers) always got $1! That's why there's a lot of the scam ads on google, fb, apple. So the paywall email firewall will not work as desired.
Not many email attacks are worth an entire dollar. It would be very very effective at reducing spam. And too effective at reducing everything else.
Re: Vouch
#259Oh and one other thing I was curious about. Did Mitchell comment on why he wrote it in nushell? I've not really messed around with that myself yet. Would people recommend it? I feel like I have such huge inertia for changing shells at this point that I've rarely seriously considered it.
Nushell has great sugar coating but mishandles basics like it will eat errors and get into impossible code paths on control-C. I have given up on it.
may be it improved? when you last time tried?
Re: Vouch
#260I love the idea, but it's going to be cancelled for sure.