alt.hn

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.

by andai

Now with AI-generated spam everywhere, maintainers have even more reason to be suspicious of unknown names. Vouch solves their problem, but think about what it means for someone trying to break in. You need someone to vouch for you before you can contribute, but how do you get someone to vouch for you if you can't contribute?

I get why maintainers need this. But we're formalizing a system that makes OSS even more of an insider's club. The cold start problem doesn't really get any warmer like this.

by theredbeard

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

by Halan

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.

by stephantul

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)

by adeebshihadeh

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.

by femto113

I even see people hopping on chat servers begging to 'contribute' just to get github clout. It's really annoying.

by brikym

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.

by freakynit

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.

by 0xbadcafebee

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

by tmvnty

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.

by HiPhish

So is there value in a three state system, rather than a 2 state?

by dncnmcdougall

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.

by kleyd

    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!

I've theorized what a solution would look like, though it'd have a different end goal to ignore bots so true discourse could be achieved. The theorized solution would be less communal though - instead, institutions would be "vouchers" and be provided the ability to confirm individuals as a real person. This could be colleges, workplaces, unions, banks, etc. There'd be no "denouncing", only "vouching" the individual as a real person. The individual's identity would never exposed - social media platforms would use a key, such as an e-mail, to verify the individual's existence as a real person, not their identity. Platforms could identify what rules would qualify an individual's recognized "existence", such as what institutions they allow, minimum number of institutions, etc. In theory, the individual "existence" could be built before they ever register for a platform. This could go way beyond social media platforms too - some examples could be vetting job applications, accepting contributors on OSS projects.

This would create a digital fingerprint of a real individual using their unique identifiers (email, phone number, etc) which may be undesirable, but individuals would absolutely have the ability to revoke their unique identifiers from participating in the program if they desire.

by JimmaDaRustla

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.

by alexjurkiewicz

Key differences: - Based on commit history, with nuance around relatedness of projects, types of projects, age, etc. - Requires no ongoing work. Just add it to your GH Actions CI. - Agent ready with an MCP interface, Python lib, and CLI

Discussion on HN here: https://news.ycombinator.com/item?id=46960412

Feedback and PRs welcome.

by jeffreysmith

Have they shared the lists of developers they want prophylactically blackballed from the community yet?

by tokyobreakfast

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.

by 1a527dd5

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.

by Fnoord

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

by IshKebab

Major congratulations to the creator, you're doing god's work. And even if this particular project struggles or outright fails, I hope that it provides valuable insight for any follow-up web-of-trust projects on how to establish trust online.

by solaire_oa

Assuming the list is under source control, the commit history can answer this question but it's manual work whereas a tree/graph system shows you directly who is making the bad judgement calls (may be intentional or not, so this person can keep contributing so long as those contribs are good, but not invite further people). I don't understand the added value of a bunch of software around what is essentially an allowlist where the commit history already shows why someone was added or removed

¹ https://github.com/mitchellh/vouch?tab=readme-ov-file#vouche...

by Aachen

The contributions I’ve seen from such people in the open source projects I’ve worked on ranged from zero to negative value, and involved unusually large amounts of drama.

I can imagine things are different for some projects. Like maybe debian is trying to upstream a fix?

Even then, can’t they start the PR with a verifiable intro like “I maintain this package for debian.”?

For the other 99% of welcome contributions, intros typically are of the form: “I was hired to work on this by one of the industrial teams that maintain it”

by hedora

“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.”*

by ashton314

Doesn't require money, just computing power.

https://en.wikipedia.org/wiki/Hashcash

If HiveCoin were still around, we could donate the hashing power to some tech-related non-profit.

by WhiteOwlLion

If upstream can’t be bothered to fix such stuff (we’re talking major functionality gaps that a $10-100/month LLM can one-shot), isn’t my extremely well tested fix (typically a few dozen or maybe hundred lines) something they should accept?

The alternative is getting hard forked by an LLM, and having the fork evolve faster / better than upstream.

Telling people like me to f—— off is just going to accelerate irrelevance in situations like this.

by hedora

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.

by arjie

This project though tries to solve a platform policy problem by throwing unnecessary barriers in front of casual but potentially/actually useful contributors.

Furthermore, it creates an "elite-takes-all", self-amplifying hierarchy of domination and rejection of new participants because they don't have enough inside friends and/or social credit points.

Fail. Stop using GH and find a platform that penalizes AI properly at its source.

by burnt-resistor

https://weblog.masukomi.org/2018/03/25/zed-shaws-utu-saving-...

https://savingtheinternetwithhate.com/

DEFCON presentation: https://www.youtube.com/watch?v=ziTMh8ApMY4

by fouc

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.

by bmitch3020

[0]: https://www.youtube.com/watch?v=rPdHXw05SvU

by max_

I think the comparisons to dating apps are quite apt.

Edit: it also assumes contributors can't change opinions, which I suppose is also a dating issue

by cyberrock

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.

by ctoth

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?

by nmstoker

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

by mijoharas

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.

by canada_dry

Maybe something like this could be useful for open source collaboration as well?

*with the notable exception of craigslist

by jcattle

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

by amadeuspagel

But then the actions implementation starts with "pull_request_target" :(

by rcmuir

Problem 2 - getting banned by any single random project for any reason, like CoC disagreement, a heated Rust discussion, any world politics views etc. would lead to a system-wide ban in all involved project. Kinda like getting a ban for a bad YT comment and then your email and files are blocked forever too.

The idea is nice, like many other social improvement ideas. The reality will 99% depend on the actual implementation and actual usage.

by Yizahi

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

by mehdibl

Simple as. He who is without sin can cast the first stone.

by throwaway020826

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.

by mijoharas

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.

by gdiamos

This is perhaps good for massive projects like curl which are tired of AI slop.

by VadimPR

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.

by rvz

The enshitification of GitHub continues

by WhereIsTheTruth