u/SyntaxOfTheDamned

Turns out: very visible. Yesterday's scan found 185 out of 185 engagers on a single repo were bots. Not 90%. Not "mostly suspicious". Every single one. The repo had zero legitimate stars.

What I built

phantomstars is a Python tool that runs daily via GitHub Actions (free, no servers):

1. Scrapes GitHub Trending and searches for repos created in the last 7 days with sudden star spikes
2. Pulls star and fork events from the last 24 hours per repo
3. Bulk-fetches every engager's profile via the GraphQL API (account creation date, follower counts, repo history)
4. Scores each account on a weighted model: account age (35%), profile completeness (30%), repo patterns (25%), activity history (10%)
5. Detects coordinated campaigns using timestamp clustering and union-find: groups of 4+ suspicious accounts that engaged within a 3-hour window
6. Files an issue directly on the targeted repo so the maintainer knows what's happening

Campaign IDs are deterministic SHA-256 fingerprints of the sorted member set, so the same group of bots gets the same ID across runs. You can track a farm across multiple days even as individual accounts get suspended.

What the pattern actually looks like

It's remarkably consistent. A fake engagement campaign in the raw data:

• 40-200 accounts, all created within the same 1-2 week window
• Zero original repositories, or only forks they never touched
• No bio, no location, no followers, no following
• All of them starring the same repo within a 90-minute window
• The target repo usually has a name implying it's a tool, hack, executor, or generator

Today's scan: 53 active campaigns across 3,560 accounts profiled. 798 classified as likely_fake. The repos being targeted are mostly low-quality AI tools and "executor" software that needs manufactured credibility fast.

Notifying the affected repo

When a repo hits a 40%+ fake engagement ratio or a campaign is detected, phantomstars opens an issue on that repo with the full suspect table: account logins, creation dates, composite scores, campaign membership. The maintainer sees it in their own issue tracker without having to find this project first.

Worth noting: a lot of these repos have issues disabled, which is a red flag on its own. Those get skipped silently.

Why I built this

Stars are how developers decide what to evaluate, what to depend on, what to recommend. When that signal is bought, it affects real decisions downstream. This started as curiosity about how measurable the problem was. The answer was more measurable than I expected.

It's part of broader research into AI slop distribution at JS Labs: https://labs.jamessawyer.co.uk/ai-slop-intelligence-dashboards/

The fake engagement problem and the AI content quality problem are really the same problem. Fake stars are the distribution layer that gets garbage in front of real users.

All open source. The data is append-only JSONL committed back to the repo after every run, queryable with jq.

Repo: https://github.com/tg12/phantomstars

Findings are probabilistic, false positives exist, the README explains the full scoring model. If your account shows up and you're a real person, there's a false positive process.

Questions welcome on the detection approach, GraphQL batching, or campaign ID stability.

I found an unusually large fork graph on a public repo and tried to notify downstream forks about upstream defects. While doing that, I noticed most forks had issues disabled, several fork-creation days had very large bursts, and a smaller subset of recent forks showed zero-engagement/minimal-activity patterns. I’m trying to understand whether this looks like normal GitHub fork behavior, bot noise, or something more inorganic.

I built a small browser-based Game Theory Arcade:

The idea is simple: instead of reading a definition of Nash equilibrium, best response, minimax, or repeated-game incentives, you play short games against bots and see the structure while you play.

At the moment it includes things like:

• Prisoner’s Dilemma
• Chicken / Hawk-Dove
• Stag Hunt
• Entry Deterrence
• Matching Pennies
• Executive vs Central Bank style games
• Random, Tit-for-Tat, Grim Trigger, one-step best-response, and minimax-style bots

Each game shows the payoff matrix, best-response markers, Nash cells, round-by-round outcomes, discounted totals, and a plain-English explanation of what happened. There is also a leaderboard, but it is mostly there to make experimentation less sterile rather than to turn it into a serious competitive game.

The thing I’m trying to test is whether game theory becomes easier to understand when you can feel the incentive problem first.

For example, in Prisoner’s Dilemma, "defect is the dominant one-shot move" is easy to say. But it lands differently when you defect once against Tit-for-Tat and then watch the relationship degrade. The same goes for mixed strategies in Matching Pennies or coordination failure in Stag Hunt.

This is not meant to replace a textbook. It is more of an intuition builder before the formal material.

• I’d be interested in criticism from people who know the subject properly:
• Where is the model misleading?
• Which games should be added next?
• Are the explanations too simplified?
• Would this be useful for students, or is it just a toy?

The latest cluster includes HantaTrackers and more “OSINT / crisis / surveillance / intelligence” dashboards that look authoritative until you read the code.

The current audit trail is now at:

181 filed issues
14 active public GitHub trackers
1 additional repo in scope with issues disabled

The pattern is not subtle anymore.

These projects keep presenting themselves as intelligence infrastructure while shipping things like:

fabricated outbreak records
fake freshness timestamps
randomised “live” market data
hardcoded confidence scores
synthetic surveillance states
provider scraping dressed up as stable API integration
hardcoded credentials
unauthenticated mutation routes
public control surfaces
SSRF/open-proxy risks
false “system healthy” states
dead features still presented as working
AI/OSINT interfaces that simulate authority instead of showing evidence

The HantaTracker / hantavirus-tracker findings are especially grim because this is not just “lol bad dashboard code.” This is public-health-flavoured slop.

One tracker was publishing hardcoded seed cases under CDC/ECDC/HealthMap/GDELT-style source labels. Another had hand-authored outbreak records, hardcoded confidence, inflated totals, fake freshness, and claimed merged sources that were not actually merged.

That matters because public health data has a higher burden of care. You cannot slap a map on hardcoded rows, call it surveillance, and pretend the UI makes it real.

The broader AI intelligence dashboard problem is now obvious:

The interface says “analysis.”
The implementation says “simulation.”
The marketing says “situational awareness.”
The code says “random fallback with a serious label.”

This is the core failure: these tools want the social status of intelligence infrastructure without doing the evidentiary, operational, or security work that intelligence infrastructure requires.

The most absurd finding in the whole series is still osiris committing a prompt injection in AGENTS.md to misdirect AI code reviewers. That is not just bad engineering. That is adversarial design aimed at preventing review.

At this point, the issue is not one bad repo. It is a repeated cloned pattern:

authority-shaped UI
weak evidence boundaries
fabricated output
unsafe operational surfaces
provider abuse
false confidence
no meaningful disclosure

If a tool cannot separate observed evidence from simulation, it is not an intelligence platform. It is theater.

And if it fabricates public health, crisis, OSINT, or geopolitical data while presenting it as live or source-backed, it should not be treated as harmless prototype code.

It should be treated as a trust and safety failure.