[HN Gopher] Vouch
___________________________________________________________________
Vouch
https://x.com/mitchellh/status/2020252149117313349
https://nitter.net/mitchellh/status/2020252149117313349
https://github.com/ghostty-org/ghostty/pull/10559
Author : chwtutha
Score : 1041 points
Date : 2026-02-08 03:09 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| davidkwast wrote:
| I think LLMs are accelerating us toward a Dune-like universe,
| where humans come before AI.
| ashton314 wrote:
| 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 wrote:
| Close, but it's "Butlerian". Easy to remember if you know
| it's named after Samuel Butler.
|
| https://en.wikipedia.org/wiki/Erewhon
| Rumple22Stilk wrote:
| The alternative is far far worse.
| SJC_Hacker wrote:
| 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 wrote:
| 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_ wrote:
| Hope github can natively integrate something in the platform, a
| relevant discussion I saw on official forums:
| https://github.com/orgs/community/discussions/185387
| matthewisabel wrote:
| 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-...
| cedws wrote:
| 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.
| sanufar wrote:
| 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 wrote:
| 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.
| alexjurkiewicz wrote:
| 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.
| javascripthater wrote:
| 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 wrote:
| Identity is a lot easier than forward trustworthiness. It can
| succeed for the former and fail for the latter.
| Animats wrote:
| > 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 wrote:
| I guess this is why Sam Altman wants to scan everyone's
| eyeballs.
| chickensong wrote:
| 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.
| pyrolistical wrote:
| Another way to solve this is how Linux organizes. Tree structure
| where lower branches vet patches and forward them up when ready
| stephantul wrote:
| 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__ wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| Look at ERC-8004
| HumanOstrich wrote:
| 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.
| tempaccount420 wrote:
| Well done, you managed to tie Rust, Nix, Haskell and OCaml
| to "extremely complex, wasteful, and unusable"
| refulgentis wrote:
| Zig can fix this, I'm sure.
| Bayko wrote:
| Boring Java dev here. Do I just sit this one out?
| drewstiff wrote:
| 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/
| throwaway2037 wrote:
| I'm confused. Why do I need "reputation within the crypto
| ecosystem"? If I want to trade it, I use an exchange, like
| Binance.
| joecool1029 wrote:
| > 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)
| buckle8017 wrote:
| Biggest issue was always the fiat transfers.
| nine_k wrote:
| 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.
| JoshTriplett wrote:
| > 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.
| atmosx wrote:
| Sounds like a black mirror episode.
| moodyScarf wrote:
| isnt that like literally the plot in one of the episodes?
| where they get a x out of 5 rating that is always visble.
| atmosx wrote:
| Yes, there is one that is pretty close to this scenario.
| refulgentis wrote:
| 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)
| ashton314 wrote:
| 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! :)
| kjs3 wrote:
| Both sides of the equation can be gamed. This has always been
| the issue with reputation systems.
| OkayPhysicist wrote:
| 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.
| ares623 wrote:
| 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.
| skeptic_ai wrote:
| 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.
| zbentley wrote:
| 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".
| dzink wrote:
| 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.
| pphysch wrote:
| 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.
| mlinsey wrote:
| > 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.
| JumpCrisscross wrote:
| > _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.)
| ashton314 wrote:
| 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 wrote:
| Man, I'm a huge fan of Anathem (and Stephenson in general) but
| this short excerpt really reminded me of https://xkcd.com/483/
| renewiltord wrote:
| 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.
| CamperBob2 wrote:
| 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.
| ashton314 wrote:
| 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.
| jemfinch wrote:
| Is this the return of Advogato?
| whalesalad wrote:
| We got social credit on GitHub before GTA 6.
| ashton314 wrote:
| Fediverse link:
| https://fosstodon.org/@mitchellh@hachyderm.io/11603152931120...
| skeptrune wrote:
| 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 wrote:
| 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 wrote:
| Why isn't the link directly to the github repository[1]?
|
| [1]: https://github.com/mitchellh/vouch
| tmvnty wrote:
| 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...
| bmitch3020 wrote:
| 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 wrote:
| So you're screwed if you don't have any connections. In that way
| it's just like meat space.
| eightnoteight wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| Nobody is screwed in the Ghostty project. Simply open a
| discussion to discuss your idea.
| Zambyte wrote:
| 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.
| throwaway2037 wrote:
| 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.
| archagon wrote:
| 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 wrote:
| Isn't it extremely difficult problem? It's very easy to game,
| vouch 1 entity that will invite lots of bad actors
| DJBunnies wrote:
| Indeed, it's relatively impossible without ties to real world
| identity.
| mjr00 wrote:
| > 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 wrote:
| That's not the point.
|
| Point is: when @lt100, @lt101, ... , @lt999 all vouch for
| something, it's worthless.
| jen20 wrote:
| But surely then a maintainer notices what has happened,
| and resolves the problem?
| Dylan16807 wrote:
| Real world identity isn't sufficient or necessary to
| solve that problem.
| OkayPhysicist wrote:
| 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.
| smotched wrote:
| you can't really build a perfect system, the goal would be to
| limit bad actors as much as possible.
| dboon wrote:
| 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.
| anupamchugh wrote:
| > 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.
| hobofan wrote:
| Then you would just un-vouch them? I don't see how its easy to
| game on that front.
| Yizahi wrote:
| 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 :)
| speps wrote:
| 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.
| supriyo-biswas wrote:
| 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.
| iugtmkbdfil834 wrote:
| 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.
| Yizahi wrote:
| 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.
| bsimpson wrote:
| 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?
| 63stack wrote:
| You are not supposed to vouch for strangers, system working
| as intended.
| mjr00 wrote:
| 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.
| jillesvangurp wrote:
| 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.
| IshKebab wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| Love seeing some nushell usage!
| aatd86 wrote:
| Does is overlap with Contributor License Agreement?
| quotemstr wrote:
| Fortunately, as long as software is open sourced, forking will
| remain a viable way to escape overzealous gatekeeping.
| skeeter2020 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| ...and waste valuable time reviewing AI slop? it looks
| surprisingly plausible, but never integrates with the
| bigger picture.
| mjr00 wrote:
| 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
| zozbot234 wrote:
| 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.
| michaelt wrote:
| 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.
| verdverm wrote:
| > Particularly in the last ~10 years ...
|
| This is maturation, open source being professional is a good
| sign for the future
| zbentley wrote:
| 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.
| mjr00 wrote:
| 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
| zozbot234 wrote:
| 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.
| jack_pp wrote:
| One problem with giving any feedback is that it can
| automatically be used by an agent to make another PR.
| zozbot234 wrote:
| 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.
| mjr00 wrote:
| 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.
| zozbot234 wrote:
| 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.
| dom96 wrote:
| 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 wrote:
| Well a lot of useful things are not useful because they are
| innovative, but well designed an executed.
| ramses0 wrote:
| 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
| rvz wrote:
| 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 wrote:
| 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 wrote:
| That's the whole point. There are many new adopters and few
| competent ones.
| verdverm wrote:
| 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 wrote:
| These projects would rather miss out on a few good people
| to stop the bad ones over the alternative.
| verdverm wrote:
| 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
| tristan957 wrote:
| The barrier in the Ghostty project is to simply open a
| discussion. It's not really hard.
| verdverm wrote:
| 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?
| kjs3 wrote:
| And...that's bad?
| freakynit wrote:
| Not until you are wrongly considered "untrusted".
| d-us-vb wrote:
| 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.
| jprosevear wrote:
| Prior art? https://en.wikipedia.org/wiki/Advogato
| Aachen wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?).
| MarkusQ wrote:
| 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.
| Loughla wrote:
| The ones I've never understood are: Prompt payment. Great
| buyer.
|
| I can't check out unless I pay. How is that feedback?
| HiPhish wrote:
| 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.
| jcattle wrote:
| 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).
| layer8 wrote:
| 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.
| zbentley wrote:
| 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.
| jcattle wrote:
| 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.
| pixl97 wrote:
| >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.
| pwdisswordfishs wrote:
| > 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.
| stavros wrote:
| 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".
| pwdisswordfishs wrote:
| 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.
| stavros wrote:
| People aren't on Github _just_ to implement reputation-
| based management, though.
| pwdisswordfishs wrote:
| What does that observation have to do with the topic
| under the microscope?
| stavros wrote:
| > 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.
| rtpg wrote:
| 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
| adeebshihadeh wrote:
| "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)
| rafram wrote:
| [flagged]
| latency-guy2 wrote:
| 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 wrote:
| 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.
| 8n4vidtmkvmk wrote:
| 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 wrote:
| 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
| adeebshihadeh wrote:
| 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.
| stavros wrote:
| I'm not sure there are many ways to interpret "I know
| whether I want to merge a PR within a few seconds".
| jeremyjh wrote:
| Yet I also agree with GP.
| theshrike79 wrote:
| "*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.
| ngcazz wrote:
| When there's time, you review, when there isn't you trust...
| 999900000999 wrote:
| 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.
| stavros wrote:
| What is the definition of trust if you still have to
| verify? How does "trust" differ from "untrust" in that
| scenario?
| johnnyanmac wrote:
| 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.
| adeebshihadeh wrote:
| What's the rush? Building good things takes time.
| johnnyanmac wrote:
| deadlines, money, attention. The usual things in industry.
| jgauth wrote:
| 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.
| BiteCode_dev wrote:
| Illegal in europe. You are bot allowed to keep a black list of
| people with the exception of some criminal situations or
| addiction.
| jen20 wrote:
| 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 wrote:
| 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.
| jen20 wrote:
| > 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.
| 1a527dd5 wrote:
| 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 wrote:
| 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 wrote:
| IDK about this implementation ...
|
| OVER-Denouncing ought to be tracked, too, for a user's
| trustworthiness profile.
| acjohnson55 wrote:
| 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 wrote:
| 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.
| Rapzid wrote:
| 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.
| mmooss wrote:
| 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.
| rvz wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| So basically we are back at tagging stuff as good for first
| contributors like we have been doing since the dawn of GitHub
| arcologies1985 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| Fogest wrote:
| 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.
| buovjaga wrote:
| 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.
| lelandbatey wrote:
| 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.
| anon291 wrote:
| 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.
| mordnis wrote:
| 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.
| rcakebread wrote:
| Who trusts people who still use X?
| jimmaswell wrote:
| 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 wrote:
| 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...
| archagon wrote:
| Exactly. Poor judgement on the author's part.
| sunir wrote:
| Reminds me fondly of advogato.
| treeshateorcs wrote:
| this wouldn't have helped against the xz attack
| jen20 wrote:
| 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 wrote:
| 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 wrote:
| That's what I thought of right away as well. We may end up with
| a blacklist of "known AI slop peddlers".
| WhereIsTheTruth wrote:
| Replacing merit with social signaling.. ..sigh..
|
| The enshitification of GitHub continues
| mehdibl wrote:
| Why in nushell? Not in go?
|
| But I like the idea and principle. OSS need this and it's traded
| very lightly.
| tristan957 wrote:
| 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.
| baq wrote:
| Central karma database next, please. Vouch = upvote, denounce =
| downvote
| kfogel wrote:
| Can't believe they didn't call it VouchDB.
| danilocesar wrote:
| Wait until he finds out about GPG signing parties in the early
| 2000s.
| andai wrote:
| 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 wrote:
| If you want me to read your comment, please pay me $1 first...
| if I find your comment interesting I might refund.
| hermanb wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Dylan16807 wrote:
| 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.
| zx8080 wrote:
| Emails to CEOs they do worth.
| Dylan16807 wrote:
| 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".
| AnthonyMouse wrote:
| 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.
| SJC_Hacker wrote:
| > 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
| AnthonyMouse wrote:
| 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?
| nobody9999 wrote:
| >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.
| SJC_Hacker wrote:
| 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.
| Dylan16807 wrote:
| > 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?
| jt2190 wrote:
| The market currently values your reading of HN comments at
| $0.
| AlexCoventry wrote:
| I'm sure astroturfers value it more highly than that.
| vasco wrote:
| The only way for you to be sure of that is if you're one.
| johnnyanmac wrote:
| I'm sure there's literature out there on how much
| astroturfers are paid.
| Bewelge wrote:
| > 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.
| lelandbatey wrote:
| 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 10C/
| make that initial text message/phone call, then the next 5
| messages are 1C/ 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.
| Bewelge wrote:
| 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.
| ramon156 wrote:
| 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).
| kurtis_reed wrote:
| You get it refunded
| Nevermark wrote:
| 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).
| zx8080 wrote:
| $10 will be a honeypot for scammers.
| Nevermark wrote:
| 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.
| sdenton4 wrote:
| 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.
| johnnyanmac wrote:
| >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.
| Fnoord wrote:
| 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.
| strken wrote:
| 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%.
| Bayko wrote:
| 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?!
| strken wrote:
| 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.
| johnnyanmac wrote:
| 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.
| Plasmoid wrote:
| 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...)
| csomar wrote:
| I suspect most of these people are not software engineers
| with a computer?
| Fnoord wrote:
| 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.
| johnnyanmac wrote:
| >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.
| balgg wrote:
| So only employed software developers are allowed to make
| PRs?
| necovek wrote:
| 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.
| Fnoord wrote:
| 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.
| account42 wrote:
| 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.
| _puk wrote:
| 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.
| nl wrote:
| 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.
| rifty wrote:
| 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.
| nl wrote:
| 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.
| rifty wrote:
| Ahh, I see now the angle you were coming at it from, my
| wrong!
| AnthonyMouse wrote:
| > 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.
| nl wrote:
| 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.
| AnthonyMouse wrote:
| 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.
| nl wrote:
| 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)
| Karrot_Kream wrote:
| 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.
| AnthonyMouse wrote:
| 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.
| satvikpendem wrote:
| But it could just be made a stablecoin.
| SR2Z wrote:
| 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.
| backscratches wrote:
| 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...
| weedhopper wrote:
| The greed has ruined it, and the greed and desperation to
| get rich at all costs keeps it alive.
| backscratches wrote:
| 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.
| AlexCoventry wrote:
| > because crypto brings money so close to engineering it
| corrupts good product design.
|
| Amen.
| oofbey wrote:
| No. Just because you can use crypto for something doesn't
| mean you should. In fact you almost never should.
| miki123211 wrote:
| 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.
| boltzmann-brain wrote:
| > 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.
| sethammons wrote:
| 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"
| MichaelZuo wrote:
| 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.
| Wowfunhappy wrote:
| > 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.
| cortesoft wrote:
| > 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.
| awestroke wrote:
| I see no advantage with this over real money transfers. At
| all. Just use some kind of escrow.
| Hendrikto wrote:
| 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.
| chairmansteve wrote:
| "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.
| account42 wrote:
| 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.
| anonymousab wrote:
| 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.
| KawaiiCyborg wrote:
| > "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...
| mring33621 wrote:
| Nope. From the POV of the maintainer, you are creating
| extra, and probably unnecessary, work for them.
| KawaiiCyborg wrote:
| 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.
| wongarsu wrote:
| 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.
| kaicianflone wrote:
| 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.
| bastawhiz wrote:
| 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.
| zahrevsky wrote:
| 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.
| hamasho wrote:
| But one way to get better at communication is try and error.
| This solution makes trying much harder, and eventually leads
| less good communicators.
| tonymet wrote:
| 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.
| spruce_tips wrote:
| 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!
| kurtis_reed wrote:
| Please do share!
| Quizzical4230 wrote:
| Yes please!
| chasd00 wrote:
| 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.
| crazygringo wrote:
| 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.
| vasco wrote:
| 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
| chmod775 wrote:
| > 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.
| unfunco wrote:
| 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?
| tehlike wrote:
| There are a lot of _free_ models on opencode.
| geysersam wrote:
| 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.
| lejalv wrote:
| In fact, we can use an automated schedule: first PR - if
| rejected, 5EUR are drawn from the contributor's account, then
| 4EUR, 3EUR, etc (plug in your favourite decreasing function,
| round to 0EUR when sufficiently close).
|
| But, crucially, if accepted, the contributor gets to draw
| 5EUR 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.
| johnnyanmac wrote:
| >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.
| phantomathkg wrote:
| 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.
| collingreen wrote:
| Which is true now as well, but at least the cost is more than
| zero
| johnnyanmac wrote:
| 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".
| KronisLV wrote:
| > 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.
| boltzmann-brain wrote:
| 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.
| weli wrote:
| $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.
| poulpy123 wrote:
| I don't like this idea but the people unable to afford $1
| don't have time to propose PR
| lobsterthief wrote:
| That's not true--it depends entirely on the country..
| weli wrote:
| 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.
| poulpy123 wrote:
| You're right, I'm fortunate enough to not have this
| experience. But not only both food and gas are much more
| than 1EUR, but also people in this situation are too
| focused on finding a way to make money to care about
| submitting merge requests
| elxr wrote:
| Plenty of teens in poorer countries actively devoting a lot
| of time to practicing programming. $1 is _a lot_ for a PR.
| femto113 wrote:
| _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 wrote:
| 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 wrote:
| 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?
| tgsovlerkhgsel wrote:
| 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.
| johnnyanmac wrote:
| 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).
| stavros wrote:
| 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?
| theshrike79 wrote:
| 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.
| mitchellh wrote:
| 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.
| AlexCoventry wrote:
| Did you experiment with getting an AI to critique incoming
| PRs, and ignoring ones where it finds clear red flags?
| Fnoord wrote:
| 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.
| javier123454321 wrote:
| Yeah, as that's a different problem unrelated to the problem
| that this is trying to solve.
| akerl_ wrote:
| > 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/
| nmstoker wrote:
| 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 wrote:
| 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 wrote:
| This adds friction, disincentivizes legitimate and high quality
| code commits and uses humans even more.
| otterley wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| may be it improved? when you last time tried?
| yencabulator wrote:
| The issues are still open.
| https://news.ycombinator.com/item?id=46535621
| dlahoda wrote:
| 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 wrote:
| 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
| a-dub wrote:
| 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 wrote:
| I guess you could say the same about a lot of craft- or skill-
| based professions that ultimately got heavily automated.
| potsandpans wrote:
| > 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 wrote:
| 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
| a-dub wrote:
| 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 wrote:
| You could argue that this could increase output to the open
| web: outsiders still need a place to clout chase.
| boltzmann-brain wrote:
| 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.
| yencabulator wrote:
| .. all revolving around a proprietary Microsoft service.
|
| Support Microsoft or be socially shunned?
| mitchellh wrote:
| 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).
| yencabulator wrote:
| 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.
| mitchellh wrote:
| 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.
| potsandpans wrote:
| I would rather stop contributing to open source rather than
| interact with your gatekeeping social experiment.
| mitchellh wrote:
| That's fine and doesn't bother me one bit.
| potsandpans wrote:
| Tracks. You don't care about the open source community.
| mitchellh wrote:
| No, that's quite a jump. I just respect whatever your
| preferences are.
| cyanydeez wrote:
| argueably, the years 2015-2020, we should have gone back to
| social standing.
| siva7 wrote:
| 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.
| senko wrote:
| 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
| patcon wrote:
| 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
| otterley wrote:
| 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 wrote:
| > forge-based
|
| ?
| kortex wrote:
| Almost certainly referring to a software forge:
| https://en.wikipedia.org/wiki/Forge_(software)
| bccdee wrote:
| 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.
| readitalready wrote:
| Is this social credit?
| smileson2 wrote:
| feels very micromanagement-ish
| brikym wrote:
| 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 wrote:
| 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 wrote:
| >What's the plan to avoid a Bluesky-like bubble from forming
| around Vouch projects?
|
| Perhaps that is the plan?
| dayvid wrote:
| 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 wrote:
| "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.
| gruez wrote:
| >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".
| dcre wrote:
| That's what I said: it's technically true but misleading.
| Barrin92 wrote:
| >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.
| logicprog wrote:
| 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.
| beepbooptheory wrote:
| What does "interested in political effectiveness" mean? Like as
| opposed to ineffectiveness? Is it like bluesky is really
| libertarian now or something?
| definethatforus wrote:
| > as people interested in political effectiveness
|
| Ah, the giant enemy crab shows its weakpoint. This is where the
| mask cracks.
| sebastianconcpt wrote:
| https://www.lewissociety.org/innerring/
| larodi wrote:
| After the economy of attention, no things enter the economy of
| trust.
| Yizahi wrote:
| 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_ wrote:
| If you like this, you may love Robin Hansons similar idea of
| vouching [0]
|
| [0]: https://www.youtube.com/watch?v=rPdHXw05SvU
| kleyd wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Sibil attack in 3...2...1....
| p4cmanus3r wrote:
| I love the idea, but it's going to be cancelled for sure.
| fcantournet wrote:
| 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 wrote:
| did you have any actual criticism?
| Bayko wrote:
| cons to YOU outway the pros. pros to HIM outway the cons.
| dang wrote:
| " _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
| cyberrock wrote:
| 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 wrote:
| > vouch denounce badactor [--reason str]
|
| Simple as. He who is without sin can cast the first stone.
| 0xbadcafebee wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Is what?
| freakynit wrote:
| 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 wrote:
| How is that different from what happens now, where someone who
| contributes regularly to a project faces less scrutiny than a
| new person?
| freakynit wrote:
| 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 wrote:
| This isn't a centralised reputation system, though, is it?
| Each project keeps its own whitelist.
| freakynit wrote:
| Thats's true.
| october8140 wrote:
| 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.
| freakynit wrote:
| 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.
| anon-3988 wrote:
| 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.
| freakynit wrote:
| 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.
| bccdee wrote:
| 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.
| aragilar wrote:
| Would it not be better to report accounts then?
| bccdee wrote:
| 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.
| Goofy_Coyote wrote:
| 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?
| freakynit wrote:
| 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)
| anon-3988 wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| stickfigure wrote:
| 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.
| freakynit wrote:
| 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.
| briandoll wrote:
| 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 wrote:
| 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
| hedora wrote:
| 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 wrote:
| 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 wrote:
| 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.
| chasd00 wrote:
| > 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.
| 8organicbits wrote:
| 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.
| hedora wrote:
| 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 wrote:
| Unfortunately, the mob mentality, and gate keeping from the
| Reddit mod era, proves that these types of systems simply don't
| work.
| energy123 wrote:
| 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 wrote:
| i think you can go earlier then that. reminds me kind of rep
| systems on message boards. which got abused.
| johnnyanmac wrote:
| 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 wrote:
| 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".
| sbr464 wrote:
| 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 wrote:
| Sometimes political views should actually get you shunned.
|
| You're always free to create a fork.
| sbr464 wrote:
| And this is why it needs a reason/ban rule. You guys simply
| can't help yourselves.
| booleandilemma wrote:
| 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.
| bccdee wrote:
| 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.
| dmitrijbelikov wrote:
| 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 wrote:
| 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.
| burnt-resistor wrote:
| 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 wrote:
| How can you "limit AI-based interactions"? Also, is there any
| "platform that penalizes AI properly at its source"?
| pstuart wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| no_circuit wrote:
| 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 wrote:
| I've thought about making such a system before, but never
| considered making it a single flat file1. 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
|
| 1 https://github.com/mitchellh/vouch?tab=readme-ov-file#vouche...
| jeffybefffy519 wrote:
| Is this a privacy nightmare because it exposes graphs of people
| together publicly?
| theredbeard wrote:
| 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 wrote:
| let's make it even better: why not set up a _donation_
| mechanism to get in the list?
| theredbeard wrote:
| What could go wrong?!
| nananana9 wrote:
| Because I want people to get paid for writing code, not to
| pay to write code.
| monegator wrote:
| my bad, forgot to /s
| theredbeard wrote:
| No worries, the italics did heavy lifting.
| bootsmann wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| mrguyorama wrote:
| >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.
| iamrobertismo wrote:
| 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.
| MattGrommes wrote:
| 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.
| everforward wrote:
| 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.
| VadimPR wrote:
| 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 wrote:
| At first, this concept looked so cool, to solve a real problem!
|
| But then the actions implementation starts with
| "pull_request_target" :(
| __alexs wrote:
| I will never contribute to a project that runs on this sort of
| ridiculous popularity contest system.
| femiagbabiaka wrote:
| 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 wrote:
| Yeah but I get paid for that.
| atticus_ wrote:
| I think its crazy that a single person thinks so much of
| themselves to create this under their name
| drewbailey wrote:
| 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 wrote:
| 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 wrote:
| Is codeowners lacking features to implement this?
| quadrifoliate wrote:
| 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.
___________________________________________________________________
(page generated 2026-02-09 23:01 UTC)