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 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 token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
Crypto has a perfect way to burn money, just send it to a nonexistent address from where it can never be recovered. I guess the trad fi equivalent are charitable donations.
The real problem here is the amount of work necessary to make this viable. I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals, not to mention all the potential contributors that have no access to Visa/MC (we do want to encourage the youth to become involved with Open Source). This basically means crypto, and crypto has its own set of problems, particularly around all the annoying KYC/AML that a normie has to get through to use it.
You can reduce the transactions with payment providers. Instead of money exchanging from contributor to maintainer, have a token exchange. Contributors fund tokens with real money, and pull requests cost and refund tokens. Like an escrow account. But the money never goes to the target system. There are no perverse incentives to steal tokens. If you get a reputation of not refunding tokens (which have no value to a maintainer), then contributors will dry up.
Probably just making it non refundable works almost as well (since time really is expended reading it), without the hassle of spinning up an intermediary layer blockchain.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
Plenty of businesses do the “your credit card will be charged $1 and then reversed” as a verification method that I don’t think it would be a major issue. I do wonder how much those companies are paying for that, though… I am guessing they lose some of that $1.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
…you might be right, but I do wonder if the situation would be different if “your business” was “Microsoft”. Obviously they would discuss this plan ahead of time.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
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.
> No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
Isn't this problem unrelated to cryptocurrency?
There will be the US dollar, and the people involved will be incentivized to keep its value high, e.g. by pressuring or invading other countries to prevent them from switching to other currencies. Or they'll be incentivized to adopt policies that cause consumer and government debt to become unreasonably excessive to create a large enough pool of debts denominated in that currency that they can create an inordinate amount of it without crashing its value.
Or on the other side of the coin, there will be countries with currencies they knowingly devalue, either because they can force the people in that country to accept them anyway or because devaluing their currency makes their exports more competitive and simultaneously allows them to spend the currency they printed.
If anything cryptocurrency could hypothetically be better at reducing these perverse incentives, because if good rules are chosen at the outset and get ossified into the protocol then it's harder for bad actors to corrupt something that requires broad consensus to change.
Sure, but your average developer doesn't have a lot of agency in if the US invades another country in order to increase the value of the coin they got for having a PR merged.
But with crypto they do. See for example all the BAGS coins that get created for random opensource projects and the behavior that occurs because of that.
Just use a stablecoin, don't float a "utility token" those things are stupid. Have a smart contract receive a USDC deposit. If the maintainer "times out" reviewing your PR, the contract returns all the deposit. If the maintainer does not accept your PR, the contract burns 0.5x of the deposit and returns the rest. Maintainers can decide to turn off the time-out for very popular projects where you probably would have devs trying to spam PRs for fame/recognition, but hopefully the deposit price can accurately reflect the amount of spam the project gets.
Utility tokens are fundamentally equities and you need to firewall equity from an organization the same way companies in most market economies are regulated.
The average developer also doesn't have a lot of agency with respect to how major chains like Ethereum are run either, but they can use them.
Creating your own chain just because you can rather than because you actually have a reason to implement the technology in a different way than anybody else should be disfavored and viewed with suspicion.
It's a huge shame that crypto has been so poorly-behaved as an industry that almost nobody is willing to touch it except for speculation. It could be useful but it's scared away most of the honest people.
The fact that people around the world are trading hundreds of billions of dollars of stable coins [1], with India, Pakistan, the Philippines and Brazil in the top five countries [2], not least of all for the purpose of "greater monetary stability" [3], I think points toward the revolutionary usefulness of its inherently non-speculative properties (as referenced in positive applications of crypto in above comments).
It really has been a shitshow of get rich schemes, and yet crypto keeps not dying, instead increasingly getting applied to extremely valuable real world every day use cases, which I think is evidence of the value of the inherent technology.
My point is that despite the incredible greed and desperation it not only doesn't die, its practical uses are growing. The numbers say that the actual value exceeds the grift.
"It's made me realize that the love of money corrupts".
Yep. How about $1 per PR. The submitter gets to choose from a list of charities. No refund if the PR is accepted.
The goal is to get rid of junk PR's. This would work. There could be a central payment system, which any open source project can integrate with. It could accept payment in say India, of the Indian PPP of $1, so you aren't shutting out poorer developers.
I would not pay any amount of money, even a trivial one, for the privilege of being able to do free work for a project - and I don't think I'm an outlier here.
Another way to think of it is: paying $1 to have your pr and concerns elevated above the supermajority sea (that which will be ai driven contributions). For that cost, it's a steal of the deal.
Then, from the perspective of "it's a donation to a project you care about" it becomes even more rational. But the project itself getting the money has all the problems others have outlined already, so that idea's a bit bust.
But I'm already donating my time by creating a PR, it definitely would disincentivize me to make PRs if I had to also pay in addition to already doing the actual work. Just always such a shame that the good people have to suffer because of the actions of the shitty people...
If that's actually the opinion of the maintainer, why even accept PRs at all? At that point, just categorically deny any. I was thinking more of actual community projects that _want_ community PRs. Those seem to have welcomed my contributions in the past, but of course they were not just AI slop or other low effort PRs.
Most of my PRs are drive-by PRs: I have an problem, maybe a bug or missing feature, that annoyed me enough to fix it. And because I want to use future versions without the work of maintaining a fork I instead invest the work to upstream the fix. A step that is sometimes more work than the fix itself. At that point I wouldn't mind paying $1 to get that PR looked at and merged.
But that is not the only type of PR. We clearly need escape hatches for people who engage with a project on a deeper level.
I think the core insight here is about incentives and friction, not crypto specifically.
I’m working on an open source CLI that experiments with this at a local, off-chain level. It lets maintainers introduce cost, review pressure, or reputation at submission time without tying anything to money or blockchains. The goal is to reduce low-quality contributions without financializing the workflow or creating new attack surfaces.
You don’t need a third party, or anybodies permission, nobody can censor you or block your transactions, you don’t need a bank account with everything that entails. The barrier of entry is the same as creating an SSH keypair. It works globally, fast, cheap. You do not need to trust anybody, all the code is open and the ledger is cryptographically verifiable by anyone. There are lots of advantages.
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.
The technical side of this seems easy enough. The human side, that seems more complicated.
Like, if I were your doctor or contractor or kid's schoolteacher or whoever you hadn't happened to already whitelist, and had sent you something important for you, and got that back as a response... I'm sure as heck not paying when I'm trying to send you something for your benefit.
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.
Bill Gates already had this idea. All efforts to change email were already documented 25 years ago. The biggest changes are it is more centralized these days, SPF/DKIM/DMARC, JMAP innovation, oh... and one more thing! It is HUGE!! HTML email is the default...
And it would even still work for the CEO, they would just have to charge more than $1.
The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
> The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
>First you have to make it low-friction. If I want Joe Average to send me $1 in cryptocurrency, how is he getting $1 in cryptocurrency to send me?
Absolutely. You're 1000% correct. Cryptocurrency is way too high friction for stuff like that. When I wish to spend crypto, I need to:
[If you don't have an exchange account already, you'll need the 0.x steps too!]
0.0 Create an account on an exchange which is legally allowed to operate in your state/country;
0.1 Provide all sorts of KYC/AML info including photos of yourself and your government ID;
0.2 Wait hours/days/weeks for the exchange to "validate" your KYC/AML info and allow you to purchase crypto;
1. Log in to an exchange which is actually allowed to operate in the place where one resides;
2. Purchase Bitcoin or other coin the exchange deems appropriate (leaving aside the hefty fee charged for using fiat currency/traditional credit card);
3. Wait days/weeks until the exchange allows you to transfer the purchased cryptocurrency out of your exchange-hosted wallet;
4. Transfer crypto to a wallet you actually control;
5. Convert the crypto purchased on the exchange to the crypto coin required for whatever your purpose may be;
6. Transmit the crypto to the destination wallet.
Total time (not including setting up the exchange account, which can take anywhere from 1-10 days): 3-10 days.
All the setup is no worse than setting up a bank account
And technically it can be avoided through back channels if you know someone who already has it - can just pay them cash or whatever and they can send crypto to you
Crypto is very easy to transfer once you have a wallet
Its the exchange to/from real world currency where the friction is.
> All the setup is no worse than setting up a bank account
Which is a huge pain in the butt. If someone invented a new lower-spam email ecosystem that required everyone to make a new bank account, very few people would join.
I would say something about a combined account but many countries have already figured out free bank transfers without needing crypto so maybe do that?
People with very little to no skill in software development are spending hundreds of dollars on tokens to fix things for clout, will an extra dollar barrier really slow things down noticeably?
> But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
But a non-zero cost of communication can obviously also have negative effects. It's interesting to think about where the sweet spot would be. But it's probably very context specific. I'm okay with close people engaging in "low quality" communication with me. I'd love, on the other hand, if politicians would stop communicating via Twitter.
The idea is that sustained and recurring communication would have a cost that quickly drops to zero. But establishing a new line of communication would have a slight cost, but which would quickly drop to zero.
A poorly thought out hypothetical, just to illustrate: Make a connection at a dinner party? Sure, technically it costs 10¢ make that initial text message/phone call, then the next 5 messages are 1¢ each, but thereafter all the messages are free. Existing relationships: free. New relationships, extremely cheap. Spamming at scale: more expensive.
I have no idea if that's a good idea or not, but I think that's an ok representation of the idea.
Haha yea, I almost didn't post my comment since the original submission is about contributors where a one time "introduction fee" would solve these problems.
I was specifically thinking about general communication. Comparing the quality of communication in physical letters (from a time when that was the only affordable way to communicate) to messages we send each other nowadays.
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.
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.
This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit.
No comment on making PRs paid, not everyone would react well to that, and some people might be in countries and circumstances where any amount would be problematic.
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
Or just don't refund it. Most people want to make contributions to open source, and everyone can afford $1. Exceptions can be made for very active contributors.
In fact, we can use an automated schedule: first PR - if rejected, 5€ are drawn from the contributor’s account, then 4€, 3€, etc (plug in your favourite decreasing function, round to 0€ when sufficiently close).
But, crucially, if accepted, the contributor gets to draw 5€ from the repository’s fund of failed PRs (if it is there), so that first bona fide contributors are incentiviced to contribute. Nobody gets to profit from failed PRs except successful new contributors. Virtuous cycle, does not appeal to the individual self-interest of repo maintainers.
One thing I am unsure of is whether fly-by AI contributions are typically made with for-free AI or there's already a hidden cost to them. This expected cost of machine-driven contribution is a factor to take into account when coming up with the upside/downside of first PR.
PS. this is a Gedankenexperiment, I am not sure what introducing monetary rewards / penalties would do to the social dynamics, but trying with small amounts may teach us something.
Well that's awfully assumptuous. So now a young college kid needs to spend time and money to be able to help out a project? I also don't like that this model inentivizes a few big PR's over small, lean, readable ones.
We're completely mixing up the incentives here anyway. We need better moderation and a cost to the account, not to each ccontribution. SomethingAwful had a great system for this 20 years ago; make it cost $10-30 to be an external contributor and report people who make slop/consistently bad PR's. They get reviewed and lose their contributor status, or even their entire account.
Sure, you can whip up another account, but you can't whip the reputation back up. That's how you make sure seasoned accounts are trustworthy and keep accounts honest.
$1 might not be a lot to you, but in some countries that's the daily wage. Even in rich countries one dollar for some might be the difference between eating or not eating that day.
Paywalling without any regional pricing consideration it's just going to incentivize people from poor countries to not participate in your project. Maybe that's okay for you but it's something to consider.
You're right, I'm fortunate enough to not have this experience. But not only both food and gas are much more than 1€, but also people in this situation are too focused on finding a way to make money to care about submitting merge requests
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%.
Indian here. You are correct. Expecting any employed Indian software developer to not be able to spare 1$ is stupid. Like how exactly poor do you think we are?!
You misunderstood the point. The point isn't that you are poor. The point is that the burden of the money lies on average heavier on you than someone from USA. This creates an uneven playing field.
I like to compare it with donations. If you get a USD donated, that is the same USD regardless of who gave it. Right? Right?!? Either way you don't know how heavy the burden is on the person who donated. You probably don't care. But it matters to the person who donated.
I think the point was that if an aspirational minimum wage worker on a borrowed computer wants to put up a PR then it would cost them less than ten minutes of wages to afford $1USD in the US, while the same worker in India would need to put up about half a day's wages.
This is very noble in theory, but in practice you're not going to get many high-quality PRs from someone who's never been paid to write software and has no financial support.
so we continue to make the rich richer and the broke students struggle more to get valuable experience. Very easy to point in 10-20 years under the coming "engineer crisis" why 'suddenly' can't support the systems we built.
Students don't have a lot of money to burn here. They're borrowing money to study. You'll miss out on them. However, you're unlikely to notice. I mean, there is no control group in such experiment.
I think the open source ecosystem would definitely notice long-term. Most people who become regular contributors start out in university or earlier - that's wen you have the most time to spend on hobbies like oss.
>contributing to an open source project that you're likely already benefiting from.
Yes, but many people benefit for free. You see the backwards incentives of making the most interested (i.e. the ones who may provide the most work to your project) pay?
And none of that even guarantee support. Meanwhile you donate more and you get to tell people what the build. It's all out of what.
4. Do not refund + Auto-send discouragement response.
5. Do not refund + Block.
6. Do not refund + Block + Report SPAM (Boom!)
And typically use $1 fee, to discourage spam.
And $10 fee, for important, open, but high frequency addresses, as that covers the cost of reviewing high throughput email, so useful email did get identified and reviewed. (With the low quality communication subsidizing the high quality communication.)
The latter would be very useful in enabling in-demand contact doors to remain completely open, without being overwhelmed. Think of a CEO or other well known person, who does want an open channel of feedback from anyone, ideally, but is going to have to have someone vet feedback for the most impactful comments, and summarize any important trend in the rest. $10 strongly disincentives low quality communication, and covers the cost of getting value out of communication (for everyone).
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.
OSS was already brutal for new contributors before AI. You'd spend hours on a good-faith PR and get ignored for months, or get torn apart in review because you didn't know the unwritten conventions. The signal-to-noise ratio sucked but at least maintainers would eventually look at your stuff.
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.
Good filters make good communities. Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith. As the barrier to entry to the internet writ large dropped to near zero, communities that were built around the bygone era's natural filtering suffered. Communities must now establish filters proactively.
Ultimately, you need to choose: does your community prioritize its short-term health, or ease of access? If a community never lets anyone in, then it withers and dies eventually, but in the meantime the community can be extremely high-trust. That's what happened to fraternal orders like the Oddfellows and the Free Masons post-Vietnam. If the community has zero barrier to entry, you end up with Twitter: a teeming mass of low-trust members screaming into the void.
The happy medium is allowing in new members just as fast as you can build trust and community cohesion. University clubs are a good example of this: at a massive turnover rate of 25% per year, they need to form processes to not just recruit that many people, but integrate that big of a chunk of their community without destroying the high-trust environment. That's how you end up with the ritualized "rushing" process.
>Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith
And it was horrifically expensive to be online until the mid 90s, or late 90s depending on where you were.
This makes sense to me. Part of me wonders if this system wouldn't work better in reverse, a blocklist instead of a banlist. Blocklists can spread via URL, in the same way that DNS or email blocklists work. Subscribe to the blocklists of people you trust.
I _think_ this removes the motivation for low-quality PRs. Get on a major blocklist and the GitHub account is basically dead. People could make new GitHub accounts, but then you never get an "impressive" GitHub account.
The comment I read about this that I liked was that they want to push the idea of starting with an Issue and a discussion before going straight to a PR. That way you can build reputation by contributing to a discussion first. Maybe you could "earn" a temporary Vouch like this that lets you start submitting. Still open to attack but the attack is at least more difficult.
Maybe it is because I mostly contribute to projects that have corporate backers but this has not been my experience at all. Usually opening an issue with “I would be willing to fix this” gets good and quick responses from maintainers. Maybe linux kernel devs are different but I doubt many of us have to interact with that as part of our day-to-day business.
Building projects, especially larger ones, has not been solely about writing code. I don't see how anything you are saying is a bad thing at all. Drive-by PRs and similar practices are bad. A high barrier is a feature, not a bug.
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.
In my OSS projects I appreciate if someone opens an issue or discussion with their idea first rather than starting with a PR. PRs often put me in an awkward position of saying "this code works, but doesn't align with other directions I'm taking this project" (e.g. API design, or a change making it harder to reach longer term goals)
He answered it in the thread: Basically, the system has no opinion on that, but in his projects he will vouch anyone who introduces themselves like a normal human being when opening a PR.
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.
The patches are not malicious, but the submitters are unable to explain them. We require submitting a non-trivial patch in order for someone to be considered for a FOSS internship. As there is money involved, this attracts scammers now more than ever.
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.
Looking at this, it looks like it's intended to handle that by only denying certain code paths.
Think denying access to production. But allowing changes to staging. Prove yourself in the lower environments (other repos, unlocked code paths) in order to get access to higher envs.
It seems like it depends on how the authors have configured Vouch. They might completely close the project except to those on the vouch list (other than viewing the repo, which seems always implied).
Alternatively they might keep some things open (issues, discussions) while requiring a vouch for PRs. Then, if folks want to get vouched, they can ask for that in discussions. Or maybe you need to ask via email. Or contact maintainers via Discord. It could be anything. Linux isn't developed on GitHub, so how do you submit changes there? Well you do so by following the norms and channels which the project makes visible. Same with Vouch.
Honestly, the entire process of open-source contribution is broken. People should just fork and compete on the free 'market'. If you have a good idea / PR, just keep patchsets. People should mix and match the patch sets as they like. Maintainers who want to keep their version active will be forced to merge proper patch sets. The key argument against this is the difficulty integrating patch sets.
This should be easier with AI. Most LLMs are pretty good at integrating existing code.
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.
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.
Good reason to be careful. Maybe there's a bit of an upside to: if you vouch for someone who does good work, then you get a little boost too. It's how personal relationships work anyway.
----------
I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good use case of blockchain tech…
> I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good use case of blockchain tech…
So the really funny thing here is the first bitcoin exchange had a Web of Trust system, and while it had it's flaws IT WORKED PRETTY WELL. It used GPG and later on bitcoin signatures. Nobody talks about it unless they were there but the system is still online. Keep in mind, this was used before centralized exchanges and regulation. It did not use a blockchain to store ratings.
As a new trader, you basically could not do trades in their OTC channel without going through traders that specialized in new people coming in. Sock accounts could rate each other, but when you checked to see if one of those scammers were trustworthy, they would have no level-2 trust since none of the regular traders had positive ratings of them.
A 100% useful heuristic for "is blockchain useful here" is to understand that blockchains can be completely replaced, at much lower cost, with a database hosted by a trusted party.
If there is literally anyone that can be (or at least must be) trusted by all potential users of a system, then it's better to just use a database controlled by that person/entity. That's why blockchain-based solutions never pan out when it comes to interacting with the real world: In real life, there is a ton of trust required to do anything.
If we want to make it extremely complex, wasteful, and unusable for 99% of people, then sure, put it on the blockchain. Then we can write tooling and agents in Rust with sandboxes created via Nix to have LLMs maintain the web of trust by writing Haskell and OCaml.
I don't think that trust is easily transferable between projects, and tracking "karma" or "reputation" as a simple number in this file would be technically easy. But how much should the "karma" value change form different actions? It's really hard to formalize efficiently. The web of trust, with all intricacies, in small communities fits well into participants' heads. This tool is definitely for reasonably small "core" communities handling a larger stream of drive-by / infrequent contributors.
> I don't think that trust is easily transferable between projects
Not easily, but I could imagine a project deciding to trust (to some degree) people vouched for by another project whose judgement they trust. Or, conversely, denouncing those endorsed by a project whose judgement they don't trust.
In general, it seems like a web of trust could cross projects in various ways.
Ethos is already building something similar, but starting with a focus on reputation within the crypto ecosystem (which I think most can agree is an understandable place to begin)
I'm unconvinced, to my possibly-undercaffeinated mind, the string of 3 posts reads like this:
- a problem already solved in TFA (you vouching for someone eventually denounced doesn't prevent you from being denounced, you can totally do it)
- a per-repo, or worse, global, blockchain to solve incrementing and decrementing integers (vouch vs. denounce)
- a lack of understanding that automated global scoring systems are an abuse vector and something people will avoid. (c.f. Black Mirror and social credit scores in China)
That is an easy way to game the whole system. Create a bunch of accounts and repos, cross vouch across all of them, generate a bunch of fake AI PRs and approve them all because none of the repos are real anyway. Then all you need is to find a way to connect your web of trust to a wider web of trust and you have a whole army of vouched sock puppet accounts.
Think Epstein but in code. Everyone would vouch for him as he’s hyper connected. So he’d get a free pass all the way. Until all blows in our faces and all that vouched for him now gets flagged. The main issue is that can take 10-20 years for it to blow up.
Then you have introverts that can be good but have no connections and won’t be able to get in.
So you’re kind of selecting for connected and good people.
Excellent point. Currently HN accounts get much higher scores if they contribute content, than if they make valuable comments. Those should be two separate scores. Instead, accounts with really good advice have lower scores than accounts that have just automated re-posting of content from elsewhere to HN.
Fair (and you’re basically describing the xz hack; vouching is done for online identities and not the people behind them).
Even with that risk I think a reputation based WoT is preferable to most alternatives. Put another way: in the current Wild West, there’s no way to identify, or track, or impose opportunity costs on transacting with (committing or using commits by) “Epstein but in code”.
But the blowback is still there. The Epstein saga has and will continue to fragment and discipline the elite. Most people probably do genuinely regret associating with him. Noam Chomsky's credibility and legacy is permanently marred, for example.
> 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 a graph search. If the person you’re evaluating vouches for people those you vouch for denounce, then even if they aren’t denounced per se, you have gained information about how trustworthy you would find that person. (Same in reverse. If they vouch for people who your vouchers vouch for, that indirectly suggests trust even if they aren’t directly vouched for.)
I've been thinking in a similar space lately, about how a "parallel web" could look like.
One of my (admittedly half baked) ideas was a vouching similar with real world or physical incentives. Basically signing up requires someone vouching, similar to this one where there is actual physical interaction between the two. But I want to take it even further -- when you signup your real life details are "escrowed" in the system (somehow), and when you do something bad enough for a permaban+, you will get doxxed.
"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.
Cool to see you here on HN! I just discovered the openpilot repository a few days ago and am having a great time digging through the codebase to learn how it all works. Msgq/cereal, Params, visionipc, the whole log message system in general. Some very interesting stuff in there.
trust resudes the verification I suppose. Getting a PR from a trusted contributor would probably have me do a quick scan for obvious mistakes. And they'd know to keep the PR's small and on the right branch to help facilitate a scan.
a new person with a big idea on the slightly wrong (but reasonable) channel would have more work in verification.
Why? I don't appreciate comments that cast doubt on decent technical contributors without any substance to back it up. It's a cheap shot from anonymity.
Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos
What kind of things would you like to hear? The default is you hear nothing. Most black boxes work this way. And you similarly have no say in the matter.
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 money by making their open source version AGPL), due to similar viral dynamics discouraging potential contributors.
“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.
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.
If you zoom out the graph all the way you'll see that it's a decline for the past year. The slight uptick in the past 1-2 months can probably be attributed to other factors (eg. ICE protests riling the left up) than "[filter bubble] is how bluesky grows".
The project author has the choice of which set of projects vouches to use or to have a project-specific vouching system. People could still object to the vouch system via Issue/Pull-request Tool and off platform. Enough votes would highlight it.
>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.
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.
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.
> 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.
> 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?
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.
That's the most difficult part oftentimes. People are busy and trying to join these conversations as someone green is hard unless you already have specifically domain knowledge to seek (which requires either a job doing that specific stuff or other FOSS contributions to point to).
I think this fear is overblown. What Vouch protects against is ultimately up to the downstream but generally its simply gated access to participate at all. It doesn't give you the right to push code or anything; normal review processes exist after. It's just gating the privilege to even request a code review.
And then they become distrusted and BOOM trust goes away from every project that subscribed to the same source.
Think of this like a spam filter, not a "I met this person live and we signed each other's PGP keys" -level of trust.
It's not there to prevent long-con supply chain attacks by state level actors, it's there to keep Mr Slopinator 9000 from creating thousands of overly verbose useless pull requests on projects.
Thing is, this system isn't supposed to be perfect. It is supposed to be better, while worth the hassle.
I doubt I'll get vouched anywhere (tho IMO it depends on context), but I firmly believe humanity (including me) will benefit from this system. And if you aren't a bad actor with bad intentions, I believe you will, too.
Only side effect is genuine contributors who aren't popular / in the know need to put in a little bit more effort. But again, that is part of worth the hassle. I'll take it for granted.
It's just an example of what you can do, not a global feature that will be mandatory. If I trust someone on one of my projects, why wouldn't I want to trust them on others?
> 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.
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.
It is never wrong to be considered untrusted. It is only occasionally right to be considered trusted. Especially in zero-risk relationships that is the default on the anonymous internet.
This makes a lot more sense for large scale and high profile projects, and it eliminates low quality slop PRs by default with the contributors having to earn the trust of the core maintainers to contribute directly to the project.
I think there are better alternatives, we'll let the market weed things out
For example, I will keep making them spin wheels and burn tokens / money, a sort of honeypot, adversarial shadowban. This is even better for disincentivizing them.
We can see this effect from Mitchell's own release of his terminal emulator (Ghostty). It was invite-only. The in-crowd on YouTube/Twitter lorded it over others as a status symbol. None of it was based on actual engineering prowess. It was more like, "hey, you speak at conferences and people follow you on social media... you must be amazing".
They're negative sum, but even negative sum systems usually have many winners (so it 'works' for some subset of individuals). That's why it perpetuates.
Yeah, these solutions are always made to try and disract from the fact that you need real, admin-level moderation and enfoecement to build trustworthy users and communities. a rogue actor should be afraid of losing their account if they submit slop. But instead all this is outsourced on the community to try and circumnavigate.
Community level enforcement is unfortunately a game of cat and mouse. except the mouse commands an army and you can only catch one mouse per repo. The most effective solution is obviously to ban the commander, but you'll never reach it as a user.
The underlying idea is admirable, but in practice this could create a market for high-reputation accounts that people buy or trade at a premium.
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.
That's fine? I mean, this is how the world works in general. Your friend X recommends Y. If Y turns out to suck, you stop listening to recommendations from X. If Y happens to be spam or malware, maybe you unfriend X or revoke all of his/her endorsements.
It's not a perfect solution, but it is a solution that evolves towards a high-trust network because there is a traceable mechanism that excludes abusers.
That's true. And this is also actually how the global routing of internet works (BGP protocol).
My comment was just to highlight possible set of issues. Hardly any system is perfect. But it's important to understand where the flaws lie so we are more careful about how we go about using it.
The BGP for example, a system that makes entire internet work, also suffers from similar issues.
Amazing idea - absolutely loving vouch.
However, as a security person, this comment immediately caught my attention.
A few things come to mind (it's late here, so apologies in advance if they're trivial and not thought through):
- Threat Actors compromising an account and use it to Vouch for another account. I have a "hunch" it could fly under the radar, though admittedly I can't see how it would be different from another rogue commit by the compromised account (hence the hunch).
- Threat actors creating fake chains of trust, working the human factor by creating fake personas and inflating stats on Github to create (fake) credibility (like how number of likes on a video can cause other people to like or not, I've noticed I may not like a video if it has a low count which I would've if it had millions - could this be applied here somehow with the threat actor's inflated repo stats?)
- Can I use this to perform a Contribution-DDOS against a specific person?
The idea is sound, and we definitely need something to address the surge in low-effort PRs, especially in the post-LLM era.
Regarding your points:
"Threat Actors compromising an account..." You're spot on. A vouch-based system inevitably puts a huge target on high-reputation accounts. They become high-value assets for account takeovers.
"Threat actors creating fake chains of trust..." This is already prevalent in the crypto landscape... we saw similar dynamics play out recently with OpenClaw. If there is a metric for trust, it will be gamed.
From my experience, you cannot successfully layer a centralized reputation system over a decentralized (open contribution) ecosystem. The reputation mechanism itself needs to be decentralized, evolving, and heuristics-based rather than static.
I actually proposed a similar heuristic approach (on a smaller scale) for the expressjs repo a few months back when they were the first to get hit by mass low-quality PRs: https://gist.github.com/freakynit/c351872e4e8f2d73e3f21c4678... (sorry, couldn;t link to original comment due to some github UI issue.. was not showing me the link)
I belong to a community that uses a chain of trust like this with regards to inviting new people. The process for avoiding the bad actor chain problem is pretty trivial: If someone catches a ban, everyone downstream of them loses access pending review, and everyone upstream of them loses invite permissions, pending review. Typically, some or most of the downstream people end up quickly getting vouched for by existing members of the community, and it tends to be pretty easy to find who messed up with a poorly-vetted invite (most often, it was the person who got banned's inviter). Person with poor judgement loses their invite permissions for a bit, everyone upstream from them gets their invite permissions back.
This is a strange comment because, this is literally the world that we live in now? We just assume that everyone is vouched by someone (perhaps Github/Gitlab). Adding this layer of vouching will basically cull all of that very cheap and meaningless vouches. Now you have to work to earn the trust. And if you lose that trust, you actually lose something.
The difference is that today this trust is local and organic to a specific project. A centralized reputation system shared across many repos turns that into delegated trust... meaning, maintainers start relying on an external signal instead of their own review/intuition. That's a meaningful shift, and it risks reducing scrutiny overall.
I am still not going to merge random code from a supposed trusted invdividual. As it is now, everyone is supposedly trusted enough to be able to contribute code. This vouching system will make me want to spend more time, not less, when contributing.
Trust signals change behavior at scale, even if individuals believe they're immune.
You personally might stay careful, but the whole point of vouching systems
is to reduce review effort in aggregate. If they don't change behavior,
they add complexity without benefi.. and if they do, that's exactly where
supply-chain risk comes from.
I think something people are missing here is, this is a response to the groundswell in vibecoded slop PRs. The point of the vouch system is not to blindly merge code from trusted individuals; it's to completely ignore code from untrusted individuals, permitting you to spend more time reviewing the MRs which remain.
To whom? It's not against Github's ToS to submit a bad PR. Anyway, bad actors can just create new accounts. It makes more sense to circulate whitelists of people who are known not to be bad actors.
I also like the flexibility of a system like this. You don't have to completely refuse contributions from people who aren't whitelisted, but since the general admission queue is much longer and full of slop, it makes sense to give known good actors a shortcut to being given your attention.
I don't think the intent is for trust to be delegated to infinity. It can just be shared easily. I could imagine a web of trust being shared between projects directly working together.
That could happen.. but then it would end up becoming a development model similar to the one followed by sqlite and ffmpeg ... i.e., open for read, but closed(almost?) for writes to external contributions.
I don't know whether that's good or bad for the overall open-source ecosystem.
It seems like dating apps to me. You have a large population of highly motivated undesirables to filter out. I think we'll see the same patterns: pay to play, location filtering, identity verification, social credit score (ELO etc).
I even see people hopping on chat servers begging to 'contribute' just to get github clout. It's really annoying.
> the purpose of the trust metric is to certify that a given user account on Advogato is known by the Advogato community to actually belong to the individual who claims it and is known to be a member of the free software and open source community. The user may be an crank, annoying, or of a political persuasion that you don't agree with. What the trust metric attempts to guarantee is that they really are who they say they are
Sounds like a slightly different goal but certainly an interesting system to look at
It explains how to get vouched. You need to have a person vouch for you after you open an issue with your proposed change. After you are vouched, you may raise a PR.
exactly this, verification should always been on the code
if someone fresh wants to contribute, now they will have to network before they can write code
honestly i don't see my self networking just so that i can push my code
I think there are valid ways to increase the outcome, like open source projects codifying the focus areas during each month, or verifying the PRs, or making PRs show proof of working etc,... many ways to deter folks who don't want to meaningfully contribute and simply ai generate and push the effort down the real contributors
Why are folks seemingly so averse to sending an email / hopping on a channel to actually talk to maintainers before just firing off code? I've been on both sides of this; I have been young and green and just fired off contributions without stopping to think, do they event want this?. Codebases are rarely built primarily out of zillions of shotgunned patches, they are more like a garden that needs tending over time, and the ones that are the best tenders are usually the ones that spend the most amount of time in the garden.
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.
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.
> 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.
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.
To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away.
Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.
I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".
Hatching a reputation-based scheme around a "Contributor Management System" and getting "the people you want as contributors" to go along with it is easier than getting them to fill in a 1/username 2/password 3/confirm-password form? Choosing to believe that is pure motivated reasoning.
> 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.
GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"
I know this is a joke, but pretending for a moment that it isn’t: this would immediately result in the rep system being gamed the same way it is on eBay: scam sellers can purchase feedback on cheap or self-shipping auctions and then pivot into defrauding people on high-dollar sales before being banned, rinse, and repeat.
Let's also see the differences: On github you can always see the interactions. On ebay, once a sale has been made, you have no idea what happens next. On Github you always have all the artifacts of where the reputation comes from.
On auctions, you do not have to provide a payment method to bid. So once you won an auction you still have to pay the agreed price. Only after the buyer paid, does the seller get the shipment address. Depending on the buyer this can take longer or shorter (or won't happen at all).
There are people who bid but then don’t pay if they win the auction. Or take weeks to pay after winning. That’s just a pain for the seller, because they have to spend time trying to get the winner to pay, or else have to put up the auction again (which used to cost some fee each time for the seller, I don’t know how it is now). The only penalty for non-paying winners is the negative feedback they receive.
I don't know how it is where where you live, but here there are two possibilities I can think of:
- When I buy an item I still have to click a "check out" link to enter my address and actually pay for the item. I could take days after buying the item to click that link.
- Some sellers might not accept PayPal, instead after I check out I get the sellers bank information and have to manually wire the money. I could take days after checking out to actually perform the money transfer.
I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
Intrinsically good, but in conflict with some larger, out of band concern that the contributor could have no way to know about? Upvote to take the sting out of rejection, along with a note along the lines of "Well done, and we would merge is it weren't for our commitment to support xxx systems which are not compatible with yyy. Perhaps refactor as a plugin?"
Also, upvotes and merge decisions may well come from different people, who happen to disagree. This is in fact healthy sometimes.
>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR
Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.
Hi, thank you for putting in the work to share and manage this.
Having read the commands I noted that there are only two options available: vouched and not, with denounced being a harder not vouches.
I was wondering if it would help to separate this into three levels: vouched (positive), not vouched (neutral) and denounced (negative)?
Then a project could allow PRs from 'not vouvhed' contributers, but have the option of denouncing them.
This would leave the communities open to new contributions, while giving a way to reject bad actors.
Then vouched users could have extra privileges. Perhaps authority to denounce, or merge. Although those are already gates by contribution rights on the underlying forge.
So is there value in a three state system, rather than a 2 state?
We'll ship some initial changes here next week to provide maintainers the ability to configure PR access as discussed above.
After that ships we'll continue doing a lot of rapid exploration given there's still a lot of ways to improve here. We also just shipped some issues related features here like comment pinning and +1 comment steering [1] to help cut through some noise.
Interested though to see what else emerges like this in the community, I expect we'll see continued experimentation and that's good for OSS.
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.
Inside the repo as metadata that can be consumed by a provider, like GHA config in .github/. Standardized, at least as an extension like git lfs so it's provider independent. Could work! I've long thought effective reputational models are a major missing piece of internet infrastructure, this could be the beginning of their existence given the new asymmetric threat of LLM output, combined with mitchellh's productivity and recognition.
This reminds me of the time that Ripple launched a marketing promotion, giving developers some amount of Ripple to encourage micropayments. They defined "developer" as "someone who has had a GitHub account for 1 year prior to this announcement" to stop folks from creating hundreds of new accounts to claim credits. This essentially created a bounty on existing GitHub accounts and led to thousands of account compromises due to poor password hygiene. GitHub account security is much better now than it was back then (Nov 2013), but this solution similarly puts a bounty on highly-vouched accounts.
I've thought about making such a system before, but never considered making it a single flat file¹. How are you going to identify who keeps inviting these bad actors?
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
I think a system that allows a reason someone is denounced, specifically for political views or support, should be implemented, to block the mob from denouncing someone on all of their projects, simply because they are against certain topics, or in an opposing political party
1. Such a system is already in place (see the `--reason` flag).
2. Being able to denounce people with noxious political views is a feature, not a bug. If someone shows up in your issues complaining about how your CoC is "woke," they're a bad actor stirring up pointless drama. At best, this is just a waste of everyone's time, and at worst they're haranguing your actual contributors who happen to be trans or something. Respectful contributors naturally will not fall afoul of this, regardless of their beliefs or party affiliation or what-have-you.
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!
This is a fun post. I think you're mistaken, though.
Your strongest point is that allowlists exclude new contributors. (You're right about blocklists, but this seems to me like a primarily allowlist-based approach.) Thing is, new contributors are already being excluded by a flood of slop PRs within which they are indistinguishable. Whatever strategy they would currently use to distinguish themselves (reaching out through social channels, volunteering in the issue for an important problem, etc) should still work with vouch. But when it does work and they are vouched for, they will get a reputational shortcut to contribute again in this repo and to contribute in other repos sharing the same vouchlist.
Like any good social solution, `vouch` is trying to codify & extend the existing ad-hoc practices that have arisen to cope with slop PRs (i.e. largely ignoring PRs submitted by strangers). Obviously it's not a full solution, but I'm suspicious of solutions that claim to fully solve a difficult problem. It's a step forward.
This is an excellent step in the direction of a web-of-trust that the present moment demands, facing an increasingly mistrustful web in the face of LLMs.
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.
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.
At a technical level it's straightforward. Repo maintainers maintain their own vouch/denouncelists. Your maintainers are assumed to be good actors who can vouch for new contributors. If your maintainers aren't good actors, that's a whole other problem. From reading the docs, you can delegate vouching to newly vouched users, as well, but this isn't a requirement.
The problem is at the social level. People will not want to maintain their own vouch/denounce lists because they're lazy. Which means if this takes off, there will be centrally maintained vouchlists. Which, if you've been on the internet for any amount of time, you can instantly imagine will lead to the formation of cliques and vouchlist drama.
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.
I think this is the inevitable reality for future FOSS. Github will be degraded, but any real development will be moved behind closed doors and invite only walls.
You can't get perfection. The constraints / stakes are softer with what Mitchell is trying to solve i.e. it's not a big deal if one slips through. That being said, it's not hard to denounce the tree of folks rooted at the original bad actor.
> The interesting failure mode isn’t just “one bad actor slips through”, it’s provenance: if you want to
> “denounce the tree rooted at a bad actor”, you need to record where a vouch came from (maintainer X,
> imported list Y, date, reason), otherwise revocation turns into manual whack-a-mole.
>
> Keeping the file format minimal is good, but I’d want at least optional provenance in the details field
> (or a sidecar) so you can do bulk revocations and audits.
> Indeed, it's relatively impossible without ties to real world identity.
I don't think that's true? The goal of vouch isn't to say "@linus_torvalds is Linus Torvalds" it's to say "@linus_torvalds is a legitimate contributor an not an AI slopper/spammer". It's not vouching for their real world identity, or that they're a good person, or that they'll never add malware to their repositories. It's just vouching for the most basic level of "when this person puts out a PR it's not AI slop".
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 :)
It’s easy to game systems unless you attach real stakes, like your reputation. You can vouch for anyone, but if you consistently back bad actors your reputation should suffer along with everything you endorsed.
The web badly under-uses reputation and cryptographic content signing. A simple web of trust, where people vouch for others and for content using their private keys, would create a durable public record of what you stand behind. We’ve had the tools for decades but so far people decline to use them properly. They don't see the urgency. AI slop creates the urgency and yet everybody is now wringing their hands on what to do. In my view the answer to that has been kind of obvious for a while: we need a reputation based web of trust.
In an era of AI slop and profit-driven bots, the anonymous web is just broken. Speech without reputational risk is essentially noise. If you have no reputation, the only way to build one is by getting others to stake theirs on you. That's actually nothing new. That's historically how you build reputation with family, friends, neighbors, colleagues, etc. If you misbehave, they turn their backs on you. Why should that work differently on the web?
GitHub actually shows how this might work but it's an incomplete solution. It has many of the necessary building blocks though. Public profiles, track records, signed commits, and real artifacts create credibility that is hard to fake except by generating high quality content over a long time. New accounts deserve caution, and old accounts with lots of low-quality (unvouched for) activity deserve skepticism. This is very tough to game.
Stackoverflow is a case study in what not to do here. It got so flooded by reputation hungry people without one that it got super annoying to use. But that might just be a bad implementation of what otherwise wasn't a bad idea.
Other places that could benefit from this are websites. New domains should have rock bottom reputation. And the link graphs of older websites should tell you all you need to know. Social networks can add the social bias: people you trust vouching for stuff. Mastodon would be perfect for this as an open federated network. Unfortunately they seem to be pushing back on the notion that content should be signed for reasons I never understood.
Hint: every software project at every company runs on this sort of ridiculous popularity contest system, the rules of the game are just not publicized.
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 Web of Trust failed for PGP 30 years ago. Why will it work here?
It didn't work for links as reputation for search once "SEO" people started creating link farms. It's worse now. With LLMs, you can create fake identities with plausible backstories.
This idea won't work with anonymity. It's been tried.
I'm not convinced that just because something didn't work 30 years ago, there's no point in revisiting it.
There's likely no perfect solution, only layers and data points. Even if one of the layers only provides a level of trust as high as the most lax person in the network, it's still a signal of something. The internet will continue to evolve and fracture into segments with different requirements IMHO.
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.
I'm guessing denounce is for bad faith behavior, not just low quality contributions. I think it's actually critical to have a way to represent this in a reputation system. It can be abused, but abuse of denouncement is grounds for denouncement, and being denounced by someone who is denounced by trusted people should carry little weight.
I'm pretty sure this project just does the storage model. It's up to communities that use it to determine the semantics and derive reputation and other higher level concepts from the data.
Off topic but why was contributing to Npgsql a bad experience for you? I've contributed, admittedly minor stuff, to that ecosystem and it was pretty smooth.
Denounce also creates liability: you are slandering someone, explicitly harming their reputation and possibly their career.
I'd hesitate to create the denounce function without speaking to an attorney; when someone's reputation and career are torpedoed by the chain reaction you created - with the intent of torpedoing reputations - they may name you in the lawsuit for damages and/or to compel you to undo the 'denounce'.
Not vouching for someone seems safe. No reason to get negative.
What value would this provide without the denouncement feature? The core purpose of the project, from what I can tell, is being able to stop the flood of AI slop coming from particular accounts, and the means to accomplish that is denouncing those accounts. Without denouncement you go from three states (vouched, neutral, denounced) to two (vouched and neutral). You could just make everyone who isn't vouched be put into the same bucket, but that seems counterproductive.
Are there actually open source developers that wander from project to project with one-off contributions that are of significant value? This seems to optimize for that specific scenario, and it’s not something I’ve seen in practice.
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”
You say that as if it’s a bad thing. The bad thing is that to get there we’ll have to go through the bloody revolution to topple the AI that have been put before the humans. That is, unless the machines prevail.
You might think this is science fiction, but the companies that brought you LLMs had the goal to pursue AGI and all its consequences. They failed today, but that has always been the end game.
To play devil’s advocate: We’ve vendored a few open source projects by just asking an LLM to fix obvious bugs that have been open for 12+ months (some projects are abandoned, others active).
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.
I agree with you, but I don't envy the maintainers. The problem is that it's really hard to tell if someone is skilled like you or just shoveling what an LLM wrote up to the maintainers to have them "figure it out." Honestly, getting a library hard forked and maintained by people that can keep up with the incoming PRs would be a relief to a lot of folks...
Oh, to be clear, there’s no way we’d want incoming code for these forks.
Incoming bug reports or design docs an LLM could implement? Sure.
Maybe something like the Linux approach (tree of well-tested, thematic branches from lieutenants) would work better. We’d be happy to be lieutenants that shepherded our forks back to upstream.
> Telling people like me to f—— off is just going to accelerate irrelevance in situations like this.
You have your fork and the fixes, the PR is just kindness on your part. If they don’t want it then just move on with your fork.
I once submitted a PR to some Salesforce helper SDK and the maintainer went on and on about approaches and refactoring etc. I just told him to take it or leave it, I don’t really care. I have my fork and fix already. They eventually merged it but I mean I didn’t care either way, I was just doing something nice for them.
A lot of the discussion is predicated on this as a "solution" to AI contributions, but I'm a little doubtful of the efficacy. It assumes that everyone in "the community" has similar opinions, but for example, while Mr. Torvalds may call current LLMs crap, he also says LLMs are just like any other tool and doesn't see copyright issues. How are you going to weigh Linux-vouched contributors?
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
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.”*
Oh for sure. To be fair, that excerpt I posted is probably the worst in the entire book since Sammann is explaining something using a bunch of ITA ~~jargon~~ bulshytt and it’s meant to be incomprehensible to even the POV character Erasmas.
Xkcd 483 is directly referencing Anathem so that should be unsurprising but I think in both His Dark Materials (e.g. anbaric power) and in Anathem it is in-universe explained. The isomorphism between that world and our world is explicitly relevant to the plot. It’s the obvious foreshadowing for what’s about to happen.
The worlds are similar with different names because they’re parallel universes about to collide.
I wonder how effective that might be as a language-learning tool. Imagine a popular novel in the US market, maybe 80000-100000 words long but whose vocabulary consists of only a few thousand unique words. The first few pages are in English, but as you progress through the book, more and more of the words appear in Chinese or German or whatever the target language is. By the end of the book you are reading the second language, having absorbed it more or less through osmosis.
Someone who reads A Clockwork Orange will unavoidably pick up a few words of vaguely-Russian extraction by the end of it, so maybe it's possible to take advantage of that. The main problem I can see is that the new language's sentence grammar will also have to be blended in, and that won't go as smoothly.
Just a thought: Around the world, most* online classifieds pages have site-wide ways to provide feedback on interactions. Ebay has stars, Germanys Kleinanzeigen has :) :| :( etc etc.
Maybe something like this could be useful for open source collaboration as well?
I had a similar thought, but I think there's a key difference here.
Traditional karma scores, star counts, etc, are mostly just counters. I can see that a bunch of people upvoted, but these days it's very easy for most of those votes to come from bots or spam farms.
The important difference that I see with Vouch is not just that I'm incrementing a counter when I vouch for you, but that I am publicly telling the world "you can trust this person". And if you turn out to be untrustworthy, that will cost me something in a much more meaningful way than if some Github project that I starred turns out to be untrustworthy. If my reputation stands to suffer from being careless in what I vouch for, then I have a stronger incentive to verify your trustworthiness before I vouch for you, AND I have an ongoing incentive to discourage you from abusing the trust you've been given.
The problem is technical: too many low-quality PRs hitting an endpoint. Vouch's solution is social: maintain trust graphs of humans.
But the PRs are increasingly from autonomous agents. Agents don't have reputations. They don't care about denounce lists. They make new accounts.
We solved unwanted automated input for email with technical tools (spam filters, DKIM, rate limiting), not by maintaining curated lists of Trusted Emailers. That's the correct solution category. Vouch is a social answer to a traffic-filtering problem.
This may solve a real problem today, but it's being built as permanent infrastructure, and permanent social gatekeeping outlasts the conditions that justified it.
"Juniors" (or anyone besides maintainers) do not fundamentally have a right to contribute to an open source project. Before this system they could submit a PR, but that doesn't mean anyone would look at it. Once you've internalized that reality, the rest flows from there.
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.
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.
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?
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 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.
The entire point is to add friction. Accepting code into public projects used to be highly frictive. RMS and Linus Torvalds weren't just accepting anyone's code when they developed GNU and Linux; and to even be considered, you had to submit patches in the right way to a mailing list. And you had to write the code yourself!
GitHub and LLMs have reduced the friction to the point where it's overwhelming human reviewers. Removing that friction would be nice if it didn't cause problems of its own. It turns out that friction had some useful benefits, and that's why you're seeing the pendulum swing the other way.
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.
Its a personal project? Do you truly believe that individuals are required to have the foresight into how their project will get adopted or viewed by the community that it would require them to create a separate github account to host it under?
Problem 1 - assuming this Vouch tool gains wide adoption without major fuckups, I predict that a lot of people would "outsource" their own vetting to it, and it would become a circular system where newcomer would not be able to get vouched because everyone will expect others to do it.
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.
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.
Mitchell has really enjoyed Nu essentially. If it is implemented in a shell script, it probably also means that general shell tooling can work with the format.
I don't see how to apply this to my medium-sized project - this is essentially a whitelist of all contributors, which is the same as a collaborators feature in github. How would an entirely new contributor get a contribution in?
This is perhaps good for massive projects like curl which are tired of AI slop.
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.
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.
I'm sick of the fact that every techno-nerd (including me) can create a new level of abstraction, the integrity of which will be proven with foam at the mouth by other people.
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.
> 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.)
Yeah… this code is entirely just a parser for a file format the author invented. Exact same thing could be done as a csv. Sacrificing confugrability for standardization and all that, but… I don’t see the there, there.
Probably the idea is to eventually have these as some sort of public repo where you can merge files from arbitrary projects together? Or inherit from some well known project’s config?
Agree! Real people are not static sets of characteristics, and without a immutable real-world identity this is even harder. It feels like we've just moved the problem from "evaluate code one time" to "continually evaluate a persona that could change owners"
I've had a similar idea, but too many squirrels out there. I hope this works and can be embraced and extended in a positive manner for the developer community.
This is a signal of failure of GH (Microsoft) to limit AI-based interactions, which is obviously not in their superficial strategic interests to do so.
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.
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.
Can you cite the law that says you may not do this?
There are obvious cases in Europe (well, were if you mean the EU) where there need not be criminal behaviour to maintain a list of people that no landlord in a town will allow into their pubs, for example.
Under the EU’s GDPR, any processing of personal data (name, contact, identifiers, etc.) generally requires a legal basis (e.g., consent, legitimate interest, contractual necessity), clear purpose, minimal data, and appropriate protection. Doing so without a lawful basis is unlawful.
It is not a cookie banner law. The american seems to keep forgetting that it's about personal data, consent, and the ability to take it down. The sharing of said data is particularly restricted.
And of course, this applies to black list, including for fraud.
Regulators have enforced this in practice. For example in the Netherlands, the tax authority was fined for operating a “fraud blacklist” without a statutory basis, i.e., illegal processing under GDPR: https://www.autoriteitpersoonsgegevens.nl/en/current/tax-adm...
The fact is many such lists exist without being punished. Your landlord list for example. That doesn't make it legal, just no shutdown yet.
Because there is no legal basis for it, unless people have committed, again, an illegal act (such as destroying the pub property). Also it's quite difficult to have people accept to be on a black list. And once they are, they can ask for their data to be taken down, which you cannot refuse.
> The american seems to keep forgetting that it's about personal data, consent, and the ability to take it down.
I am European, nice try though.
It is very unclear that this example falls foul of GDPR. On this basis, Git _itself_ fails at that, and no reasonable court will find it to be the case.
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...
> Leave it to us nerds to try and solve a human problem with a technical solution...
Honestly, my view is that this is a technical solution for a cultural problem. Particularly in the last ~10 years, open source has really been pushed into a "corporate dress rehearsal" culture. All communication is expected to be highly professional. Talk to everyone who opens an issue or PR with the respect you would a coworker. Say nothing that might offend anyone anywhere, keep it PG-13. Even Linus had to pull back on his famously virtiolic responses to shitty code in PRs.
Being open and inclusive is great, but bad actors have really exploited this. The proper response to an obviously AI-generated slop PR should be "fuck off", closing the PR, and banning them from the repo. But maintainers are uncomfortable with doing this directly since it violates the corporate dress rehearsal kayfabe, so vouch is a roundabout way of accomplishing this.
What on earth makes you think that denouncing a bot PR with stronger language would deter it? The bot does not and cannot care.
If that worked, then there would be an epidemic of phone scammers or email phishers having epiphanies and changing careers when their victims reply with (well deserved) angry screeds.
I didn't mean the "fuck off" part to be quite verbatim... this ghostty PR[0] is a good example of how this stuff should be handled. Notably: there's no attempt to review or provide feedback--it's instantly recognized as a slop PR--and it's an instant ban from repo.
This is the level of response these PRs deserve. What people shouldn't be doing is treating these as good-faith requests and trying to provide feedback or asking them to refactor, like they're mentoring a junior dev. It'll just fall on deaf ears.
Sure, but that pull request is blatantly unreviewable because of how it bundles dozens of entirely unrelated commits together. Just say that and move on: it only takes a one-line comment and it informs potential contributors about what to avoid if any of them is lurking the repo.
If they immediately make another low-quality PR that's when you ban them because they're clearly behaving like a bad actor. But providing even trivial, boilerplate feedback like that is an easy way of drawing a bright line for contributors: you're not going to review contributions that are blatantly low-quality, and that's why they must refrain from trying to post raw AI slop.
Sounds like we're largely saying the same thing. Open source maintainers should feel empowered to say "nope, this is slop, not reading, bye" and ban you from the repo, without worrying if that seems unprofessional.
If you explicitly say "this is unreviewable junk, kthxbye" there's nothing unprofessional about it. But just blaming "AI slop" runs into the obvious issue that most people may be quite unaware that AI will generate unreviewable junk by default, unless it's being very carefully directed by an expert user.
I disagree. The problem with AI slop is not so much that it's from AI, but that it's pretty much always completely unreadable and unmaintainable code. So just tell the contributor that their work is not up to standard, and if they persist they will get banned from contributing further. It's their job to refactor the contribution so that it's as easy as possible to review, and if AI is not up to the task this will obviously require human effort.
You're giving way too much credit to the people spamming these slop PRs. These are not good faith contributions by people trying to help. They are people trying to get pull requests merged for selfish reasons, whether that's a free shirt or something to put on their resume. Even on the first page of closed ghostty PRs I was able to find some prime slop[0]. It is a huge waste of time for a maintainer to nicely tell people like this they need to refactor. They're not going to listen.
edit; and just to be totally clear this isn't an anti-AI statement. You can still make valid, even good PRs with AI. Mitchell just posted about using AI himself recently[1]. This is about AI making it easy for people to spam low-quality slop in what is essentially a DoS attack on maintainers' attention.
If you can immediately tell "this is just AI slop" that's all the review and "attention" you need; you can close the PR and append a boilerplate message that tells the contributor what to do if they want to turn this into a productive contribution. Whether they're "good faith contributors trying to help" or not is immaterial if this is their first interaction. If they don't get the point and spam the repo again then sure, treat them as bad actors.
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.
it's also going to kill the open web. nobody is going to want to share their ideas or code publicly anymore. with the natural barriers gone, the incentives to share will go to zero. everything will happen behind closed doors.
GitHub has never been a good method of clout chasing. in decades of being in this industry, I've seen < 1% of potential employers care about FLOSS contributions, as long as you have some stuff on your GH.
The origin of the problems with low-quality drive-by requests is github's social nature[0]. AI doesn't help, but it's not the cause.
I've seen my share of zero-effort drive-by "contributions" so people can pad their GH profile, long before AI, on tiny obscure projects I have published there: larger and more prominent projects have always been spammed.
If anything, the AI-enabled flood will force the reckoning that was long time coming.
I feel this is a bit too pessimistic. For example, people can make tutorials that auto-certify in vouch. Or others can write agent skills that share etiquette, which agents must demonstrate usage of before
PRs can be created.
Yes, there's room for deception, but this is mostly about superhuman skills and newcomer ignorance and a new eternal September that we'll surely figure out
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 sense cause they're being invoked ON GITHUB).
So I can choose from github, gitlab or maybe codeberg? What about self-hosters, with project-specific forges? What about the fact that I have an account on multiple forges, that are all me?
This seems to be overly biased toward centralized services, which means it's just serving to further re-enforce Microsoft's dominance.
It's a text string, platform can be anything you want, then use the vouch CLI (or parse it yourself) to do whatever you want. We don't do identity mapping, because cross-forge projects are rare and maintaining that would centralize the system and its not what we're trying to do. The whole thing is explicitly decentralized with tiny, community specific networks that you build up.
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.
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 the cons outway the pros, then doing nothing is better than this.
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.
i believe he is talking about Twitter(X) and not x11. so a political stance from the x.com in the description. i love running x11 too, wayland is still not there yet sadly, still has a few quirks.
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.
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 token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
Crypto has a perfect way to burn money, just send it to a nonexistent address from where it can never be recovered. I guess the trad fi equivalent are charitable donations.
The real problem here is the amount of work necessary to make this viable. I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals, not to mention all the potential contributors that have no access to Visa/MC (we do want to encourage the youth to become involved with Open Source). This basically means crypto, and crypto has its own set of problems, particularly around all the annoying KYC/AML that a normie has to get through to use it.
You can reduce the transactions with payment providers. Instead of money exchanging from contributor to maintainer, have a token exchange. Contributors fund tokens with real money, and pull requests cost and refund tokens. Like an escrow account. But the money never goes to the target system. There are no perverse incentives to steal tokens. If you get a reputation of not refunding tokens (which have no value to a maintainer), then contributors will dry up.
"TrustTokens" or "EscrowTokens"
Probably just making it non refundable works almost as well (since time really is expended reading it), without the hassle of spinning up an intermediary layer blockchain.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
Plenty of businesses do the “your credit card will be charged $1 and then reversed” as a verification method that I don’t think it would be a major issue. I do wonder how much those companies are paying for that, though… I am guessing they lose some of that $1.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
…you might be right, but I do wonder if the situation would be different if “your business” was “Microsoft”. Obviously they would discuss this plan ahead of time.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
https://news.ycombinator.com/item?id=46943416
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
https://news.ycombinator.com/item?id=46938811
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
> because crypto brings money so close to engineering it corrupts good product design.
Amen.
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.
No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
> No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
Isn't this problem unrelated to cryptocurrency?
There will be the US dollar, and the people involved will be incentivized to keep its value high, e.g. by pressuring or invading other countries to prevent them from switching to other currencies. Or they'll be incentivized to adopt policies that cause consumer and government debt to become unreasonably excessive to create a large enough pool of debts denominated in that currency that they can create an inordinate amount of it without crashing its value.
Or on the other side of the coin, there will be countries with currencies they knowingly devalue, either because they can force the people in that country to accept them anyway or because devaluing their currency makes their exports more competitive and simultaneously allows them to spend the currency they printed.
If anything cryptocurrency could hypothetically be better at reducing these perverse incentives, because if good rules are chosen at the outset and get ossified into the protocol then it's harder for bad actors to corrupt something that requires broad consensus to change.
Sure, but your average developer doesn't have a lot of agency in if the US invades another country in order to increase the value of the coin they got for having a PR merged.
But with crypto they do. See for example all the BAGS coins that get created for random opensource projects and the behavior that occurs because of that.
Just use a stablecoin, don't float a "utility token" those things are stupid. Have a smart contract receive a USDC deposit. If the maintainer "times out" reviewing your PR, the contract returns all the deposit. If the maintainer does not accept your PR, the contract burns 0.5x of the deposit and returns the rest. Maintainers can decide to turn off the time-out for very popular projects where you probably would have devs trying to spam PRs for fame/recognition, but hopefully the deposit price can accurately reflect the amount of spam the project gets.
Utility tokens are fundamentally equities and you need to firewall equity from an organization the same way companies in most market economies are regulated.
You don't even need to burn it, just send it to someone other than the developers, like the EFF, so the developers aren't given a perverse incentive.
The average developer also doesn't have a lot of agency with respect to how major chains like Ethereum are run either, but they can use them.
Creating your own chain just because you can rather than because you actually have a reason to implement the technology in a different way than anybody else should be disfavored and viewed with suspicion.
I'm talking about your own coin, not chain.
ERC20 tokens are part of Ethereum (and yes I realise there are also non ETH based tokens and that the gas cost of Eth makes them attractive etc etc)
But it could just be made a stablecoin.
It's a huge shame that crypto has been so poorly-behaved as an industry that almost nobody is willing to touch it except for speculation. It could be useful but it's scared away most of the honest people.
The fact that people around the world are trading hundreds of billions of dollars of stable coins [1], with India, Pakistan, the Philippines and Brazil in the top five countries [2], not least of all for the purpose of "greater monetary stability" [3], I think points toward the revolutionary usefulness of its inherently non-speculative properties (as referenced in positive applications of crypto in above comments).
It really has been a shitshow of get rich schemes, and yet crypto keeps not dying, instead increasingly getting applied to extremely valuable real world every day use cases, which I think is evidence of the value of the inherent technology.
[1]https://defillama.com/stablecoins [2]https://www.trmlabs.com/reports-and-whitepapers/2025-crypto-... [3]https://www.goldmansachs.com/what-we-do/goldman-sachs-global...
The greed has ruined it, and the greed and desperation to get rich at all costs keeps it alive.
My point is that despite the incredible greed and desperation it not only doesn't die, its practical uses are growing. The numbers say that the actual value exceeds the grift.
Ahh, I see now the angle you were coming at it from, my wrong!
"It's made me realize that the love of money corrupts".
Yep. How about $1 per PR. The submitter gets to choose from a list of charities. No refund if the PR is accepted.
The goal is to get rid of junk PR's. This would work. There could be a central payment system, which any open source project can integrate with. It could accept payment in say India, of the Indian PPP of $1, so you aren't shutting out poorer developers.
I would not pay any amount of money, even a trivial one, for the privilege of being able to do free work for a project - and I don't think I'm an outlier here.
Another way to think of it is: paying $1 to have your pr and concerns elevated above the supermajority sea (that which will be ai driven contributions). For that cost, it's a steal of the deal.
Then, from the perspective of "it's a donation to a project you care about" it becomes even more rational. But the project itself getting the money has all the problems others have outlined already, so that idea's a bit bust.
> "it's a donation to a project you care about"
But I'm already donating my time by creating a PR, it definitely would disincentivize me to make PRs if I had to also pay in addition to already doing the actual work. Just always such a shame that the good people have to suffer because of the actions of the shitty people...
Nope. From the POV of the maintainer, you are creating extra, and probably unnecessary, work for them.
If that's actually the opinion of the maintainer, why even accept PRs at all? At that point, just categorically deny any. I was thinking more of actual community projects that _want_ community PRs. Those seem to have welcomed my contributions in the past, but of course they were not just AI slop or other low effort PRs.
Most of my PRs are drive-by PRs: I have an problem, maybe a bug or missing feature, that annoyed me enough to fix it. And because I want to use future versions without the work of maintaining a fork I instead invest the work to upstream the fix. A step that is sometimes more work than the fix itself. At that point I wouldn't mind paying $1 to get that PR looked at and merged.
But that is not the only type of PR. We clearly need escape hatches for people who engage with a project on a deeper level.
I think the core insight here is about incentives and friction, not crypto specifically.
I’m working on an open source CLI that experiments with this at a local, off-chain level. It lets maintainers introduce cost, review pressure, or reputation at submission time without tying anything to money or blockchains. The goal is to reduce low-quality contributions without financializing the workflow or creating new attack surfaces.
I see no advantage with this over real money transfers. At all. Just use some kind of escrow.
You don’t need a third party, or anybodies permission, nobody can censor you or block your transactions, you don’t need a bank account with everything that entails. The barrier of entry is the same as creating an SSH keypair. It works globally, fast, cheap. You do not need to trust anybody, all the code is open and the ledger is cryptographically verifiable by anyone. There are lots of advantages.
No. Just because you can use crypto for something doesn’t mean you should. In fact you almost never should.
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!
Has anyone ever paid you?
The technical side of this seems easy enough. The human side, that seems more complicated.
Like, if I were your doctor or contractor or kid's schoolteacher or whoever you hadn't happened to already whitelist, and had sent you something important for you, and got that back as a response... I'm sure as heck not paying when I'm trying to send you something for your benefit.
Yeah, meanwhile a scammer will actually pay to have a seal of approval.
It's a great way to stop receiving anything that benefits yourself and only start receiving mail which could make the sender way more than $1
> Yeah, meanwhile a scammer will actually pay to have a seal of approval.
No they won't. Especially not automated spam. They'd just get farmed by people creating millions of fake e-mail addresses.
I’m interested in seeing this too. Heh an agent will gladly pay a dollar of their human’s money if they can declare success.
Yes please!
Please do share!
If you want me to read your comment, please pay me $1 first... if I find your comment interesting I might refund.
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.
Bill Gates already had this idea. All efforts to change email were already documented 25 years ago. The biggest changes are it is more centralized these days, SPF/DKIM/DMARC, JMAP innovation, oh... and one more thing! It is HUGE!! HTML email is the default...
Yeah I remember this from "The Road Ahead" which I chanced upon one time in the 90s. I thought it was a silly idea.
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.
Emails to CEOs they do worth.
So only CEOs will get spam, and it's effective for 99.9% of people? I would not describe that as "will not work as desired".
And it would even still work for the CEO, they would just have to charge more than $1.
The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
> The real problem is we don't have a low-friction digital payment system that allows individuals to automate sending payment requests for small amounts of money to each other without requiring everyone to sign up for a merchant account with a financial bureaucracy.
Its called cryptocurrency
First you have to make it low-friction. If I want Joe Average to send me $1 in cryptocurrency, how is he getting $1 in cryptocurrency to send me?
>First you have to make it low-friction. If I want Joe Average to send me $1 in cryptocurrency, how is he getting $1 in cryptocurrency to send me?
Absolutely. You're 1000% correct. Cryptocurrency is way too high friction for stuff like that. When I wish to spend crypto, I need to:
[If you don't have an exchange account already, you'll need the 0.x steps too!]
0.0 Create an account on an exchange which is legally allowed to operate in your state/country;
0.1 Provide all sorts of KYC/AML info including photos of yourself and your government ID;
0.2 Wait hours/days/weeks for the exchange to "validate" your KYC/AML info and allow you to purchase crypto;
1. Log in to an exchange which is actually allowed to operate in the place where one resides;
2. Purchase Bitcoin or other coin the exchange deems appropriate (leaving aside the hefty fee charged for using fiat currency/traditional credit card);
3. Wait days/weeks until the exchange allows you to transfer the purchased cryptocurrency out of your exchange-hosted wallet;
4. Transfer crypto to a wallet you actually control;
5. Convert the crypto purchased on the exchange to the crypto coin required for whatever your purpose may be;
6. Transmit the crypto to the destination wallet.
Total time (not including setting up the exchange account, which can take anywhere from 1-10 days): 3-10 days.
Much too high friction for small payments, IMHO.
All the setup is no worse than setting up a bank account
And technically it can be avoided through back channels if you know someone who already has it - can just pay them cash or whatever and they can send crypto to you
Crypto is very easy to transfer once you have a wallet
Its the exchange to/from real world currency where the friction is.
> All the setup is no worse than setting up a bank account
Which is a huge pain in the butt. If someone invented a new lower-spam email ecosystem that required everyone to make a new bank account, very few people would join.
I would say something about a combined account but many countries have already figured out free bank transfers without needing crypto so maybe do that?
The market currently values your reading of HN comments at $0.
I'm sure astroturfers value it more highly than that.
The only way for you to be sure of that is if you're one.
I'm sure there's literature out there on how much astroturfers are paid.
People with very little to no skill in software development are spending hundreds of dollars on tokens to fix things for clout, will an extra dollar barrier really slow things down noticeably?
There are a lot of _free_ models on opencode.
This means someone with tons of money can spam anyone repo, while the lower income people cannot raise as many PR or speak as much as the filthy rich.
Which is true now as well, but at least the cost is more than zero
The incentives are way off too. Now you have a financial incentive as a maintainter to throw out normally well meaning PR's as "bad".
> But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
But a non-zero cost of communication can obviously also have negative effects. It's interesting to think about where the sweet spot would be. But it's probably very context specific. I'm okay with close people engaging in "low quality" communication with me. I'd love, on the other hand, if politicians would stop communicating via Twitter.
The idea is that sustained and recurring communication would have a cost that quickly drops to zero. But establishing a new line of communication would have a slight cost, but which would quickly drop to zero.
A poorly thought out hypothetical, just to illustrate: Make a connection at a dinner party? Sure, technically it costs 10¢ make that initial text message/phone call, then the next 5 messages are 1¢ each, but thereafter all the messages are free. Existing relationships: free. New relationships, extremely cheap. Spamming at scale: more expensive.
I have no idea if that's a good idea or not, but I think that's an ok representation of the idea.
Haha yea, I almost didn't post my comment since the original submission is about contributors where a one time "introduction fee" would solve these problems.
I was specifically thinking about general communication. Comparing the quality of communication in physical letters (from a time when that was the only affordable way to communicate) to messages we send each other nowadays.
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.
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.
> It should just be $1 to submit PR.
This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit.
No comment on making PRs paid, not everyone would react well to that, and some people might be in countries and circumstances where any amount would be problematic.
pay-to-commit has been discussed in the article linked here
https://news.ycombinator.com/item?id=46938811
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
Or just don't refund it. Most people want to make contributions to open source, and everyone can afford $1. Exceptions can be made for very active contributors.
In fact, we can use an automated schedule: first PR - if rejected, 5€ are drawn from the contributor’s account, then 4€, 3€, etc (plug in your favourite decreasing function, round to 0€ when sufficiently close).
But, crucially, if accepted, the contributor gets to draw 5€ from the repository’s fund of failed PRs (if it is there), so that first bona fide contributors are incentiviced to contribute. Nobody gets to profit from failed PRs except successful new contributors. Virtuous cycle, does not appeal to the individual self-interest of repo maintainers.
One thing I am unsure of is whether fly-by AI contributions are typically made with for-free AI or there's already a hidden cost to them. This expected cost of machine-driven contribution is a factor to take into account when coming up with the upside/downside of first PR.
PS. this is a Gedankenexperiment, I am not sure what introducing monetary rewards / penalties would do to the social dynamics, but trying with small amounts may teach us something.
>everyone can afford $1
Well that's awfully assumptuous. So now a young college kid needs to spend time and money to be able to help out a project? I also don't like that this model inentivizes a few big PR's over small, lean, readable ones.
We're completely mixing up the incentives here anyway. We need better moderation and a cost to the account, not to each ccontribution. SomethingAwful had a great system for this 20 years ago; make it cost $10-30 to be an external contributor and report people who make slop/consistently bad PR's. They get reviewed and lose their contributor status, or even their entire account.
Sure, you can whip up another account, but you can't whip the reputation back up. That's how you make sure seasoned accounts are trustworthy and keep accounts honest.
$1 might not be a lot to you, but in some countries that's the daily wage. Even in rich countries one dollar for some might be the difference between eating or not eating that day.
Paywalling without any regional pricing consideration it's just going to incentivize people from poor countries to not participate in your project. Maybe that's okay for you but it's something to consider.
I don't like this idea but the people unable to afford $1 don't have time to propose PR
Plenty of teens in poorer countries actively devoting a lot of time to practicing programming. $1 is a lot for a PR.
That’s not true—it depends entirely on the country..
I'm glad that you are lucky enough to never have had to choose between filling your gas tank or eating. It's sadly the state many people live in.
You're right, I'm fortunate enough to not have this experience. But not only both food and gas are much more than 1€, but also people in this situation are too focused on finding a way to make money to care about submitting merge requests
But one way to get better at communication is try and error. This solution makes trying much harder, and eventually leads less good communicators.
It's externalisation of cost.
We've seen it everywhere, in communication, in globalised manufacturing, now in code generation.
It takes nothing to throw something out there now; we're at a scale that there's no longer even a cost to personal reputation - everyone does it.
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%.
Indian here. You are correct. Expecting any employed Indian software developer to not be able to spare 1$ is stupid. Like how exactly poor do you think we are?!
It's not that outrageous. Apparently, 90% of India is living on less than $10 per day (https://ourworldindata.org/grapher/share-living-with-less-th...)
I suspect most of these people are not software engineers with a computer?
You misunderstood the point. The point isn't that you are poor. The point is that the burden of the money lies on average heavier on you than someone from USA. This creates an uneven playing field.
I like to compare it with donations. If you get a USD donated, that is the same USD regardless of who gave it. Right? Right?!? Either way you don't know how heavy the burden is on the person who donated. You probably don't care. But it matters to the person who donated.
I think the point was that if an aspirational minimum wage worker on a borrowed computer wants to put up a PR then it would cost them less than ten minutes of wages to afford $1USD in the US, while the same worker in India would need to put up about half a day's wages.
This is very noble in theory, but in practice you're not going to get many high-quality PRs from someone who's never been paid to write software and has no financial support.
so we continue to make the rich richer and the broke students struggle more to get valuable experience. Very easy to point in 10-20 years under the coming "engineer crisis" why 'suddenly' can't support the systems we built.
So only employed software developers are allowed to make PRs?
>Like how exactly poor do you think we are?!
I get laid off and suddenly I'm poor and am weighing optins. And I'm American.
I've contributed almost full time to free software as a student. When I became a professional software developer, suddenly I lost the time to do it.
Students don't have a lot of money to burn here. They're borrowing money to study. You'll miss out on them. However, you're unlikely to notice. I mean, there is no control group in such experiment.
I think the open source ecosystem would definitely notice long-term. Most people who become regular contributors start out in university or earlier - that's wen you have the most time to spend on hobbies like oss.
Not that word, in the context of contributing to an open source project that you're likely already benefiting from.
ie, if you want to contribute code, you must also contribute financially.
>contributing to an open source project that you're likely already benefiting from.
Yes, but many people benefit for free. You see the backwards incentives of making the most interested (i.e. the ones who may provide the most work to your project) pay?
And none of that even guarantee support. Meanwhile you donate more and you get to tell people what the build. It's all out of what.
You get it refunded
The default could should be to refund.
That would make not-refunding culturally crass unless it was warranted.
With manual options for:
0. (Default, refund)
1. (Default refund) + Auto-send discouragement response. (But allow it.)
2. (Default refund) + Block.
3. Do not refund
4. Do not refund + Auto-send discouragement response.
5. Do not refund + Block.
6. Do not refund + Block + Report SPAM (Boom!)
And typically use $1 fee, to discourage spam.
And $10 fee, for important, open, but high frequency addresses, as that covers the cost of reviewing high throughput email, so useful email did get identified and reviewed. (With the low quality communication subsidizing the high quality communication.)
The latter would be very useful in enabling in-demand contact doors to remain completely open, without being overwhelmed. Think of a CEO or other well known person, who does want an open channel of feedback from anyone, ideally, but is going to have to have someone vet feedback for the most impactful comments, and summarize any important trend in the rest. $10 strongly disincentives low quality communication, and covers the cost of getting value out of communication (for everyone).
$10 will be a honeypot for scammers.
I don't think most people are going to pay $10 to get an email through without checking.
Might be worth strongly suggesting a check, at permission time.
But I am sure you are right.
Maybe receivers don't get the money. They just get to burn whoever is sending them email they don't want? A thought anyway.
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.
OSS was already brutal for new contributors before AI. You'd spend hours on a good-faith PR and get ignored for months, or get torn apart in review because you didn't know the unwritten conventions. The signal-to-noise ratio sucked but at least maintainers would eventually look at your stuff.
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.
Good filters make good communities. Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith. As the barrier to entry to the internet writ large dropped to near zero, communities that were built around the bygone era's natural filtering suffered. Communities must now establish filters proactively.
Ultimately, you need to choose: does your community prioritize its short-term health, or ease of access? If a community never lets anyone in, then it withers and dies eventually, but in the meantime the community can be extremely high-trust. That's what happened to fraternal orders like the Oddfellows and the Free Masons post-Vietnam. If the community has zero barrier to entry, you end up with Twitter: a teeming mass of low-trust members screaming into the void.
The happy medium is allowing in new members just as fast as you can build trust and community cohesion. University clubs are a good example of this: at a massive turnover rate of 25% per year, they need to form processes to not just recruit that many people, but integrate that big of a chunk of their community without destroying the high-trust environment. That's how you end up with the ritualized "rushing" process.
>Back in the good ol' days of the internet, access to the internet in of itself was a decent filter: you had to want to be online, you needed to be somewhat technical, or at least willing to grapple with technical problems, and you needed to actively seek out communities online which aligned with your interests, and there was little financial motivation to do so in bad faith
And it was horrifically expensive to be online until the mid 90s, or late 90s depending on where you were.
This makes sense to me. Part of me wonders if this system wouldn't work better in reverse, a blocklist instead of a banlist. Blocklists can spread via URL, in the same way that DNS or email blocklists work. Subscribe to the blocklists of people you trust.
I _think_ this removes the motivation for low-quality PRs. Get on a major blocklist and the GitHub account is basically dead. People could make new GitHub accounts, but then you never get an "impressive" GitHub account.
The comment I read about this that I liked was that they want to push the idea of starting with an Issue and a discussion before going straight to a PR. That way you can build reputation by contributing to a discussion first. Maybe you could "earn" a temporary Vouch like this that lets you start submitting. Still open to attack but the attack is at least more difficult.
Maybe it is because I mostly contribute to projects that have corporate backers but this has not been my experience at all. Usually opening an issue with “I would be willing to fix this” gets good and quick responses from maintainers. Maybe linux kernel devs are different but I doubt many of us have to interact with that as part of our day-to-day business.
Building projects, especially larger ones, has not been solely about writing code. I don't see how anything you are saying is a bad thing at all. Drive-by PRs and similar practices are bad. A high barrier is a feature, not a bug.
let's make it even better: why not set up a donation mechanism to get in the list?
Because I want people to get paid for writing code, not to pay to write code.
my bad, forgot to /s
No worries, the italics did heavy lifting.
What could go wrong?!
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.
In my OSS projects I appreciate if someone opens an issue or discussion with their idea first rather than starting with a PR. PRs often put me in an awkward position of saying "this code works, but doesn't align with other directions I'm taking this project" (e.g. API design, or a change making it harder to reach longer term goals)
He answered it in the thread: Basically, the system has no opinion on that, but in his projects he will vouch anyone who introduces themselves like a normal human being when opening a PR.
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?
The patches are not malicious, but the submitters are unable to explain them. We require submitting a non-trivial patch in order for someone to be considered for a FOSS internship. As there is money involved, this attracts scammers now more than ever.
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.
Looking at this, it looks like it's intended to handle that by only denying certain code paths.
Think denying access to production. But allowing changes to staging. Prove yourself in the lower environments (other repos, unlocked code paths) in order to get access to higher envs.
Hell, we already do this in the ops world.
So basically we are back at tagging stuff as good for first contributors like we have been doing since the dawn of GitHub
It seems like it depends on how the authors have configured Vouch. They might completely close the project except to those on the vouch list (other than viewing the repo, which seems always implied).
Alternatively they might keep some things open (issues, discussions) while requiring a vouch for PRs. Then, if folks want to get vouched, they can ask for that in discussions. Or maybe you need to ask via email. Or contact maintainers via Discord. It could be anything. Linux isn't developed on GitHub, so how do you submit changes there? Well you do so by following the norms and channels which the project makes visible. Same with Vouch.
Honestly, the entire process of open-source contribution is broken. People should just fork and compete on the free 'market'. If you have a good idea / PR, just keep patchsets. People should mix and match the patch sets as they like. Maintainers who want to keep their version active will be forced to merge proper patch sets. The key argument against this is the difficulty integrating patch sets.
This should be easier with AI. Most LLMs are pretty good at integrating existing code.
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.
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.
Good reason to be careful. Maybe there's a bit of an upside to: if you vouch for someone who does good work, then you get a little boost too. It's how personal relationships work anyway.
----------
I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good use case of blockchain tech…
> I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good use case of blockchain tech…
So the really funny thing here is the first bitcoin exchange had a Web of Trust system, and while it had it's flaws IT WORKED PRETTY WELL. It used GPG and later on bitcoin signatures. Nobody talks about it unless they were there but the system is still online. Keep in mind, this was used before centralized exchanges and regulation. It did not use a blockchain to store ratings.
As a new trader, you basically could not do trades in their OTC channel without going through traders that specialized in new people coming in. Sock accounts could rate each other, but when you checked to see if one of those scammers were trustworthy, they would have no level-2 trust since none of the regular traders had positive ratings of them.
Here's a link to the system: https://bitcoin-otc.com/trust.php (on IRC, you would use a bot called gribble to authenticate)
Biggest issue was always the fiat transfers.
A 100% useful heuristic for "is blockchain useful here" is to understand that blockchains can be completely replaced, at much lower cost, with a database hosted by a trusted party.
If there is literally anyone that can be (or at least must be) trusted by all potential users of a system, then it's better to just use a database controlled by that person/entity. That's why blockchain-based solutions never pan out when it comes to interacting with the real world: In real life, there is a ton of trust required to do anything.
If we want to make it extremely complex, wasteful, and unusable for 99% of people, then sure, put it on the blockchain. Then we can write tooling and agents in Rust with sandboxes created via Nix to have LLMs maintain the web of trust by writing Haskell and OCaml.
Well done, you managed to tie Rust, Nix, Haskell and OCaml to "extremely complex, wasteful, and unusable"
Boring Java dev here. Do I just sit this one out?
Zig can fix this, I'm sure.
I don't think that trust is easily transferable between projects, and tracking "karma" or "reputation" as a simple number in this file would be technically easy. But how much should the "karma" value change form different actions? It's really hard to formalize efficiently. The web of trust, with all intricacies, in small communities fits well into participants' heads. This tool is definitely for reasonably small "core" communities handling a larger stream of drive-by / infrequent contributors.
> I don't think that trust is easily transferable between projects
Not easily, but I could imagine a project deciding to trust (to some degree) people vouched for by another project whose judgement they trust. Or, conversely, denouncing those endorsed by a project whose judgement they don't trust.
In general, it seems like a web of trust could cross projects in various ways.
Ethos is already building something similar, but starting with a focus on reputation within the crypto ecosystem (which I think most can agree is an understandable place to begin)
https://www.ethos.network/
I'm confused. Why do I need "reputation within the crypto ecosystem"? If I want to trade it, I use an exchange, like Binance.
Both sides of the equation can be gamed. This has always been the issue with reputation systems.
I'm unconvinced, to my possibly-undercaffeinated mind, the string of 3 posts reads like this:
- a problem already solved in TFA (you vouching for someone eventually denounced doesn't prevent you from being denounced, you can totally do it)
- a per-repo, or worse, global, blockchain to solve incrementing and decrementing integers (vouch vs. denounce)
- a lack of understanding that automated global scoring systems are an abuse vector and something people will avoid. (c.f. Black Mirror and social credit scores in China)
Those are good arguments against. I want to make it clear that I think it’s a possibly interesting idea, but also probably a bad one too! :)
Sounds like a black mirror episode.
isnt that like literally the plot in one of the episodes? where they get a x out of 5 rating that is always visble.
Yes, there is one that is pretty close to this scenario.
Look at ERC-8004
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.
The same as when you vouch for your company to hire someone - because you will benefit from their help.
I think your suggestion is a good one.
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.
Maybe your own vouch score goes up when someone you vouched for contributes to a project?
That is an easy way to game the whole system. Create a bunch of accounts and repos, cross vouch across all of them, generate a bunch of fake AI PRs and approve them all because none of the repos are real anyway. Then all you need is to find a way to connect your web of trust to a wider web of trust and you have a whole army of vouched sock puppet accounts.
Think Epstein but in code. Everyone would vouch for him as he’s hyper connected. So he’d get a free pass all the way. Until all blows in our faces and all that vouched for him now gets flagged. The main issue is that can take 10-20 years for it to blow up.
Then you have introverts that can be good but have no connections and won’t be able to get in.
So you’re kind of selecting for connected and good people.
Excellent point. Currently HN accounts get much higher scores if they contribute content, than if they make valuable comments. Those should be two separate scores. Instead, accounts with really good advice have lower scores than accounts that have just automated re-posting of content from elsewhere to HN.
Fair (and you’re basically describing the xz hack; vouching is done for online identities and not the people behind them).
Even with that risk I think a reputation based WoT is preferable to most alternatives. Put another way: in the current Wild West, there’s no way to identify, or track, or impose opportunity costs on transacting with (committing or using commits by) “Epstein but in code”.
But the blowback is still there. The Epstein saga has and will continue to fragment and discipline the elite. Most people probably do genuinely regret associating with him. Noam Chomsky's credibility and legacy is permanently marred, for example.
> 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 a graph search. If the person you’re evaluating vouches for people those you vouch for denounce, then even if they aren’t denounced per se, you have gained information about how trustworthy you would find that person. (Same in reverse. If they vouch for people who your vouchers vouch for, that indirectly suggests trust even if they aren’t directly vouched for.)
I've been thinking in a similar space lately, about how a "parallel web" could look like.
One of my (admittedly half baked) ideas was a vouching similar with real world or physical incentives. Basically signing up requires someone vouching, similar to this one where there is actual physical interaction between the two. But I want to take it even further -- when you signup your real life details are "escrowed" in the system (somehow), and when you do something bad enough for a permaban+, you will get doxxed.
"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)
Cool to see you here on HN! I just discovered the openpilot repository a few days ago and am having a great time digging through the codebase to learn how it all works. Msgq/cereal, Params, visionipc, the whole log message system in general. Some very interesting stuff in there.
When there's time, you review, when there isn't you trust...
That's the issue here.
Even if I trust you, I still need to review your work before merging it.
Good people still make mistakes.
What is the definition of trust if you still have to verify? How does "trust" differ from "untrust" in that scenario?
trust resudes the verification I suppose. Getting a PR from a trusted contributor would probably have me do a quick scan for obvious mistakes. And they'd know to keep the PR's small and on the right branch to help facilitate a scan.
a new person with a big idea on the slightly wrong (but reasonable) channel would have more work in verification.
What's the rush? Building good things takes time.
deadlines, money, attention. The usual things in industry.
[flagged]
Why? I don't appreciate comments that cast doubt on decent technical contributors without any substance to back it up. It's a cheap shot from anonymity.
I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes.
If you had left it at know you want to reject a PR within a few seconds, that'd be fine.
Although with safety critical systems I'd probably want each contributor to have some experience in the field too.
Sounds like you misunderstood. They didn't say they are merging PRs after a few seconds. Just that the difference between a good one and a bad is often obvious after a few seconds. Edit: typos
Exactly, every PR starts with:
1. What’s the goal of this PR and how does it further our project’s goals?
2. Is this vaguely the correct implementation?
Evaluating those two takes a few seconds. Beyond that, yes it takes a while to review and merge even a few line diff.
I'm not sure there are many ways to interpret "I know whether I want to merge a PR within a few seconds".
Yet I also agree with GP.
"*WANT* to close or *WANT* to merge". Not WILL close or WILL merge.
You look at the PR and you know just by looking at it for a few seconds if it looks off or not.
Looks off -> "Want to close"
Write a polite response and close the issue.
Doesn't look off -> "Want to merge"
If we want to merge it, then of course you look at it more closely. Or label it and move on with the triage.
What kind of things would you like to hear? The default is you hear nothing. Most black boxes work this way. And you similarly have no say in the matter.
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 money by making their open source version AGPL), due to similar viral dynamics discouraging potential contributors.
“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.
>At this point it would make sense to say this is just how Bluesky grows.
>https://bsky.jazco.dev/stats
If you zoom out the graph all the way you'll see that it's a decline for the past year. The slight uptick in the past 1-2 months can probably be attributed to other factors (eg. ICE protests riling the left up) than "[filter bubble] is how bluesky grows".
That’s what I said: it’s technically true but misleading.
The project author has the choice of which set of projects vouches to use or to have a project-specific vouching system. People could still object to the vouch system via Issue/Pull-request Tool and off platform. Enough votes would highlight it.
>What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects?
Perhaps that is the plan?
> as people interested in political effectiveness
Ah, the giant enemy crab shows its weakpoint. This is where the mask cracks.
What does "interested in political effectiveness" mean? Like as opposed to ineffectiveness? Is it like bluesky is really libertarian now or something?
>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.
I've been on Mastodon, in leftist spaces theoretically ideologically aligned with me (I've since drifted more...)
It was horrible. Being on Mastodon was one of the most corrosive, humorless, joyless, anxiety and guilt inducing experiences I've ever had.
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.
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?
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.
That's the most difficult part oftentimes. People are busy and trying to join these conversations as someone green is hard unless you already have specifically domain knowledge to seek (which requires either a job doing that specific stuff or other FOSS contributions to point to).
I think this fear is overblown. What Vouch protects against is ultimately up to the downstream but generally its simply gated access to participate at all. It doesn't give you the right to push code or anything; normal review processes exist after. It's just gating the privilege to even request a code review.
Its just a layer to minimize noise.
Did you experiment with getting an AI to critique incoming PRs, and ignoring ones where it finds clear red flags?
And then they become distrusted and BOOM trust goes away from every project that subscribed to the same source.
Think of this like a spam filter, not a "I met this person live and we signed each other's PGP keys" -level of trust.
It's not there to prevent long-con supply chain attacks by state level actors, it's there to keep Mr Slopinator 9000 from creating thousands of overly verbose useless pull requests on projects.
That is indeed a weakness of Web of Trust.
Thing is, this system isn't supposed to be perfect. It is supposed to be better, while worth the hassle.
I doubt I'll get vouched anywhere (tho IMO it depends on context), but I firmly believe humanity (including me) will benefit from this system. And if you aren't a bad actor with bad intentions, I believe you will, too.
Only side effect is genuine contributors who aren't popular / in the know need to put in a little bit more effort. But again, that is part of worth the hassle. I'll take it for granted.
It's just an example of what you can do, not a global feature that will be mandatory. If I trust someone on one of my projects, why wouldn't I want to trust them on others?
Yeah, as that's a different problem unrelated to the problem that this is trying to solve.
> 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/
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.
Well a lot of useful things are not useful because they are innovative, but well designed an executed.
And...that's bad?
Not until you are wrongly considered "untrusted".
It is never wrong to be considered untrusted. It is only occasionally right to be considered trusted. Especially in zero-risk relationships that is the default on the anonymous internet.
It's similar to old Usenet "killfiles" - https://en.wikipedia.org/wiki/Kill_file
...or spam "RBL" lists which were often shared. https://en.wikipedia.org/wiki/Domain_Name_System_blocklist
This makes a lot more sense for large scale and high profile projects, and it eliminates low quality slop PRs by default with the contributors having to earn the trust of the core maintainers to contribute directly to the project.
it also increases the barrier to new adopters
why not use ai to help with the ai problem, why prefer this extra coordination effort and implementation?
That's the whole point. There are many new adopters and few competent ones.
I mean to well meaning contributors, I understand the goal of vouch, I think it goes too far and you'll turn off said well meaning contributors
I certainly have dropped off when projects have burdensome rules, even before ai slop fest
These projects would rather miss out on a few good people to stop the bad ones over the alternative.
I think there are better alternatives, we'll let the market weed things out
For example, I will keep making them spin wheels and burn tokens / money, a sort of honeypot, adversarial shadowban. This is even better for disincentivizing them.
Will automate it if it ever gets bad
The barrier in the Ghostty project is to simply open a discussion. It's not really hard.
What about fixing a typo in a comment?
Do I have to start a discussion before I can submit a fix for a two char swap?
Also, my statement was general, why are you making it about one?
Unfortunately, the mob mentality, and gate keeping from the Reddit mod era, proves that these types of systems simply don’t work.
We can see this effect from Mitchell's own release of his terminal emulator (Ghostty). It was invite-only. The in-crowd on YouTube/Twitter lorded it over others as a status symbol. None of it was based on actual engineering prowess. It was more like, "hey, you speak at conferences and people follow you on social media... you must be amazing".
They're negative sum, but even negative sum systems usually have many winners (so it 'works' for some subset of individuals). That's why it perpetuates.
i think you can go earlier then that. reminds me kind of rep systems on message boards. which got abused.
Yeah, these solutions are always made to try and disract from the fact that you need real, admin-level moderation and enfoecement to build trustworthy users and communities. a rogue actor should be afraid of losing their account if they submit slop. But instead all this is outsourced on the community to try and circumnavigate.
Community level enforcement is unfortunately a game of cat and mouse. except the mouse commands an army and you can only catch one mouse per repo. The most effective solution is obviously to ban the commander, but you'll never reach it as a user.
The underlying idea is admirable, but in practice this could create a market for high-reputation accounts that people buy or trade at a premium.
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.
That's fine? I mean, this is how the world works in general. Your friend X recommends Y. If Y turns out to suck, you stop listening to recommendations from X. If Y happens to be spam or malware, maybe you unfriend X or revoke all of his/her endorsements.
It's not a perfect solution, but it is a solution that evolves towards a high-trust network because there is a traceable mechanism that excludes abusers.
That's true. And this is also actually how the global routing of internet works (BGP protocol).
My comment was just to highlight possible set of issues. Hardly any system is perfect. But it's important to understand where the flaws lie so we are more careful about how we go about using it.
The BGP for example, a system that makes entire internet work, also suffers from similar issues.
Amazing idea - absolutely loving vouch. However, as a security person, this comment immediately caught my attention.
A few things come to mind (it's late here, so apologies in advance if they're trivial and not thought through):
- Threat Actors compromising an account and use it to Vouch for another account. I have a "hunch" it could fly under the radar, though admittedly I can't see how it would be different from another rogue commit by the compromised account (hence the hunch).
- Threat actors creating fake chains of trust, working the human factor by creating fake personas and inflating stats on Github to create (fake) credibility (like how number of likes on a video can cause other people to like or not, I've noticed I may not like a video if it has a low count which I would've if it had millions - could this be applied here somehow with the threat actor's inflated repo stats?)
- Can I use this to perform a Contribution-DDOS against a specific person?
The idea is sound, and we definitely need something to address the surge in low-effort PRs, especially in the post-LLM era.
Regarding your points:
"Threat Actors compromising an account..." You're spot on. A vouch-based system inevitably puts a huge target on high-reputation accounts. They become high-value assets for account takeovers.
"Threat actors creating fake chains of trust..." This is already prevalent in the crypto landscape... we saw similar dynamics play out recently with OpenClaw. If there is a metric for trust, it will be gamed.
From my experience, you cannot successfully layer a centralized reputation system over a decentralized (open contribution) ecosystem. The reputation mechanism itself needs to be decentralized, evolving, and heuristics-based rather than static.
I actually proposed a similar heuristic approach (on a smaller scale) for the expressjs repo a few months back when they were the first to get hit by mass low-quality PRs: https://gist.github.com/freakynit/c351872e4e8f2d73e3f21c4678... (sorry, couldn;t link to original comment due to some github UI issue.. was not showing me the link)
I belong to a community that uses a chain of trust like this with regards to inviting new people. The process for avoiding the bad actor chain problem is pretty trivial: If someone catches a ban, everyone downstream of them loses access pending review, and everyone upstream of them loses invite permissions, pending review. Typically, some or most of the downstream people end up quickly getting vouched for by existing members of the community, and it tends to be pretty easy to find who messed up with a poorly-vetted invite (most often, it was the person who got banned's inviter). Person with poor judgement loses their invite permissions for a bit, everyone upstream from them gets their invite permissions back.
This is a strange comment because, this is literally the world that we live in now? We just assume that everyone is vouched by someone (perhaps Github/Gitlab). Adding this layer of vouching will basically cull all of that very cheap and meaningless vouches. Now you have to work to earn the trust. And if you lose that trust, you actually lose something.
How is that different from what happens now, where someone who contributes regularly to a project faces less scrutiny than a new person?
The difference is that today this trust is local and organic to a specific project. A centralized reputation system shared across many repos turns that into delegated trust... meaning, maintainers start relying on an external signal instead of their own review/intuition. That's a meaningful shift, and it risks reducing scrutiny overall.
I am still not going to merge random code from a supposed trusted invdividual. As it is now, everyone is supposedly trusted enough to be able to contribute code. This vouching system will make me want to spend more time, not less, when contributing.
Trust signals change behavior at scale, even if individuals believe they're immune.
You personally might stay careful, but the whole point of vouching systems is to reduce review effort in aggregate. If they don't change behavior, they add complexity without benefi.. and if they do, that's exactly where supply-chain risk comes from.
I think something people are missing here is, this is a response to the groundswell in vibecoded slop PRs. The point of the vouch system is not to blindly merge code from trusted individuals; it's to completely ignore code from untrusted individuals, permitting you to spend more time reviewing the MRs which remain.
Would it not be better to report accounts then?
To whom? It's not against Github's ToS to submit a bad PR. Anyway, bad actors can just create new accounts. It makes more sense to circulate whitelists of people who are known not to be bad actors.
I also like the flexibility of a system like this. You don't have to completely refuse contributions from people who aren't whitelisted, but since the general admission queue is much longer and full of slop, it makes sense to give known good actors a shortcut to being given your attention.
This isn't a centralised reputation system, though, is it? Each project keeps its own whitelist.
Thats's true.
I don't think the intent is for trust to be delegated to infinity. It can just be shared easily. I could imagine a web of trust being shared between projects directly working together.
That could happen.. but then it would end up becoming a development model similar to the one followed by sqlite and ffmpeg ... i.e., open for read, but closed(almost?) for writes to external contributions.
I don't know whether that's good or bad for the overall open-source ecosystem.
It seems like dating apps to me. You have a large population of highly motivated undesirables to filter out. I think we'll see the same patterns: pay to play, location filtering, identity verification, social credit score (ELO etc).
I even see people hopping on chat servers begging to 'contribute' just to get github clout. It's really annoying.
Prior art? https://en.wikipedia.org/wiki/Advogato
> the purpose of the trust metric is to certify that a given user account on Advogato is known by the Advogato community to actually belong to the individual who claims it and is known to be a member of the free software and open source community. The user may be an crank, annoying, or of a political persuasion that you don't agree with. What the trust metric attempts to guarantee is that they really are who they say they are
Sounds like a slightly different goal but certainly an interesting system to look at
So you're screwed if you don't have any connections. In that way it's just like meat space.
This is untrue.
Look here: https://github.com/mitchellh/vouch/blob/main/CONTRIBUTING.md
It explains how to get vouched. You need to have a person vouch for you after you open an issue with your proposed change. After you are vouched, you may raise a PR.
Nobody is screwed in the Ghostty project. Simply open a discussion to discuss your idea.
Yeah, it's important to note that opening an MR is not the only way to communicate. It seems like many people in this thread are forgetting that.
exactly this, verification should always been on the code
if someone fresh wants to contribute, now they will have to network before they can write code
honestly i don't see my self networking just so that i can push my code
I think there are valid ways to increase the outcome, like open source projects codifying the focus areas during each month, or verifying the PRs, or making PRs show proof of working etc,... many ways to deter folks who don't want to meaningfully contribute and simply ai generate and push the effort down the real contributors
Why are folks seemingly so averse to sending an email / hopping on a channel to actually talk to maintainers before just firing off code? I've been on both sides of this; I have been young and green and just fired off contributions without stopping to think, do they event want this?. Codebases are rarely built primarily out of zillions of shotgunned patches, they are more like a garden that needs tending over time, and the ones that are the best tenders are usually the ones that spend the most amount of time in the garden.
> honestly i don't see my self networking just so that i can push my code
But that's good outcome. You would rather spend time on projects where you agree with the project policies.
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.
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.
> 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.
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.
To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away.
Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.
I disagree with the "just"-ness of setting up bugzilla + cgit... but I do wonder how far you could go with just being on literally any platform.
Obviously technically the same things are possible but I gotta imagine there's a bit less noise on projects hosted on other platforms
I mean, "everyone already has an account" is already a very good reason. That doesn't mean "I automatically accept contributions from everyone", it might be "I want to make the process of contribution as easy as possible for the people I want as contributors".
Hatching a reputation-based scheme around a "Contributor Management System" and getting "the people you want as contributors" to go along with it is easier than getting them to fill in a 1/username 2/password 3/confirm-password form? Choosing to believe that is pure motivated reasoning.
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.
GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"
I know this is a joke, but pretending for a moment that it isn’t: this would immediately result in the rep system being gamed the same way it is on eBay: scam sellers can purchase feedback on cheap or self-shipping auctions and then pivot into defrauding people on high-dollar sales before being banned, rinse, and repeat.
Let's also see the differences: On github you can always see the interactions. On ebay, once a sale has been made, you have no idea what happens next. On Github you always have all the artifacts of where the reputation comes from.
The ones I've never understood are: Prompt payment. Great buyer.
I can't check out unless I pay. How is that feedback?
On auctions, you do not have to provide a payment method to bid. So once you won an auction you still have to pay the agreed price. Only after the buyer paid, does the seller get the shipment address. Depending on the buyer this can take longer or shorter (or won't happen at all).
There are people who bid but then don’t pay if they win the auction. Or take weeks to pay after winning. That’s just a pain for the seller, because they have to spend time trying to get the winner to pay, or else have to put up the auction again (which used to cost some fee each time for the seller, I don’t know how it is now). The only penalty for non-paying winners is the negative feedback they receive.
I don't know how it is where where you live, but here there are two possibilities I can think of:
- When I buy an item I still have to click a "check out" link to enter my address and actually pay for the item. I could take days after buying the item to click that link. - Some sellers might not accept PayPal, instead after I check out I get the sellers bank information and have to manually wire the money. I could take days after checking out to actually perform the money transfer.
I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
Intrinsically good, but in conflict with some larger, out of band concern that the contributor could have no way to know about? Upvote to take the sting out of rejection, along with a note along the lines of "Well done, and we would merge is it weren't for our commitment to support xxx systems which are not compatible with yyy. Perhaps refactor as a plugin?"
Also, upvotes and merge decisions may well come from different people, who happen to disagree. This is in fact healthy sometimes.
>The only bad way I can see this being gamed is if a bunch of buddies get together and merge each other's garbage PR
Ya, I'm just wondering how this system avoids a 51% attack. Simply put there are a fixed number of human contributers, but effectively an infinite number of bot contributers.
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...
Hi, thank you for putting in the work to share and manage this. Having read the commands I noted that there are only two options available: vouched and not, with denounced being a harder not vouches. I was wondering if it would help to separate this into three levels: vouched (positive), not vouched (neutral) and denounced (negative)? Then a project could allow PRs from 'not vouvhed' contributers, but have the option of denouncing them. This would leave the communities open to new contributions, while giving a way to reject bad actors. Then vouched users could have extra privileges. Perhaps authority to denounce, or merge. Although those are already gates by contribution rights on the underlying forge.
So is there value in a three state system, rather than a 2 state?
It seems it's a 3 state system already, with exit code 2 being the "not vouched / neutral" state.
https://github.com/mitchellh/vouch?tab=readme-ov-file#local-...
Local Commands
Check a user's vouch status:
vouch check <username>
Exit codes: 0 = vouched, 1 = denounced, 2 = unknown.
Hope github can natively integrate something in the platform, a relevant discussion I saw on official forums: https://github.com/orgs/community/discussions/185387
We'll ship some initial changes here next week to provide maintainers the ability to configure PR access as discussed above.
After that ships we'll continue doing a lot of rapid exploration given there's still a lot of ways to improve here. We also just shipped some issues related features here like comment pinning and +1 comment steering [1] to help cut through some noise.
Interested though to see what else emerges like this in the community, I expect we'll see continued experimentation and that's good for OSS.
[1] https://github.blog/changelog/2026-02-05-pinned-comments-on-...
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.
Inside the repo as metadata that can be consumed by a provider, like GHA config in .github/. Standardized, at least as an extension like git lfs so it's provider independent. Could work! I've long thought effective reputational models are a major missing piece of internet infrastructure, this could be the beginning of their existence given the new asymmetric threat of LLM output, combined with mitchellh's productivity and recognition.
This reminds me of the time that Ripple launched a marketing promotion, giving developers some amount of Ripple to encourage micropayments. They defined "developer" as "someone who has had a GitHub account for 1 year prior to this announcement" to stop folks from creating hundreds of new accounts to claim credits. This essentially created a bounty on existing GitHub accounts and led to thousands of account compromises due to poor password hygiene. GitHub account security is much better now than it was back then (Nov 2013), but this solution similarly puts a bounty on highly-vouched accounts.
I've thought about making such a system before, but never considered making it a single flat file¹. How are you going to identify who keeps inviting these bad actors?
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...
I think a system that allows a reason someone is denounced, specifically for political views or support, should be implemented, to block the mob from denouncing someone on all of their projects, simply because they are against certain topics, or in an opposing political party
1. Such a system is already in place (see the `--reason` flag).
2. Being able to denounce people with noxious political views is a feature, not a bug. If someone shows up in your issues complaining about how your CoC is "woke," they're a bad actor stirring up pointless drama. At best, this is just a waste of everyone's time, and at worst they're haranguing your actual contributors who happen to be trans or something. Respectful contributors naturally will not fall afoul of this, regardless of their beliefs or party affiliation or what-have-you.
Sometimes political views should actually get you shunned.
You're always free to create a fork.
And this is why it needs a reason/ban rule. You guys simply can’t help yourselves.
Please tell us the correct political views we should have, or at least provide a list of the political views that will result in a shunning.
You know exactly the ones they're talking about.
The ones you're not willing to say with your whole chest in public because you know what everyone will think about you.
Either have the courage of your own convictions or have shame, you pick.
I'm reminded of the old Usenet responses to people claiming to solve the spam problem, so I can't help myself:
This is a fun post. I think you're mistaken, though.
Your strongest point is that allowlists exclude new contributors. (You're right about blocklists, but this seems to me like a primarily allowlist-based approach.) Thing is, new contributors are already being excluded by a flood of slop PRs within which they are indistinguishable. Whatever strategy they would currently use to distinguish themselves (reaching out through social channels, volunteering in the issue for an important problem, etc) should still work with vouch. But when it does work and they are vouched for, they will get a reputational shortcut to contribute again in this repo and to contribute in other repos sharing the same vouchlist.
Like any good social solution, `vouch` is trying to codify & extend the existing ad-hoc practices that have arisen to cope with slop PRs (i.e. largely ignoring PRs submitted by strangers). Obviously it's not a full solution, but I'm suspicious of solutions that claim to fully solve a difficult problem. It's a step forward.
> forge-based
?
Almost certainly referring to a software forge: https://en.wikipedia.org/wiki/Forge_(software)
This is an excellent step in the direction of a web-of-trust that the present moment demands, facing an increasingly mistrustful web in the face of LLMs.
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.
This totally won't be abused in some way by the drama-free open source community.
Have they shared the lists of developers they want prophylactically blackballed from the community yet?
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.
Ovet-strict spam filters usually lead to de facto shunning of the person that doesn’t realize their incoming messages are being dropped.
I think that’ll also happen to most open source projects that adopt a policy of silent auto-rejection of contributions without review.
Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors
At a technical level it's straightforward. Repo maintainers maintain their own vouch/denouncelists. Your maintainers are assumed to be good actors who can vouch for new contributors. If your maintainers aren't good actors, that's a whole other problem. From reading the docs, you can delegate vouching to newly vouched users, as well, but this isn't a requirement.
The problem is at the social level. People will not want to maintain their own vouch/denounce lists because they're lazy. Which means if this takes off, there will be centrally maintained vouchlists. Which, if you've been on the internet for any amount of time, you can instantly imagine will lead to the formation of cliques and vouchlist drama.
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.
I think this is the inevitable reality for future FOSS. Github will be degraded, but any real development will be moved behind closed doors and invite only walls.
That's putting weight on the other end of the scale. Why would you want to stake your reputation on an internet stranger based on a few PRs?
You are not supposed to vouch for strangers, system working as intended.
You can't get perfection. The constraints / stakes are softer with what Mitchell is trying to solve i.e. it's not a big deal if one slips through. That being said, it's not hard to denounce the tree of folks rooted at the original bad actor.
> The interesting failure mode isn’t just “one bad actor slips through”, it’s provenance: if you want to > “denounce the tree rooted at a bad actor”, you need to record where a vouch came from (maintainer X, > imported list Y, date, reason), otherwise revocation turns into manual whack-a-mole. > > Keeping the file format minimal is good, but I’d want at least optional provenance in the details field > (or a sidecar) so you can do bulk revocations and audits.
Indeed, it's relatively impossible without ties to real world identity.
> Indeed, it's relatively impossible without ties to real world identity.
I don't think that's true? The goal of vouch isn't to say "@linus_torvalds is Linus Torvalds" it's to say "@linus_torvalds is a legitimate contributor an not an AI slopper/spammer". It's not vouching for their real world identity, or that they're a good person, or that they'll never add malware to their repositories. It's just vouching for the most basic level of "when this person puts out a PR it's not AI slop".
That’s not the point.
Point is: when @lt100, @lt101, … , @lt999 all vouch for something, it’s worthless.
That's really easy to clean up, if you maintain the tree of trust. If a parent node gets whacked, all the child nodes do, too.
Real world identity isn't sufficient or necessary to solve that problem.
But surely then a maintainer notices what has happened, and resolves the problem?
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 :)
It’s easy to game systems unless you attach real stakes, like your reputation. You can vouch for anyone, but if you consistently back bad actors your reputation should suffer along with everything you endorsed.
The web badly under-uses reputation and cryptographic content signing. A simple web of trust, where people vouch for others and for content using their private keys, would create a durable public record of what you stand behind. We’ve had the tools for decades but so far people decline to use them properly. They don't see the urgency. AI slop creates the urgency and yet everybody is now wringing their hands on what to do. In my view the answer to that has been kind of obvious for a while: we need a reputation based web of trust.
In an era of AI slop and profit-driven bots, the anonymous web is just broken. Speech without reputational risk is essentially noise. If you have no reputation, the only way to build one is by getting others to stake theirs on you. That's actually nothing new. That's historically how you build reputation with family, friends, neighbors, colleagues, etc. If you misbehave, they turn their backs on you. Why should that work differently on the web?
GitHub actually shows how this might work but it's an incomplete solution. It has many of the necessary building blocks though. Public profiles, track records, signed commits, and real artifacts create credibility that is hard to fake except by generating high quality content over a long time. New accounts deserve caution, and old accounts with lots of low-quality (unvouched for) activity deserve skepticism. This is very tough to game.
Stackoverflow is a case study in what not to do here. It got so flooded by reputation hungry people without one that it got super annoying to use. But that might just be a bad implementation of what otherwise wasn't a bad idea.
Other places that could benefit from this are websites. New domains should have rock bottom reputation. And the link graphs of older websites should tell you all you need to know. Social networks can add the social bias: people you trust vouching for stuff. Mastodon would be perfect for this as an open federated network. Unfortunately they seem to be pushing back on the notion that content should be signed for reasons I never understood.
you can't really build a perfect system, the goal would be to limit bad actors as much as possible.
I will never contribute to a project that runs on this sort of ridiculous popularity contest system.
Hint: every software project at every company runs on this sort of ridiculous popularity contest system, the rules of the game are just not publicized.
Yeah but I get paid for that.
Fediverse link: https://fosstodon.org/@mitchellh@hachyderm.io/11603152931120...
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 Web of Trust failed for PGP 30 years ago. Why will it work here?
It didn't work for links as reputation for search once "SEO" people started creating link farms. It's worse now. With LLMs, you can create fake identities with plausible backstories.
This idea won't work with anonymity. It's been tried.
I guess this is why Sam Altman wants to scan everyone's eyeballs.
Web of Trust failed? If you saw that a close friend had signed someone else's PGP key, you would be pretty sure it was really that person.
Identity is a lot easier than forward trustworthiness. It can succeed for the former and fail for the latter.
I'm not convinced that just because something didn't work 30 years ago, there's no point in revisiting it.
There's likely no perfect solution, only layers and data points. Even if one of the layers only provides a level of trust as high as the most lax person in the network, it's still a signal of something. The internet will continue to evolve and fracture into segments with different requirements IMHO.
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.
I'm guessing denounce is for bad faith behavior, not just low quality contributions. I think it's actually critical to have a way to represent this in a reputation system. It can be abused, but abuse of denouncement is grounds for denouncement, and being denounced by someone who is denounced by trusted people should carry little weight.
IDK about this implementation ...
OVER-Denouncing ought to be tracked, too, for a user's trustworthiness profile.
I'm pretty sure this project just does the storage model. It's up to communities that use it to determine the semantics and derive reputation and other higher level concepts from the data.
Off topic but why was contributing to Npgsql a bad experience for you? I've contributed, admittedly minor stuff, to that ecosystem and it was pretty smooth.
Denounce also creates liability: you are slandering someone, explicitly harming their reputation and possibly their career.
I'd hesitate to create the denounce function without speaking to an attorney; when someone's reputation and career are torpedoed by the chain reaction you created - with the intent of torpedoing reputations - they may name you in the lawsuit for damages and/or to compel you to undo the 'denounce'.
Not vouching for someone seems safe. No reason to get negative.
What value would this provide without the denouncement feature? The core purpose of the project, from what I can tell, is being able to stop the flood of AI slop coming from particular accounts, and the means to accomplish that is denouncing those accounts. Without denouncement you go from three states (vouched, neutral, denounced) to two (vouched and neutral). You could just make everyone who isn't vouched be put into the same bucket, but that seems counterproductive.
Are there actually open source developers that wander from project to project with one-off contributions that are of significant value? This seems to optimize for that specific scenario, and it’s not something I’ve seen in practice.
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”
I think LLMs are accelerating us toward a Dune-like universe, where humans come before AI.
You say that as if it’s a bad thing. The bad thing is that to get there we’ll have to go through the bloody revolution to topple the AI that have been put before the humans. That is, unless the machines prevail.
You might think this is science fiction, but the companies that brought you LLMs had the goal to pursue AGI and all its consequences. They failed today, but that has always been the end game.
Got to go through the Butlerian Jihad first… not looking forward to that bit.
(EDIT: Thanks sparky_z for the correction of my spelling!)
Close, but it's "Butlerian". Easy to remember if you know it's named after Samuel Butler.
https://en.wikipedia.org/wiki/Erewhon
That was one of the most unplausible aspects of that series, at least the subset of which was remotely plausible - i.e. there was alot of "magic".
Given two factions at war, one of which is using AI/machines and the other is not and wants to destroy them, my bet is on the side using AI/machines.
The alternative is far far worse.
To play devil’s advocate: We’ve vendored a few open source projects by just asking an LLM to fix obvious bugs that have been open for 12+ months (some projects are abandoned, others active).
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.
Open source projects are under no obligation to accept any patches, AI or human generated. Being the fastest evolving fork may not be their goal.
I'm pretty doubtful a handful of one-shot AI patches is a viable fork. Bug fixes are only one part of the workload.
I agree with you, but I don't envy the maintainers. The problem is that it's really hard to tell if someone is skilled like you or just shoveling what an LLM wrote up to the maintainers to have them "figure it out." Honestly, getting a library hard forked and maintained by people that can keep up with the incoming PRs would be a relief to a lot of folks...
Oh, to be clear, there’s no way we’d want incoming code for these forks.
Incoming bug reports or design docs an LLM could implement? Sure.
Maybe something like the Linux approach (tree of well-tested, thematic branches from lieutenants) would work better. We’d be happy to be lieutenants that shepherded our forks back to upstream.
> Telling people like me to f—— off is just going to accelerate irrelevance in situations like this.
You have your fork and the fixes, the PR is just kindness on your part. If they don’t want it then just move on with your fork.
I once submitted a PR to some Salesforce helper SDK and the maintainer went on and on about approaches and refactoring etc. I just told him to take it or leave it, I don’t really care. I have my fork and fix already. They eventually merged it but I mean I didn’t care either way, I was just doing something nice for them.
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.
This reminds me a bit of the basic concepts behind Zed Shaw's Utu idea
https://weblog.masukomi.org/2018/03/25/zed-shaws-utu-saving-...
https://savingtheinternetwithhate.com/
DEFCON presentation: https://www.youtube.com/watch?v=ziTMh8ApMY4
A lot of the discussion is predicated on this as a "solution" to AI contributions, but I'm a little doubtful of the efficacy. It assumes that everyone in "the community" has similar opinions, but for example, while Mr. Torvalds may call current LLMs crap, he also says LLMs are just like any other tool and doesn't see copyright issues. How are you going to weigh Linux-vouched contributors?
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
Is codeowners lacking features to implement this?
Yes, it doesn't control anything about who can submit PRs (as far as I know), just who can approve/merge them from predefined groups/users.
Is this a privacy nightmare because it exposes graphs of people together publicly?
If you like this, you may love Robin Hansons similar idea of vouching [0]
[0]: https://www.youtube.com/watch?v=rPdHXw05SvU
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.”*
Man, I'm a huge fan of Anathem (and Stephenson in general) but this short excerpt really reminded me of https://xkcd.com/483/
Oh for sure. To be fair, that excerpt I posted is probably the worst in the entire book since Sammann is explaining something using a bunch of ITA ~~jargon~~ bulshytt and it’s meant to be incomprehensible to even the POV character Erasmas.
Spoilers for Anathem and His Dark Materials below
Xkcd 483 is directly referencing Anathem so that should be unsurprising but I think in both His Dark Materials (e.g. anbaric power) and in Anathem it is in-universe explained. The isomorphism between that world and our world is explicitly relevant to the plot. It’s the obvious foreshadowing for what’s about to happen.
The worlds are similar with different names because they’re parallel universes about to collide.
I wonder how effective that might be as a language-learning tool. Imagine a popular novel in the US market, maybe 80000-100000 words long but whose vocabulary consists of only a few thousand unique words. The first few pages are in English, but as you progress through the book, more and more of the words appear in Chinese or German or whatever the target language is. By the end of the book you are reading the second language, having absorbed it more or less through osmosis.
Someone who reads A Clockwork Orange will unavoidably pick up a few words of vaguely-Russian extraction by the end of it, so maybe it's possible to take advantage of that. The main problem I can see is that the new language's sentence grammar will also have to be blended in, and that won't go as smoothly.
Just a thought: Around the world, most* online classifieds pages have site-wide ways to provide feedback on interactions. Ebay has stars, Germanys Kleinanzeigen has :) :| :( etc etc.
Maybe something like this could be useful for open source collaboration as well?
*with the notable exception of craigslist
I had a similar thought, but I think there's a key difference here.
Traditional karma scores, star counts, etc, are mostly just counters. I can see that a bunch of people upvoted, but these days it's very easy for most of those votes to come from bots or spam farms.
The important difference that I see with Vouch is not just that I'm incrementing a counter when I vouch for you, but that I am publicly telling the world "you can trust this person". And if you turn out to be untrustworthy, that will cost me something in a much more meaningful way than if some Github project that I starred turns out to be untrustworthy. If my reputation stands to suffer from being careless in what I vouch for, then I have a stronger incentive to verify your trustworthiness before I vouch for you, AND I have an ongoing incentive to discourage you from abusing the trust you've been given.
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.
> Ah, we have converted a technical problem into a social problem.
Surely you mean this the other way around?
Mitchell is trying to address a social problem with a technical solution.
Nope, I meant what I originally said.
The problem is technical: too many low-quality PRs hitting an endpoint. Vouch's solution is social: maintain trust graphs of humans.
But the PRs are increasingly from autonomous agents. Agents don't have reputations. They don't care about denounce lists. They make new accounts.
We solved unwanted automated input for email with technical tools (spam filters, DKIM, rate limiting), not by maintaining curated lists of Trusted Emailers. That's the correct solution category. Vouch is a social answer to a traffic-filtering problem.
This may solve a real problem today, but it's being built as permanent infrastructure, and permanent social gatekeeping outlasts the conditions that justified it.
"Juniors" (or anyone besides maintainers) do not fundamentally have a right to contribute to an open source project. Before this system they could submit a PR, but that doesn't mean anyone would look at it. Once you've internalized that reality, the rest flows from there.
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.
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.
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?
At first, this concept looked so cool, to solve a real problem!
But then the actions implementation starts with "pull_request_target" :(
Why stop at restricting pull requests? I wouldn't want spam issues either. New issues and contributors should be gated at the "discussion" stage.
> 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.)
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 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.
This adds friction, disincentivizes legitimate and high quality code commits and uses humans even more.
The entire point is to add friction. Accepting code into public projects used to be highly frictive. RMS and Linus Torvalds weren't just accepting anyone's code when they developed GNU and Linux; and to even be considered, you had to submit patches in the right way to a mailing list. And you had to write the code yourself!
GitHub and LLMs have reduced the friction to the point where it's overwhelming human reviewers. Removing that friction would be nice if it didn't cause problems of its own. It turns out that friction had some useful benefits, and that's why you're seeing the pendulum swing the other way.
Love seeing some nushell usage!
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.
I think its crazy that a single person thinks so much of themselves to create this under their name
Its a personal project? Do you truly believe that individuals are required to have the foresight into how their project will get adopted or viewed by the community that it would require them to create a separate github account to host it under?
https://www.lewissociety.org/innerring/
feels very micromanagement-ish
Why isn't the link directly to the github repository[1]?
[1]: https://github.com/mitchellh/vouch
Problem 1 - assuming this Vouch tool gains wide adoption without major fuckups, I predict that a lot of people would "outsource" their own vetting to it, and it would become a circular system where newcomer would not be able to get vouched because everyone will expect others to do it.
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.
We need this for social media.
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.
Why in nushell? Not in go?
But I like the idea and principle. OSS need this and it's traded very lightly.
Mitchell has really enjoyed Nu essentially. If it is implemented in a shell script, it probably also means that general shell tooling can work with the format.
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.
Looks like he's got a few posts mentioning that he likes nu[0].
Something to keep in mind if I'm ever looking to switch I guess.
[0] https://x.com/mitchellh/status/1907849319052386577
he seems like dislikes go and rust. and likely ts. go and ts were fully legit for such work.
zig is too low level.
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?
The issues are still open. https://news.ycombinator.com/item?id=46535621
I love the idea, but it's going to be cancelled for sure.
After the economy of attention, no things enter the economy of trust.
Reminds me fondly of advogato.
I don't see how to apply this to my medium-sized project - this is essentially a whitelist of all contributors, which is the same as a collaborators feature in github. How would an entirely new contributor get a contribution in?
This is perhaps good for massive projects like curl which are tired of AI slop.
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.
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.
Can't believe they didn't call it VouchDB.
I'm sick of the fact that every techno-nerd (including me) can create a new level of abstraction, the integrity of which will be proven with foam at the mouth by other people.
Another way to solve this is how Linux organizes. Tree structure where lower branches vet patches and forward them up when ready
> vouch denounce badactor [--reason str]
Simple as. He who is without sin can cast the first stone.
Sibil attack in 3...2...1....
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.
That's what I thought of right away as well. We may end up with a blacklist of "known AI slop peddlers".
Is this the return of Advogato?
> 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.)
Yeah… this code is entirely just a parser for a file format the author invented. Exact same thing could be done as a csv. Sacrificing confugrability for standardization and all that, but… I don’t see the there, there.
Probably the idea is to eventually have these as some sort of public repo where you can merge files from arbitrary projects together? Or inherit from some well known project’s config?
Agree! Real people are not static sets of characteristics, and without a immutable real-world identity this is even harder. It feels like we've just moved the problem from "evaluate code one time" to "continually evaluate a persona that could change owners"
We got social credit on GitHub before GTA 6.
I've had a similar idea, but too many squirrels out there. I hope this works and can be embraced and extended in a positive manner for the developer community.
this wouldn't have helped against the xz attack
It's not intended to, though? It's supposed to address the issue of low-effort slop wasting maintainer time, not a well-planned attack.
This is a signal of failure of GH (Microsoft) to limit AI-based interactions, which is obviously not in their superficial strategic interests to do so.
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.
How can you "limit AI-based interactions"? Also, is there any "platform that penalizes AI properly at its source"?
Is what?
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.
Does is overlap with Contributor License Agreement?
Central karma database next, please. Vouch = upvote, denounce = downvote
Fortunately, as long as software is open sourced, forking will remain a viable way to escape overzealous gatekeeping.
Is this social credit?
Wait until he finds out about GPG signing parties in the early 2000s.
Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.
Can you cite the law that says you may not do this?
There are obvious cases in Europe (well, were if you mean the EU) where there need not be criminal behaviour to maintain a list of people that no landlord in a town will allow into their pubs, for example.
Under the EU’s GDPR, any processing of personal data (name, contact, identifiers, etc.) generally requires a legal basis (e.g., consent, legitimate interest, contractual necessity), clear purpose, minimal data, and appropriate protection. Doing so without a lawful basis is unlawful.
It is not a cookie banner law. The american seems to keep forgetting that it's about personal data, consent, and the ability to take it down. The sharing of said data is particularly restricted.
And of course, this applies to black list, including for fraud.
Regulators have enforced this in practice. For example in the Netherlands, the tax authority was fined for operating a “fraud blacklist” without a statutory basis, i.e., illegal processing under GDPR: https://www.autoriteitpersoonsgegevens.nl/en/current/tax-adm...
The fact is many such lists exist without being punished. Your landlord list for example. That doesn't make it legal, just no shutdown yet.
Because there is no legal basis for it, unless people have committed, again, an illegal act (such as destroying the pub property). Also it's quite difficult to have people accept to be on a black list. And once they are, they can ask for their data to be taken down, which you cannot refuse.
> The american seems to keep forgetting that it's about personal data, consent, and the ability to take it down.
I am European, nice try though.
It is very unclear that this example falls foul of GDPR. On this basis, Git _itself_ fails at that, and no reasonable court will find it to be the case.
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...
> Leave it to us nerds to try and solve a human problem with a technical solution...
Honestly, my view is that this is a technical solution for a cultural problem. Particularly in the last ~10 years, open source has really been pushed into a "corporate dress rehearsal" culture. All communication is expected to be highly professional. Talk to everyone who opens an issue or PR with the respect you would a coworker. Say nothing that might offend anyone anywhere, keep it PG-13. Even Linus had to pull back on his famously virtiolic responses to shitty code in PRs.
Being open and inclusive is great, but bad actors have really exploited this. The proper response to an obviously AI-generated slop PR should be "fuck off", closing the PR, and banning them from the repo. But maintainers are uncomfortable with doing this directly since it violates the corporate dress rehearsal kayfabe, so vouch is a roundabout way of accomplishing this.
What on earth makes you think that denouncing a bot PR with stronger language would deter it? The bot does not and cannot care.
If that worked, then there would be an epidemic of phone scammers or email phishers having epiphanies and changing careers when their victims reply with (well deserved) angry screeds.
I didn't mean the "fuck off" part to be quite verbatim... this ghostty PR[0] is a good example of how this stuff should be handled. Notably: there's no attempt to review or provide feedback--it's instantly recognized as a slop PR--and it's an instant ban from repo.
This is the level of response these PRs deserve. What people shouldn't be doing is treating these as good-faith requests and trying to provide feedback or asking them to refactor, like they're mentoring a junior dev. It'll just fall on deaf ears.
[0] https://github.com/ghostty-org/ghostty/pull/10588
Sure, but that pull request is blatantly unreviewable because of how it bundles dozens of entirely unrelated commits together. Just say that and move on: it only takes a one-line comment and it informs potential contributors about what to avoid if any of them is lurking the repo.
One problem with giving any feedback is that it can automatically be used by an agent to make another PR.
If they immediately make another low-quality PR that's when you ban them because they're clearly behaving like a bad actor. But providing even trivial, boilerplate feedback like that is an easy way of drawing a bright line for contributors: you're not going to review contributions that are blatantly low-quality, and that's why they must refrain from trying to post raw AI slop.
Sounds like we're largely saying the same thing. Open source maintainers should feel empowered to say "nope, this is slop, not reading, bye" and ban you from the repo, without worrying if that seems unprofessional.
If you explicitly say "this is unreviewable junk, kthxbye" there's nothing unprofessional about it. But just blaming "AI slop" runs into the obvious issue that most people may be quite unaware that AI will generate unreviewable junk by default, unless it's being very carefully directed by an expert user.
> Particularly in the last ~10 years ...
This is maturation, open source being professional is a good sign for the future
I disagree. The problem with AI slop is not so much that it's from AI, but that it's pretty much always completely unreadable and unmaintainable code. So just tell the contributor that their work is not up to standard, and if they persist they will get banned from contributing further. It's their job to refactor the contribution so that it's as easy as possible to review, and if AI is not up to the task this will obviously require human effort.
You're giving way too much credit to the people spamming these slop PRs. These are not good faith contributions by people trying to help. They are people trying to get pull requests merged for selfish reasons, whether that's a free shirt or something to put on their resume. Even on the first page of closed ghostty PRs I was able to find some prime slop[0]. It is a huge waste of time for a maintainer to nicely tell people like this they need to refactor. They're not going to listen.
edit; and just to be totally clear this isn't an anti-AI statement. You can still make valid, even good PRs with AI. Mitchell just posted about using AI himself recently[1]. This is about AI making it easy for people to spam low-quality slop in what is essentially a DoS attack on maintainers' attention.
[0] https://github.com/ghostty-org/ghostty/pull/10588
[1] https://mitchellh.com/writing/my-ai-adoption-journey
If you can immediately tell "this is just AI slop" that's all the review and "attention" you need; you can close the PR and append a boilerplate message that tells the contributor what to do if they want to turn this into a productive contribution. Whether they're "good faith contributors trying to help" or not is immaterial if this is their first interaction. If they don't get the point and spam the repo again then sure, treat them as bad actors.
The thing is, the person will use their AI to respond to your boilerplate.
That means you, like John Henry, are competing against a machine at the thing that machine was designed to do.
...and waste valuable time reviewing AI slop? it looks surprisingly plausible, but never integrates with the bigger picture.
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.
Vouch is a good quick fix, but it has some properties that can lead to collapsed states, discussed in the article linked here: https://news.ycombinator.com/item?id=46938811
it's also going to kill the open web. nobody is going to want to share their ideas or code publicly anymore. with the natural barriers gone, the incentives to share will go to zero. everything will happen behind closed doors.
You could argue that this could increase output to the open web: outsiders still need a place to clout chase.
GitHub has never been a good method of clout chasing. in decades of being in this industry, I've seen < 1% of potential employers care about FLOSS contributions, as long as you have some stuff on your GH.
The origin of the problems with low-quality drive-by requests is github's social nature[0]. AI doesn't help, but it's not the cause.
I've seen my share of zero-effort drive-by "contributions" so people can pad their GH profile, long before AI, on tiny obscure projects I have published there: larger and more prominent projects have always been spammed.
If anything, the AI-enabled flood will force the reckoning that was long time coming.
[0] https://news.ycombinator.com/item?id=46731646
I feel this is a bit too pessimistic. For example, people can make tutorials that auto-certify in vouch. Or others can write agent skills that share etiquette, which agents must demonstrate usage of before PRs can be created.
Yes, there's room for deception, but this is mostly about superhuman skills and newcomer ignorance and a new eternal September that we'll surely figure out
> that's all going to go away and everyone is going to fall back on credentials and social standing.
Only if you allow people like this to normalize it.
.. all revolving around a proprietary Microsoft service.
Support Microsoft or be socially shunned?
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 sense cause they're being invoked ON GITHUB).
Define "platform".
So I can choose from github, gitlab or maybe codeberg? What about self-hosters, with project-specific forges? What about the fact that I have an account on multiple forges, that are all me?
This seems to be overly biased toward centralized services, which means it's just serving to further re-enforce Microsoft's dominance.
It's a text string, platform can be anything you want, then use the vouch CLI (or parse it yourself) to do whatever you want. We don't do identity mapping, because cross-forge projects are rare and maintaining that would centralize the system and its not what we're trying to do. The whole thing is explicitly decentralized with tiny, community specific networks that you build up.
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.
Tracks. You don't care about the open source community.
No, that’s quite a jump. I just respect whatever your preferences are.
argueably, the years 2015-2020, we should have gone back to social standing.
I guess you could say the same about a lot of craft- or skill-based professions that ultimately got heavily automated.
It also marks the end of the open source movement as the value of source code has lost any meaning with vibe coding and ai.
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.
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 the cons outway the pros, then doing nothing is better than this.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
did you have any actual criticism?
cons to YOU outway the pros. pros to HIM outway the cons.
Replacing merit with social signaling.. ..sigh..
The enshitification of GitHub continues
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.
Who trusts people who still use X?
I still prefer it to Wayland for various reasons, and I don't think Wayland would work properly on my mid 2010 Macbook anyway.
i believe he is talking about Twitter(X) and not x11. so a political stance from the x.com in the description. i love running x11 too, wayland is still not there yet sadly, still has a few quirks.
if not mistaken x11 is what mitchell is running rightn ow https://github.com/mitchellh/nixos-config/blob/0c42252d8951a...
Exactly. Poor judgement on the author’s part.