NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
Vouch (github.com)
stephantul 14 hours ago [-]
IMO: trust-based systems only work if they carry risk. Your own score should be linked to the people you "vouch for" or "denounce".

This is similar to real life: if you vouch for someone (in business for example), and they scam them, your own reputation suffers. So vouching carries risk. Similarly, if you going around someone is unreliable, but people find out they actually aren't, your reputation also suffers. If vouching or denouncing become free, it will become too easy to weaponize.

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

mlinsey 8 minutes ago [-]
> 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.

ashton314 13 hours ago [-]
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.

Good reason to be careful. Maybe there's a bit of an upside to: if you vouch for someone who does good work, then you get a little boost too. It's how personal relationships work anyway.

----------

I'm pretty skeptical of all things cryptocurrency, but I've wondered if something like this would be an actually good use case of blockchain tech…

nine_k 8 minutes ago [-]
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.
joecool1029 30 minutes ago [-]
> 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 21 minutes ago [-]
Biggest issue was always the fiat transfers.
HumanOstrich 13 hours ago [-]
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 14 minutes ago [-]
Well done, you managed to tie Rust, Nix, Haskell and OCaml to "extremely complex, wasteful, and unusable"
drewstiff 10 hours ago [-]
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/

smoyer 13 hours ago [-]
Look at ERC-8004
__turbobrew__ 13 hours ago [-]
> Then again, if this is the case, why would you risk your own reputation to vouch for anyone anyway.

Maybe your own vouch score goes up when someone you vouched for contributes to a project?

skeptic_ai 11 hours ago [-]
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 12 minutes ago [-]
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”.

ares623 12 hours ago [-]
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.

adeebshihadeh 1 hours ago [-]
"Open source has always worked on a system of trust and verify"

Not sure about the trust part. Ideally, you can evaluate the change on its own.

In my experience, I immediately know whether I want to close or merge a PR within a few seconds, and the hard part is writing the response to close it such that they don't come back again with the same stuff.

