16 ms·

Vouch

• davidkwast 8mo ago
  I think LLMs are accelerating us toward a Dune-like universe, where humans come before AI.
  • ashton314 8mo ago
    Got to go through the Butlerian Jihad first… not looking forward to that bit. (EDIT: Thanks sparky_z for the correction of my spelling!)
    • sparky_z 8mo ago
      Close, but it's "Butlerian". Easy to remember if you know it's named after Samuel Butler. https://en.wikipedia.org/wiki/Erewhon https://en.wikipedia.org/wiki/Erewhon
    • Rumple22Stilk 8mo ago
      The alternative is far far worse.
    • SJC_Hacker 8mo ago
      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.
  • sph 8mo ago
    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.
• someone_jain_ 8mo ago
  Hope github can natively integrate something in the platform, a relevant discussion I saw on official forums: https://github.com/orgs/community/discussions/185387 https://github.com/orgs/community/discussions/185387
  • matthewisabel 8mo ago
    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-github-issues/ https://github.blog/changelog/2026-02-05-pinned-comments-on-...
• cedws 8mo ago
  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.
• deleted 8mo ago
  [deleted]
• sanufar 8mo ago
  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.
• canada_dry 8mo ago
  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.
• deleted 8mo ago
  [deleted]
• deleted 8mo ago
  [deleted]
• alexjurkiewicz 8mo ago
  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.
  • deleted 8mo ago
    [deleted]
  • javascripthater 8mo ago
    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.
    • BugsJustFindMe 8mo ago
      Identity is a lot easier than forward trustworthiness. It can succeed for the former and fail for the latter.
  • Animats 8mo ago
    > 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.
    • ibrahima 8mo ago
      I guess this is why Sam Altman wants to scan everyone's eyeballs.
  • chickensong 8mo ago
• pyrolistical 8mo ago
  Another way to solve this is how Linux organizes. Tree structure where lower branches vet patches and forward them up when ready
• stephantul 8mo ago
  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.
  • __turbobrew__ 8mo ago
    > 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?
    • vasco 8mo ago
      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.
  • ashton314 8mo ago
    > 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…
    • smoyer 8mo ago
      Look at ERC-8004
• ashton314 8mo ago
  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.”*
  • igor47 8mo ago
    Man, I'm a huge fan of Anathem (and Stephenson in general) but this short excerpt really reminded me of https://xkcd.com/483/ https://xkcd.com/483/
• enterprisetalk 8mo ago
  [dead]
• returnInfinity 8mo ago
  [flagged]
• jemfinch 8mo ago
  Is this the return of Advogato?
• whalesalad 8mo ago
  We got social credit on GitHub before GTA 6.
• ashton314 8mo ago
  Fediverse link: https://fosstodon.org/@mitchellh@hachyderm.io/116031529311207899 https://fosstodon.org/@mitchellh@hachyderm.io/11603152931120...
• skeptrune 8mo ago
  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.
• arjie 8mo ago
  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.
• amadeuspagel 8mo ago
  Why isn't the link directly to the github repository[1]? [1]: https://github.com/mitchellh/vouch https://github.com/mitchellh/vouch
• tmvnty 8mo ago
  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-trust-levels https://blog.discourse.org/2018/06/understanding-discourse-t...
• bmitch3020 8mo ago
  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.
• moogly 8mo ago
  So you're screwed if you don't have any connections. In that way it's just like meat space.
  • eightnoteight 8mo ago
    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
    • kortex 8mo ago
      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.
    • geodel 8mo ago
      > 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.
  • tristan957 8mo ago
    Nobody is screwed in the Ghostty project. Simply open a discussion to discuss your idea.
    • Zambyte 8mo ago
      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.
• archagon 8mo ago
  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.
• abracos 8mo ago
  Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors
  • deleted 8mo ago
    [deleted]
  • DJBunnies 8mo ago
    Indeed, it's relatively impossible without ties to real world identity.
    • mjr00 8mo ago
      > 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".
      • DJBunnies 8mo ago
        That’s not the point. Point is: when @lt100, @lt101, … , @lt999 all vouch for something, it’s worthless.
        • jen20 8mo ago
          But surely then a maintainer notices what has happened, and resolves the problem?
        • Dylan16807 8mo ago
          Real world identity isn't sufficient or necessary to solve that problem.
        • OkayPhysicist 8mo ago
• IshKebab 8mo ago
  > 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.)
  • vscode-rest 8mo ago
    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?
  • skeeter2020 8mo ago
    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"
• vips7L 8mo ago
  Love seeing some nushell usage!
• zenoware 8mo ago
  [dead]
• aatd86 8mo ago
  Does is overlap with Contributor License Agreement?
