Vouch

It seems like dating apps to me. You have a large population of undesirables so I think we'll see the same patterns like pay-to-play and some social credit or ELO ranking score.

this highlights the saddest thing about this whole generative ai thing. beforehand, there was opportunity to learn, deliver and prove oneself outside of classical social organization. now that's all going to go away and everyone is going to fall back on credentials and social standing. what an incredible shame for social mobility and those who for one reason or another don't fit in with traditional structures.

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 helpful and innocuous manner, then leverages that to gain trust in target project (possibly through multiple intermediary projects). If this sort of cross project trust ever becomes automated then any account that was ever trusted anywhere suddenly becomes an attractive target for account takeover attacks. I think a pure distrust list would be a much safer place to start.

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.

"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/openpilot)

How does a potential positive contributor pierce through? If they are not contributing to something already and are not in the network with other contributors? They might be a SME on the subject and legit have something to bring to the table but only operated on private source.

I get that AI is creating a ton of toil to maintainers but this is not the solution.

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 vouching or denouncing become free, it will become too easy to weaponize.

Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.

feels very micromanagement-ish

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.

Prior art? https://en.wikipedia.org/wiki/Advogato

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

> The idea is based on the already successful system used by @badlogicgames in Pi. Thank you Mario.

This is from the twitter post referenced above, and he says the same thing in the ghostty issue. Can anyone link to discussion on that or elaborate?

(I briefly looked at the pi repo, and have looked around in the past but don't see any references to this vouching system.)

So you're screwed if you don't have any connections. In that way it's just like meat space.

I'm reminded of the old Usenet responses to people claiming to solve the spam problem, so I can't help myself:

    Your solution advocates a
    ( ) technical (X) social ( ) policy-based ( ) forge-based
    approach to solving AI-generated pull requests to open source projects. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws.)
    
    ( ) PR spammers can easily use AI to adapt to detection methods
    ( ) Legitimate non-native English speakers' contributions would be affected
    ( ) Legitimate users of AI coding assistants would be affected
    ( ) It is defenseless against determined bad actors
    ( ) It will stop AI slop for two weeks and then we'll be stuck with it
    (X) Project maintainers don't have time to implement it
    (X) Requires immediate total cooperation from maintainers at once
    (X) False positives would drive away genuine new contributors
    
    Specifically, your plan fails to account for
    (X) Ease of creating new GitHub accounts
    (X) Script kiddies and reputation farmers
    ( ) Armies of LLM-assisted coding tools in legitimate use
    (X) Eternal arms race involved in all detection approaches
    ( ) Extreme pressure on developers to use AI tools
    (X) Maintainer burnout that is unaffected by automated filtering
    ( ) Graduate students trying to pad their CVs
    ( ) The fact that AI will only get better at mimicking humans
    
    and the following philosophical objections may also apply:
    (X) Ideas similar to yours are easy to come up with, yet none have ever
    been shown practical
    (X) Allowlists exclude new contributors
    (X) Blocklists are circumvented in minutes
    ( ) We should be able to use AI tools without being censored
    (X) Countermeasures must work if phased in gradually across projects
    ( ) Contributing to open source should be free and open
    (X) Feel-good measures do nothing to solve the problem
    (X) This will just make maintainer burnout worse
    
    Furthermore, this is what I think about you:
    (X) Sorry dude, but I don't think it would work.
    ( ) This is a stupid idea, and you're a stupid person for suggesting it.
    ( ) Nice try, assh0le! I'm going to find out what project you maintain and
    send you 50 AI-generated PRs!

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-farmers. They open hundreds of low-effort PRs on GitHub in the hope that some of them get merged. This will increase the reputation of their accounts, which they hope will help them stand out when applying for a job. So the solution would be for GitHub to implement a system to punish bad PRs. Here is my idea:

- The owner of a repo can close a PR either neutrally (e.g. an earnest but misguided effort was made), positively (a valuable contribution was made) or negatively (worthless slop)

- Depending on how the PR was closed the reputation rises or drops

- Reputation can only be raised or lowered when interacting with another repo

The last point should prevent brigading, I have to make contact with someone before he can judge me, and he can only judge me once per interaction. People could still farm reputation by making lots of quality PRs, but that's actually a good thing. The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PRs, but people can already do that sort of thing. Maybe the reputation should not be a total sum, but per project? Anyway, the idea is for there to be some negative consequences for people opening junk PRs.

