We stopped AI bot spam in our GitHub repo using Git's –author flag
76 points by ildari 46 minutes ago | 15 comments
arecsu 8 minutes ago
Makes me wonder if an ELO-based system would work to mitigate these issues. People who merged PR successfully onto a project, that had real issues acknowledged, the quality of their responses measured by other users reactions or something, etc, multiplied possibly by the degree of importance of the project where their activity has been made. Won't be about human vs AI, but actual helpful effective being vs low effort/spammy contributions. Issues and PRs could be sorted and filtered by their ELO score. I'm saying ELO as analogy to "score based given the context", not really a 1:1 translation of the ELO system
replysilverwind 18 minutes ago
PR spam is a major problems for repo that run bounties. Maybe GitHub should temporarily block accounts from raising PRs if like 95%+ of them are getting rejected.
replyhiccuphippo 9 minutes ago
GitHub has not incentive for blocking AI. It's like asking an ad company to build an adblocker into their browser.
replypetterroea 5 minutes ago
What I see is a (clever) hack, and GitHub continuing to provide good tools to its users.
replyildari 46 minutes ago
Hi HN community, I wanted to share our approach to reduce amount of AI slop PR's and issues in our repo. We enabled "require prior contribution" flag on GH and created a CI script that creates a tiny commit co-authored with you, if you pass captcha on our website. Worked really well and we were able to block at least 500 bots in the first week. Sharing a screenshot from cloudflare: https://archestra.ai/hn-comment-cloudflare-challenge-outcome...
replysatvikpendem 33 minutes ago
Yep, this is similar to some other version control tools like Tangled which has vouching.
replytln 21 minutes ago
Thats a really elegant solution.
replyHow does the website trigger the CI script? Through GH rest API?
ildari 14 minutes ago
thank you, yep through the rest API, here is the example: https://github.com/archestra-ai/website/blob/29ebdacbd8a22b9...
reply
> When requiring approvals only for first-time contributors (the first two settings), a user that has had any commit or pull request merged into the repository will not require approval. A malicious user could meet this requirement by getting a simple typo or other innocuous change accepted by a maintainer, either as part of a pull request they have authored or as part of another user's pull request.