• quotemstr 8mo ago
  Fortunately, as long as software is open sourced, forking will remain a viable way to escape overzealous gatekeeping.
• skeeter2020 8mo ago
  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...
  • mjr00 8mo ago
    > 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.
    • zozbot234 8mo ago
      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.
      • bpavuk 8mo ago
        ...and waste valuable time reviewing AI slop? it looks surprisingly plausible, but never integrates with the bigger picture.
      • 8mo ago
• dom96 8mo ago
  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.
  • 3371 8mo ago
    Well a lot of useful things are not useful because they are innovative, but well designed an executed.
  • rvz 8mo ago
    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.
    • verdverm 8mo ago
      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?
      • Rumple22Stilk 8mo ago
        That's the whole point. There are many new adopters and few competent ones.
        • verdverm 8mo ago
          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
          • acedTrex 8mo ago
            These projects would rather miss out on a few good people to stop the bad ones over the alternative.
• jprosevear 8mo ago
  Prior art? https://en.wikipedia.org/wiki/Advogato https://en.wikipedia.org/wiki/Advogato
  • Aachen 8mo ago
    > 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
• HiPhish 8mo ago
  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.
  • zozbot234 8mo ago
    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!"
    • HiPhish 8mo ago
      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?).
      • 8mo ago
• adeebshihadeh 8mo ago
  "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 https://github.com/commaai/openpilot)
  • rafram 8mo ago
    [flagged]
    • latency-guy2 8mo ago
      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.
    • BowBun 8mo ago
      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.
      • deleted 8mo ago
        [deleted]
      • 8n4vidtmkvmk 8mo ago
        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.
        • colinmcdermott 8mo ago
          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
• BiteCode_dev 8mo ago
  Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.
  • jen20 8mo ago
    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.
    • BiteCode_dev 8mo ago
      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-administration-fined-for-fraud-blacklist?utm_source=chatgpt.com 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.
      • jen20 8mo ago
        > 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.
• deleted 8mo ago
  [deleted]
• 1a527dd5 8mo ago
  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.
  • acjohnson55 8mo ago
    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.
    • ncr100 8mo ago
      IDK about this implementation ... OVER-Denouncing ought to be tracked, too, for a user's trustworthiness profile.
      • acjohnson55 8mo ago
        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.
  • mjr00 8mo ago
    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.
• rvz 8mo ago
  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.
• Halan 8mo ago
  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.
  • qmarchi 8mo ago
    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.
    • Halan 8mo ago
      So basically we are back at tagging stuff as good for first contributors like we have been doing since the dawn of GitHub
  • arcologies1985 8mo ago
    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)
  • buovjaga 8mo ago
    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.
    • swordsith 8mo ago
• rcakebread 8mo ago
  Who trusts people who still use X?
  • jimmaswell 8mo ago
    I still prefer it to Wayland for various reasons, and I don't think Wayland would work properly on my mid 2010 Macbook anyway.
    • dedzycide 8mo ago
      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/0c42252d8951ac338fe9d80d45ea912e0b956993/machines/vm-shared.nix#L115 https://github.com/mitchellh/nixos-config/blob/0c42252d8951a...
  • archagon 8mo ago
    Exactly. Poor judgement on the author’s part.
• mehdibl 8mo ago
  Why in nushell? Not in go? But I like the idea and principle. OSS need this and it's traded very lightly.
  • tristan957 8mo ago
    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.
• sunir 8mo ago
  Reminds me fondly of advogato.
• treeshateorcs 8mo ago
  this wouldn't have helped against the xz attack
  • jen20 8mo ago
    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.
• rorylaitila 8mo ago
  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.
  • the_biot 8mo ago
    That's what I thought of right away as well. We may end up with a blacklist of "known AI slop peddlers".
• WhereIsTheTruth 8mo ago
  Replacing merit with social signaling.. ..sigh.. The enshitification of GitHub continues
• baq 8mo ago
  Central karma database next, please. Vouch = upvote, denounce = downvote
• kfogel 8mo ago
  Can't believe they didn't call it VouchDB.
• danilocesar 8mo ago
  Wait until he finds out about GPG signing parties in the early 2000s.
• andai 8mo ago
  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.
  • k8sToGo 8mo ago
    If you want me to read your comment, please pay me $1 first... if I find your comment interesting I might refund.
    • hermanb 8mo ago
      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.
      • Fnoord 8mo ago
        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...
        • TurdF3rguson 8mo ago
          Yeah I remember this from "The Road Ahead" which I chanced upon one time in the 90s. I thought it was a silly idea.
      • zx8080 8mo ago
        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.
• femto113 8mo ago
  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.
  • tgsovlerkhgsel 8mo ago
    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.
    • btown 8mo ago
      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 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 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?