Hope github can natively integrate something in the platform, a relevant discussion I saw on official forums: https://github.com/orgs/community/discussions/185387

Interesting idea.

It spreads the effort for maintaining the list of trusted people, which is helpful. However I still see a potential firehose of randoms requesting to be vouched for. Various ways one might manage that, perhaps even some modest effort preceding step that would demonstrate understanding of the project / willingness to help, such as A/B triaging of several pairs of issues, kind of like a directed, project relevant CAPTCHA?

I believe interviewing devs before allowing them to contribute is a good strategy for the upcoming years. Let’s treat future OS contributors the same way companies/startups do when they want to hire new devs.

Are we seeing forum moderations (e.g., Discourse trust levels^[1]) coming to source code repositories?

[1]: https://blog.discourse.org/2018/06/understanding-discourse-t...

I think LLMs are accelerating us toward a Dune-like universe, where humans come before AI.

Reminds me of the reputation system that the ITA in Anathem by Neal Stephenson seem to have. One character (Sammann) needs access to essentially a private BBS and has to get validated.

“After we left Samble I began trying to obtain access to certain reticules,” Sammann explained. “Normally these would have been closed to me, but I thought I might be able to get in if I explained what I was doing. It took a little while for my request to be considered. The people who control these were probably searching the Reticulum to obtain corroboration for my story.”

“How would that work?” I asked.

Sammann was not happy that I’d inquired. Maybe he was tired of explaining such things to me; or maybe he still wished to preserve a little bit of respect for the Discipline that we had so flagrantly been violating. “Let’s suppose there’s a speelycaptor at the mess hall in that hellhole town where we bought snow tires.”

“Norslof,” I said.

“Whatever. This speelycaptor is there as a security measure. It sees us walking to the till to pay for our terrible food. That information goes on some reticule or other. Someone who studies the images can see that I was there on such-and-such a date with three other people. Then they can use other such techniques to figure out who those people are. One turns out to be Fraa Erasmas from Saunt Edhar. Thus the story I’m telling is corroborated.”

“Okay, but how—”

“Never mind.” Then, as if he’d grown weary of using that phrase, he caught himself short, closed his eyes for a moment, and tried again. “If you must know, they probably ran an asamocra on me.”

“Asamocra?”

“Asynchronous, symmetrically anonymized, moderated open-cry repute auction. Don’t even bother trying to parse that. The acronym is pre-Reconstitution. There hasn’t been a true asamocra for 3600 years. Instead we do other things that serve the same purpose and we call them by the old name. In most cases, it takes a few days for a provably irreversible phase transition to occur in the reputon glass—never mind—and another day after that to make sure you aren’t just being spoofed by ephemeral stochastic nucleation. The point being, I was not granted the access I wanted until recently.” He smiled and a hunk of ice fell off his whiskers and landed on the control panel of his jeejah. “I was going to say ‘until today’ but this damned day never ends.”

“Fine. I don’t really understand anything you said but maybe we can save that for later.”

“That would be good. The point is that I was trying to get information about that rocket launch you glimpsed on the speely.”*

Ah, we have converted a technical problem into a social problem. Historically those are vastly easier to solve, right?

Spam filters exist. Why do we need to bring politics into it? Reminds me of the whole CoC mess a few years back.

Every time somebody talks about a new AI thing the lament here goes:

> BUT THINK OF THE JUNIORS!

How do you expect this system to treat juniors? How do your juniors ever gain experience committing to open source? who vouches for them?

This is a permanent social structure for a transient technical problem.

Fediverse link: https://fosstodon.org/@mitchellh@hachyderm.io/11603152931120...

Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors

I have a hard time trying to poke holes in this. Seems objectively good and like it, or some very similar version of it, will work long term.

Love seeing some nushell usage!

Is this social credit?

I think denouncing is an incredibly bad idea especially as the foundation of VOUCH seems to be web of trust.

If you get denounced on a popular repo and everyone "inherits" that repo as a source of trust (e.g. think email providers - Google decides you are bad, good luck).

Couple with the fact that usually new contributors take some time to find their feet.

I've only been at this game (SWE) for ~10 years so not a long time. But I can tell you my first few contributions were clumsy and perhaps would have earned my a denouncement.

I'm not sure if I would have contributed to the AWS SDK, Sendgrid, Nunit, New Relic (easily my best experience) and my attempted contribution to Npgsql (easily my worst experience) would have definitely earned me a denouncement.