(I review a lot of PRs for openpilot - https://github.com/commaai/openpilot)

ngcazz 6 minutes ago [-]
When there's time, you review, when there isn't you trust...
rafram 54 minutes ago [-]
> In my experience, I immediately know whether I want to close or merge a PR within a few seconds

Not sure this is what I want to hear about a system that people entrust their lives to on the highway…

BowBun 27 minutes ago [-]
Why? I don't appreciate comments that cast doubt on decent technical contributors without any substance to back it up. It's a cheap shot from anonymity.
8n4vidtmkvmk 10 minutes ago [-]
I'm not the parent but if you know you want to merge a PR "within a few seconds" then you're likely to be merging in bad changes.

If you had left it at know you want to reject a PR within a few seconds, that'd be fine.

Although with safety critical systems I'd probably want each contributor to have some experience in the field too.

22 minutes ago [-]
latency-guy2 47 minutes ago [-]
What kind of things would you like to hear? The default is you hear nothing. Most black boxes work this way. And you similarly have no say in the matter.
skeeter2020 1 hours ago [-]
Doesn't this just shift the same hard problem from code to people? It may seem easier to assess the "quality" of a person, but I think there are all sorts of complex social dynamics at play, plus far more change over time. Leave it to us nerds to try and solve a human problem with a technical solution...
mjr00 1 hours ago [-]
> Leave it to us nerds to try and solve a human problem with a technical solution...

Honestly, my view is that this is a technical solution for a cultural problem. Particularly in the last ~10 years, open source has really been pushed into a "corporate dress rehearsal" culture. All communication is expected to be highly professional. Talk to everyone who opens an issue or PR with the respect you would a coworker. Say nothing that might offend anyone anywhere, keep it PG-13. Even Linus had to pull back on his famously virtiolic responses to shitty code in PRs.

Being open and inclusive is great, but bad actors have really exploited this. The proper response to an obviously AI-generated slop PR should be "fuck off", closing the PR, and banning them from the repo. But maintainers are uncomfortable with doing this directly since it violates the corporate dress rehearsal kayfabe, so vouch is a roundabout way of accomplishing this.

zbentley 8 minutes ago [-]
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.

zozbot234 45 minutes ago [-]
I disagree. The problem with AI slop is not so much that it's from AI, but that it's pretty much always completely unreadable and unmaintainable code. So just tell the contributor that their work is not up to standard, and if they persist they will get banned from contributing further. It's their job to refactor the contribution so that it's as easy as possible to review, and if AI is not up to the task this will obviously require human effort.
mjr00 34 minutes ago [-]
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 19 minutes ago [-]
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 4 minutes ago [-]
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.

bpavuk 38 minutes ago [-]
...and waste valuable time reviewing AI slop? it looks surprisingly plausible, but never integrates with the bigger picture.
verdverm 40 minutes ago [-]
> Particularly in the last ~10 years ...

This is maturation, open source being professional is a good sign for the future

jprosevear 1 hours ago [-]
sunir 3 minutes ago [-]
Reminds me fondly of advogato.
Halan 41 minutes ago [-]
How does a potential positive contributor pierce through? If they are not contributing to something already and are not in the network with other contributors? They might be a SME on the subject and legit have something to bring to the table but only operated on private source.

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

arcologies1985 23 minutes ago [-]
In my OSS projects I appreciate if someone opens an issue or discussion with their idea first rather than starting with a PR. PRs often put me in an awkward position of saying "this code works, but doesn't align with other directions I'm taking this project" (e.g. API design, or a change making it harder to reach longer term goals)
qmarchi 29 minutes ago [-]
Looking at this, it looks like it's intended to handle that by only denying certain code paths.

Think denying access to production. But allowing changes to staging. Prove yourself in the lower environments (other repos, unlocked code paths) in order to get access to higher envs.

Hell, we already do this in the ops world.

Halan 25 minutes ago [-]
So basically we are back at tagging stuff as good for first contributors like we have been doing since the dawn of GitHub
treeshateorcs 3 minutes ago [-]
this wouldn't have helped against the xz attack
dom96 1 hours ago [-]
Initially I liked the idea, but the more I think about it the more this feels like it just boils down to: only allow contributions from a list of trusted people.
3371 1 hours ago [-]
Well a lot of useful things are not useful because they are innovative, but well designed an executed.
ramses0 1 hours ago [-]
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 1 hours ago [-]
This makes a lot more sense for large scale and high profile projects, and it eliminates low quality slop PRs by default with the contributors having to earn the trust of the core maintainers to contribute directly to the project.
verdverm 39 minutes ago [-]
it also increases the barrier to new adopters

why not use ai to help with the ai problem, why prefer this extra coordination effort and implementation?

Rumple22Stilk 21 minutes ago [-]
That's the whole point. There are many new adopters and few competent ones.
verdverm 17 minutes ago [-]
I mean to well meaning contributors, I understand the goal of vouch, I think it goes too far and you'll turn off said well meaning contributors

I certainly have dropped off when projects have burdensome rules, even before ai slop fest

1a527dd5 52 minutes ago [-]
I think denouncing is an incredibly bad idea especially as the foundation of VOUCH seems to be web of trust.

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

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

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

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

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

acjohnson55 43 minutes ago [-]
I'm guessing denounce is for bad faith behavior, not just low quality contributions. I think it's actually critical to have a way to represent this in a reputation system. It can be abused, but abuse of denouncement is grounds for denouncement, and being denounced by someone who is denounced by trusted people should carry little weight.
ncr100 36 minutes ago [-]
IDK about this implementation ...

OVER-Denouncing ought to be tracked, too, for a user's trustworthiness profile.

mjr00 42 minutes ago [-]
What value would this provide without the denouncement feature? The core purpose of the project, from what I can tell, is being able to stop the flood of AI slop coming from particular accounts, and the means to accomplish that is denouncing those accounts. Without denouncement you go from three states (vouched, neutral, denounced) to two (vouched and neutral). You could just make everyone who isn't vouched be put into the same bucket, but that seems counterproductive.
HiPhish 1 hours ago [-]
Not sure about this one. I understand the need and the idea behind it is well-intentioned, but I can easily see denouncelists turn into a weapon against wrongthinkers. Said something double-plus-ungood on Twitter? Denounced. Accepted contribution from someone on a prominent denouncelist? Denouced. Not that it was not possible to create such lists before, but it was all informal.

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

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

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

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

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

zozbot234 1 hours ago [-]
GitHub needs to implement eBay-like feedback for contributors. With not only reputation scores, but explanatory comments like "AAAAAAAAAAAAAA++++++++++++ VERY GOOD CONTRIBUTIONS AND EASY TO WORK WITH. WOULD DEFINITELY MERGE THEIR WORK AGAIN!"
HiPhish 41 minutes ago [-]
I think merged PRs should be automatically upvoted (if it was bad, why did you merge it?) and closed unmerged PRs should not be able to get upvoted (if it was good, why did you not merge it?).
MarkusQ 9 minutes ago [-]
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 37 minutes ago [-]
The ones I've never understood are: Prompt payment. Great buyer.

I can't check out unless I pay. How is that feedback?

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

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

davidkwast 16 hours ago [-]
I think LLMs are accelerating us toward a Dune-like universe, where humans come before AI.
sph 13 hours ago [-]
You say that as if it’s a bad thing. The bad thing is that to get there we’ll have to go through the bloody revolution to topple the AI that have been put before the humans. That is, unless the machines prevail.

You might think this is science fiction, but the companies that brought you LLMs had the goal to pursue AGI and all its consequences. They failed today, but that has always been the end game.

ashton314 14 hours ago [-]
Got to go through the Butlerian Jihad first… not looking forward to that bit.

(EDIT: Thanks sparky_z for the correction of my spelling!)

sparky_z 13 hours ago [-]
Close, but it's "Butlerian". Easy to remember if you know it's named after Samuel Butler.

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

Rumple22Stilk 21 minutes ago [-]
The alternative is far far worse.
someone_jain_ 16 hours ago [-]
Hope github can natively integrate something in the platform, a relevant discussion I saw on official forums: https://github.com/orgs/community/discussions/185387
matthewisabel 16 hours ago [-]
We'll ship some initial changes here next week to provide maintainers the ability to configure PR access as discussed above.

After that ships we'll continue doing a lot of rapid exploration given there's still a lot of ways to improve here. We also just shipped some issues related features here like comment pinning and +1 comment steering [1] to help cut through some noise.

Interested though to see what else emerges like this in the community, I expect we'll see continued experimentation and that's good for OSS.

[1] https://github.blog/changelog/2026-02-05-pinned-comments-on-...

ashton314 13 hours ago [-]
vips7L 2 hours ago [-]
Love seeing some nushell usage!
moogly 4 hours ago [-]
So you're screwed if you don't have any connections. In that way it's just like meat space.
skeptrune 12 hours ago [-]
I have a hard time trying to poke holes in this. Seems objectively good and like it, or some very similar version of it, will work long term.
ashton314 14 hours ago [-]
Reminds me of the reputation system that the ITA in Anathem by Neal Stephenson seem to have. One character (Sammann) needs access to essentially a private BBS and has to get validated.

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

“How would that work?” I asked.

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

“Norslof,” I said.

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

“Okay, but how—”

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

“Asamocra?”

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

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

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

igor47 11 hours ago [-]
Man, I'm a huge fan of Anathem (and Stephenson in general) but this short excerpt really reminded me of https://xkcd.com/483/
renewiltord 3 hours ago [-]
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 1 hours ago [-]
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.

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

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

abracos 2 hours ago [-]
Isn't it extremely difficult problem? It's very easy to game, vouch 1 entity that will invite lots of bad actors
mjr00 2 hours ago [-]
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.

speps 2 hours ago [-]
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 1 hours ago [-]
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 50 minutes ago [-]
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.
bsimpson 50 minutes ago [-]
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 43 minutes ago [-]
You are not supposed to vouch for strangers, system working as intended.
dboon 2 hours ago [-]
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 1 hours ago [-]
> 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.
DJBunnies 2 hours ago [-]
Indeed, it's relatively impossible without ties to real world identity.
mjr00 2 hours ago [-]
> Indeed, it's relatively impossible without ties to real world identity.

I don't think that's true? The goal of vouch isn't to say "@linus_torvalds is Linus Torvalds" it's to say "@linus_torvalds is a legitimate contributor an not an AI slopper/spammer". It's not vouching for their real world identity, or that they're a good person, or that they'll never add malware to their repositories. It's just vouching for the most basic level of "when this person puts out a PR it's not AI slop".

DJBunnies 6 minutes ago [-]
That’s not the point.

Point is: when @lt100, @lt101, … , @lt999 all vouch for something, it’s worthless.

hobofan 2 hours ago [-]
Then you would just un-vouch them? I don't see how its easy to game on that front.
2 hours ago [-]
smotched 2 hours ago [-]
you can't really build a perfect system, the goal would be to limit bad actors as much as possible.
alexjurkiewicz 15 hours ago [-]
The Web of Trust failed for PGP 30 years ago. Why will it work here?

For a single organisation, a list of vouched users sounds great. GitHub permissions already support this.

My concern is with the "web" part. Once you have orgs trusting the vouch lists of other orgs, you end up with the classic problems of decentralised trust:

1. The level of trust is only as high as the lax-est person in your network 2. Nobody is particularly interested in vetting new users 3. Updating trust rarely happens

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

javascripthater 15 hours ago [-]
Web of Trust failed? If you saw that a close friend had signed someone else's PGP key, you would be pretty sure it was really that person.
BugsJustFindMe 2 hours ago [-]
Identity is a lot easier than forward trustworthiness. It can succeed for the former and fail for the latter.
Animats 12 hours ago [-]
> The Web of Trust failed for PGP 30 years ago. Why will it work here?

It didn't work for links as reputation for search once "SEO" people started creating link farms. It's worse now. With LLMs, you can create fake identities with plausible backstories.

This idea won't work with anonymity. It's been tried.

ibrahima 1 hours ago [-]
I guess this is why Sam Altman wants to scan everyone's eyeballs.
15 hours ago [-]
bmitch3020 7 hours ago [-]
I could see this becoming useful to denounce contributors. "This user is malicious, a troll, contributes LLM slop, etc." It could become a distributed block list, discourage some bad behavior I've been seeing on GitHub, assuming the denounce entries are reviewed rather than automatically accepted.

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

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

16 hours ago [-]
canada_dry 16 hours ago [-]
An interesting approach to the worsening signal-to-noise ratio OSS projects are experiencing.

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

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

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

16 hours ago [-]
16 hours ago [-]
IshKebab 2 hours ago [-]
> Who and how someone is vouched or denounced is left entirely up to the project integrating the system.

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

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

skeeter2020 1 hours ago [-]
Agree! Real people are not static sets of characteristics, and without a immutable real-world identity this is even harder. It feels like we've just moved the problem from "evaluate code one time" to "continually evaluate a persona that could change owners"
vscode-rest 2 hours ago [-]
[dead]
sanufar 16 hours ago [-]
Makes sense, it feels like this just codifies a lot of implicit standards wrt OSS contribution which is great to see. I do wonder if we'll ever see a tangible "reputation" metric used for contribs, or if it'd even be useful at all. Seems like the core tension now is just the ease of pumping out slop vs the responsibility of ownership of code/consideration for project maintainers.
aatd86 2 hours ago [-]
Does is overlap with Contributor License Agreement?
returnInfinity 13 hours ago [-]
Easy for the koreans to game this.
quotemstr 1 hours ago [-]
Fortunately, as long as software is open sourced, forking will remain a viable way to escape overzealous gatekeeping.
jemfinch 13 hours ago [-]
Is this the return of Advogato?
whalesalad 13 hours ago [-]
We got social credit on GitHub before GTA 6.
pyrolistical 14 hours ago [-]
Another way to solve this is how Linux organizes. Tree structure where lower branches vet patches and forward them up when ready
BiteCode_dev 1 hours ago [-]
Illegal in europe. You are bot allowed to keep a black list of people with the exception of some criminal situations or addiction.
rvz 48 minutes ago [-]
This makes sense for large-scale and widely used projects such as Ghostty.

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

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

A great deal.

zenoware 2 hours ago [-]
[dead]
enterprisetalk 13 hours ago [-]
[dead]
archagon 2 hours ago [-]
However good (or bad) this idea may be, you are shooting yourself in the foot by announcing it on Twitter. Half the devs I know won’t touch that site with a ten foot pole.
rcakebread 28 minutes ago [-]
Who trusts people who still use X?
jimmaswell 26 minutes ago [-]
I still prefer it to Wayland for various reasons, and I don't think Wayland would work properly on my mid 2010 Macbook anyway.
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 19:45:12 GMT+0000 (Coordinated Universal Time) with Vercel.