• nmstoker 8mo ago
  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?
• nabilsaikaly 8mo ago
  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.
  • tedk-42 8mo ago
    This adds friction, disincentivizes legitimate and high quality code commits and uses humans even more.
    • otterley 8mo ago
      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.
• mijoharas 8mo ago
  > 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.)
• ctoth 8mo ago
  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.
  • WatchDog 8mo ago
    > 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.
    • ctoth 8mo ago
      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.
  • defen 8mo ago
    "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.
• mijoharas 8mo ago
  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.
  • yencabulator 8mo ago
    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.
    • dlahoda 8mo ago
      may be it improved? when you last time tried?
      • yencabulator 8mo ago
        The issues are still open. https://news.ycombinator.com/item?id=46535621 https://news.ycombinator.com/item?id=46535621
  • dlahoda 8mo ago
    he seems like dislikes go and rust. and likely ts. go and ts were fully legit for such work. zig is too low level.
  • mijoharas 8mo ago
    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 https://x.com/mitchellh/status/1907849319052386577
• a-dub 8mo ago
  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.
  • bicx 8mo ago
    I guess you could say the same about a lot of craft- or skill-based professions that ultimately got heavily automated.
  • potsandpans 8mo ago
    > 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.
  • boltzmann-brain 8mo ago
    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 https://news.ycombinator.com/item?id=46938811
    • a-dub 8mo ago
      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.
      • tolerance 8mo ago
        You could argue that this could increase output to the open web: outsiders still need a place to clout chase.
        • 8mo ago
• otterley 8mo ago
  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!
  • mmooss 8mo ago
    > forge-based ?
    • kortex 8mo ago
• readitalready 8mo ago
  Is this social credit?
• smileson2 8mo ago
  feels very micromanagement-ish
• brikym 8mo ago
  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.
• tmp10423288442 8mo ago
  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.
  • mhuffman 8mo ago
    >What's the plan to avoid a Bluesky-like bubble from forming around Vouch projects? Perhaps that is the plan?
  • dayvid 8mo ago
    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.
  • dcre 8mo ago
    “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 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.
    • gruez 8mo ago
      >At this point it would make sense to say this is just how Bluesky grows. >https://bsky.jazco.dev/stats 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".
• sebastianconcpt 8mo ago
  https://www.lewissociety.org/innerring/ https://www.lewissociety.org/innerring/
• larodi 8mo ago
  After the economy of attention, no things enter the economy of trust.
• Yizahi 8mo ago
  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.
• max_ 8mo ago
  If you like this, you may love Robin Hansons similar idea of vouching [0] [0]: https://www.youtube.com/watch?v=rPdHXw05SvU https://www.youtube.com/watch?v=rPdHXw05SvU
• kleyd 8mo ago
  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.
  • Tossrock 8mo ago
    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.
• Fnoord 8mo ago
  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.
  • hedora 8mo ago
    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.
• tokyobreakfast 8mo ago
  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?
• fallat 8mo ago
  Sibil attack in 3...2...1....
• p4cmanus3r 8mo ago
  I love the idea, but it's going to be cancelled for sure.
• fcantournet 8mo ago
  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.
  • wayeq 8mo ago
    did you have any actual criticism?
  • Bayko 8mo ago
    cons to YOU outway the pros. pros to HIM outway the cons.
  • dang 8mo ago
    "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 https://news.ycombinator.com/newsguidelines.html
• cyberrock 8mo ago
  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
• throwaway020826 8mo ago
  > vouch denounce badactor [--reason str] Simple as. He who is without sin can cast the first stone.
• 0xbadcafebee 8mo ago
  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.
• gdiamos 8mo ago
  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.
• chillingeffect 8mo ago
  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.
• VerifiedReports 8mo ago
  Is what?
• freakynit 8mo ago
  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.
  • stavros 8mo ago
    How is that different from what happens now, where someone who contributes regularly to a project faces less scrutiny than a new person?
    • freakynit 8mo ago
      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.
      • stavros 8mo ago
        This isn't a centralised reputation system, though, is it? Each project keeps its own whitelist.
        • freakynit 8mo ago
          Thats's true.
      • october8140 8mo ago
        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.
        • 8mo ago
• briandoll 8mo ago
  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.
• fouc 8mo ago
  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-the-internet-with-hate/ https://weblog.masukomi.org/2018/03/25/zed-shaws-utu-saving-... https://savingtheinternetwithhate.com/ https://savingtheinternetwithhate.com/ DEFCON presentation: https://www.youtube.com/watch?v=ziTMh8ApMY4 https://www.youtube.com/watch?v=ziTMh8ApMY4