Concept is good, but I would omit the concept of denouncement entirely.

Can't believe they didn't call it VouchDB.

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 particularly interested in vetting new users 3. Updating trust rarely happens

There _is_ a problem with AI Slop overrunning public repositories. But WoT has failed once, we don't need to try it again.

The return of the Web of Trust, I suppose. Interesting that if you look at the way Linux is developed (people have trees that they try to get into the inner circle maintainers who then submit their stuff to Linus's tree) vs. this, it's sort of like path compression in a union-find data structure. Rather than validating a specific piece of code, you validate the person themselves.

Another thing that is amusing is that Sam Altman invented this whole human validation device (Worldcoin) but it can't actually serve a useful purpose here because it's not enough to say you are who you are. You need someone to say you're a worthwhile person to listen to.

Why in nushell? Not in go?

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

I could see this becoming useful to denounce contributors. "This user is malicious, a troll, contributes LLM slop, etc." It could become a distributed block list, discourage some bad behavior I've been seeing on GitHub, assuming the denounce entries are reviewed rather than automatically accepted.

But using this to vouch for others as a way to indicate trust is going to be dangerous. Accounts can be compromised, people make mistakes, and different people have different levels of trust.

I'd like to see more attention placed in verifying released content. That verification should be a combination of code scans for vulnerabilities, detection of a change in capabilities, are reproducible builds of the generated artifacts. That would not only detect bad contributions, but also bad maintainers.

An interesting approach to the worsening signal-to-noise ratio OSS projects are experiencing.

However, it's not hard to envision a future where the exact opposite will be occur: a few key AI tools/models will become specialized and better at coding/testing in various platforms than humans and they will ignore or de-prioritize our input.

I think this project is motivated by the same concern I have that open source (particularly on GitHub) is going to devolve into a slop fest as the barrier of entry lowers due to LLMs. For every principled developer who takes personal responsibility for what they ship, regardless of whether it was LLM-generated, there are people 10 others that don't care and will pollute the public domain with broken, low quality projects. In other words, I foresee open source devolving from a high trust society to a low one.

Why isn't the link directly to the github repository[1]?

[1]: https://github.com/mitchellh/vouch

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 empathy-full.

Reminds me fondly of advogato.

Makes sense, it feels like this just codifies a lot of implicit standards wrt OSS contribution which is great to see. I do wonder if we'll ever see a tangible "reputation" metric used for contribs, or if it'd even be useful at all. Seems like the core tension now is just the ease of pumping out slop vs the responsibility of ownership of code/consideration for project maintainers.

Is this the return of Advogato?

We got social credit on GitHub before GTA 6.

Does is overlap with Contributor License Agreement?

Wait until he finds out about GPG signing parties in the early 2000s.

Another way to solve this is how Linux organizes. Tree structure where lower branches vet patches and forward them up when ready

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

this wouldn't have helped against the xz attack

Fortunately, as long as software is open sourced, forking will remain a viable way to escape overzealous gatekeeping.

> Who and how someone is vouched or denounced is left entirely up to the project integrating the system.

Feels like making a messaging app but "how messages are delivered and to whom is left to the user to implement".

I think "who and how someone is vouched" is like 99.99% of the problem and they haven't tried to solve it so it's hard to see how much value there is here. (And tbh I doubt you really can solve this problem in a way that doesn't suck.)

Doesn't this just shift the same hard problem from code to people? It may seem easier to assess the "quality" of a person, but I think there are all sorts of complex social dynamics at play, plus far more change over time. Leave it to us nerds to try and solve a human problem with a technical solution...

Replacing merit with social signaling.. ..sigh..

The enshitification of GitHub continues

This makes sense for large-scale and widely used projects such as Ghostty.

It also addresses the issue in tolerating unchecked or seemingly plausible slop PRs from outside contributors from ever getting merged in easily. By default, they are all untrusted.

Now this social issue has been made worse by vibe-coded PRs; and untrusted outside contributors should instead earn their access to be 'vouched' by the core maintainers rather than them allowing a wild west of slop PRs.

A great deal.

[dead]

[dead]

Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.

However good (or bad) this idea may be, you are shooting yourself in the foot by announcing it on Twitter. Half the devs I know won’t touch that site with a ten foot pole.

Easy for the koreans to game this.

Who trusts people who still use X?