• hedora 8mo ago
  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.
  • TheTaytay 8mo ago
    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...
    • hedora 8mo ago
      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.
  • deleted 8mo ago
    [deleted]
  • chasd00 8mo ago
    > 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.
• Verlyn139 8mo ago
  [dead]
• hedora 8mo ago
  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”
• sbr464 8mo ago
  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
  • __float 8mo ago
    Sometimes political views should actually get you shunned. You're always free to create a fork.
    • sbr464 8mo ago
      And this is why it needs a reason/ban rule. You guys simply can’t help yourselves.
    • booleandilemma 8mo ago
      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.
      • habinero 8mo ago
        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.
        • deleted 8mo ago
          [deleted]
  • bccdee 8mo ago
    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.
• sbr464 8mo ago
  Unfortunately, the mob mentality, and gate keeping from the Reddit mod era, proves that these types of systems simply don’t work.
  • energy123 8mo ago
    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.
  • tayo42 8mo ago
    i think you can go earlier then that. reminds me kind of rep systems on message boards. which got abused.
  • johnnyanmac 8mo ago
    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.
  • nobleach 8mo ago
    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".
• dmitrijbelikov 8mo ago
  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.
• solaire_oa 8mo ago
  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.
• emeraudelinton 8mo ago
  [dead]
• burnt-resistor 8mo ago
  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.
  • throwaway2037 8mo ago
    How can you "limit AI-based interactions"? Also, is there any "platform that penalizes AI properly at its source"?
• pstuart 8mo ago
  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.
• jcattle 8mo ago
  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
  • bjt 8mo ago
    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.
• dncnmcdougall 8mo ago
  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?
  • Naracion 8mo ago
    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-commands 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.
• no_circuit 8mo ago
  Why stop at restricting pull requests? I wouldn't want spam issues either. New issues and contributors should be gated at the "discussion" stage.
• Aachen 8mo ago
  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#vouched-file-format https://github.com/mitchellh/vouch?tab=readme-ov-file#vouche...
• jeffybefffy519 8mo ago
  Is this a privacy nightmare because it exposes graphs of people together publicly?
• theredbeard 8mo ago
  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.
  • monegator 8mo ago
    let's make it even better: why not set up a donation mechanism to get in the list?
    • theredbeard 8mo ago
      What could go wrong?!
    • nananana9 8mo ago
      Because I want people to get paid for writing code, not to pay to write code.
      • monegator 8mo ago
        my bad, forgot to /s
        • theredbeard 8mo ago
          No worries, the italics did heavy lifting.
  • bootsmann 8mo ago
    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.
• VadimPR 8mo ago
  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.
• rcmuir 8mo ago
  At first, this concept looked so cool, to solve a real problem! But then the actions implementation starts with "pull_request_target" :(
• __alexs 8mo ago
  I will never contribute to a project that runs on this sort of ridiculous popularity contest system.
  • femiagbabiaka 8mo ago
    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.
    • __alexs 8mo ago
      Yeah but I get paid for that.
• atticus_ 8mo ago
  I think its crazy that a single person thinks so much of themselves to create this under their name
  • drewbailey 8mo ago
    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?
• JimmaDaRustla 8mo ago
  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.
• winfortheworld 8mo ago
  Is codeowners lacking features to implement this?
  • quadrifoliate 8mo ago
    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.
• WhiteOwlLion 8mo ago
  What about HashCash, where proof of work increases with more pull requests from a user ID? Beyond typical submission frequency, proof-of-work would become exponentially more difficult to prevent spam, helping to keep the riff-raff out. Doesn't require money, just computing power. https://en.wikipedia.org/wiki/Hashcash https://en.wikipedia.org/wiki/Hashcash If HiveCoin were still around, we could donate the hashing power to some tech-related non-profit.
• jeffreysmith 8mo ago
  I think this is really a key problem to solve, but I couldn't convince myself that it was the right solution. So, I put up my alternative proposal, Good Egg: https://github.com/2ndSetAI/good-egg https://github.com/2ndSetAI/good-egg Key differences: - Based on commit history, with nuance around relatedness of projects, types of projects, age, etc. - Requires no ongoing work. Just add it to your GH Actions CI. - Agent ready with an MCP interface, Python lib, and CLI Discussion on HN here: https://news.ycombinator.com/item?id=46960412 https://news.ycombinator.com/item?id=46960412 Feedback and PRs welcome.
• tom_m 8mo ago
  This is essentially the death of open-source software. I understand that projects will probably get floods of PRs and such given how easy it is to do stuff with AI now... And maybe it's AI that is to blame for it all. That's fair. But no good will come of this strategy. I think it's even possible that we will see a massive stall in innovation now.