Make X Great Again ships one pillar, keeps three stores on three version lines, and its env template disagrees with its own instructions
Make X Great Again — passive ambient browser extension that makes X usable: spam shield, KOL signal score, profile digest, social graph hints. Public-good, open source.
At a glance
- What is it?
- MXGA is an AGPL browser extension that syncs a community built public blacklist and hides matching accounts locally on x.com, with optional native mute and block through your own login state. Only pillar one of five is live, the newest GitHub tag is v0.4.0 from May 2026 while the page talks about a 0.6.1 build awaiting review, and the shipped env template names two variables the setup instructions never mention.
- Who is it for?
- Read the Ghost Ban paragraph before anything else if you plan to turn on X mute or X block. Local hide is the default because it calls no X endpoint at all; the other two modes act through your real account, and the documentation itself says that bulk blocking can get an account ghost banned, feature limited or frozen.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One pillar is live, and the project summary names the three that are not
The page is honest about this in a table with a status column. Pillar 01, killing spam accounts in comments, is marked Live. The other four are marked planned: a hover card on an @handle showing account age, original ratio, topic concentration and interaction quality; an automatic profile digest with what a person mainly discusses, their five most popular posts in the last month and their best interaction window; social graph hints under a tweet naming which accounts you follow reposted or commented; and a one click export of your follows, bookmarks and own posts as JSON or Markdown.
The repository summary line is where the mismatch sits. It advertises a spam shield, a KOL signal score, a profile digest and social graph hints, which is three of the four unimplemented pillars presented in the same voice as the one feature that works. If you evaluate this project from the summary you will conclude it does more than it does today. The implementation path for pillars 02 through 05 is in `docs/PRODUCT.md`, and the page says outright that only pillar 01 is up.
What pillar 01 does is concrete, and it is the whole extension: sync a community maintained public blacklist, badge the accounts that match, and hide them locally.
Three stores, three version lines, and no tag above v0.4.0
The platform table tracks four distribution channels with their own status and requirements: a Chrome Web Store build for Chrome, Edge, Brave and Arc on the Chromium engine with MV3 and automatic updates; a Firefox add on build requiring Firefox 140 or newer; a Safari macOS build through TestFlight needing macOS 15 or newer; and a Safari iOS and iPadOS build through TestFlight needing iOS or iPadOS 18 or newer, acting on x.com inside Safari. The Safari ports are done and maintained by `@tualatrix`, with build instructions in `docs/SAFARI.md` and `docs/SAFARI-IOS.md`.
The Firefox row states that the store version is still 0.4.0 and that 0.6.1 is awaiting review. The GitHub release list stops at v0.4.0 on 2026-05-28, after v0.3.0 on 2026-05-26 and v0.2.0 on 2026-05-25, three releases in four days. So the highest numbered build the page discusses, 0.6.1, has no tag, and the numbers you see depend on which store you open. The root `package.json` adds a third data point: it carries `version` `0.0.1` with `private` set to true, because the root is the workspace for the CLI and the service rather than the shipped extension.
Local hide is the default because mute and block act as you
The handling mode setting decides what the hide button does, and the three options have very different consequences. Local hide is the default: a visual hide inside the extension, zero network calls, X unaware, and reversible from a local hide list in the options page within five seconds. X mute uses your own X login state to call X's native mute, which is one directional, tells the other party nothing and leaves the follow relationship unchanged. X block is X's native block, where neither side sees the other and the follow is removed.
The muted and blocked paths are optional and, importantly, their optional permissions are requested only at the moment you switch to that mode, not on install. Default permissions are limited to `storage`, `alarms` and `unlimitedStorage`, with x.com and GitHub host permissions requested per feature.
Both actions go through a global rate limit queue before reaching X: serialized across tabs, roughly 1.2 second spacing plus jitter, staged cooldowns and backoff on 429 responses. Those actions call X's own interface directly and never pass through the project's own server. The queue is there to survive a bad afternoon, not to make a bulk operation safe, which is what the next section is about.
The Ghost Ban warning is the part of the documentation worth reading twice
The page carries a dedicated note on X risk control, and its logic is precise. Local hide only hides visually inside the extension and calls no X interface, so it does not trigger X's automation defenses. Enable X mute or X block and the situation changes: both act with your real X account against X's own interface, so X's anti automation rules apply. Acting on many accounts in a short window, and bulk blocking in particular, can be judged abnormal behavior and lead to a ghost ban, feature restrictions or a frozen account.
The project's answer is a queue, plus instructions: operate in batches, in small numbers, prefer mute over block, and do not block densely on a new account or one that was restricted recently. Those are mitigation measures, not permission.
This is also the difference between the two halves of the product. Hiding is a client side operation you can undo. Muting and blocking are irreversible remote actions against a third party's system executed with your credentials, and no rate limiter makes a large batch of them something you want to automate.
So the setting to think about before install is not the default, which is safe, but the moment you decide the default is not enough.
The list syncs every six hours and the matching never leaves the machine
On install and on update the extension downloads the public list immediately, then checks every six hours. The matching itself runs locally, and the page is specific about what the sync request does not carry: no page content, no X identity, no scan results, no processing records. There is no analytics reporting, and local processing records are not uploaded.
Online detection is the one exception, and it is gated behind a GitHub login. For accounts that the local list, the cache and the official rules all miss, the extension submits the public profile and the current public text to `/v1/classify`, capped at 40 accounts per page with at most 3 concurrent requests, and the results are cached on the machine. Signing out of GitHub returns the extension to pure local matching.
The gatekeeper console at `/admin` needs an `ADMIN_TOKEN` and has four tabs: the pending queue, the blacklist, the whitelist and an audit log. The public roster at `/list` is the readable half of the same store, exposing every `human_confirmed` account with its reason and its report count. Governance rules live in `GOVERNANCE.md` and the data flows in `DATA_USAGE.md`.
The automatic publish threshold is written down and switched off
List membership is not self serving. The page describes a three step route: the list is assembled from keyword rules plus an AI first pass, a maintainer confirms by hand, and only confirmed accounts are published. Reports and confirmations go through the website API rather than through the extension, with GitHub token verification and salted fingerprint storage, and during the alpha stage every report enters the human queue first.
The interesting part is the threshold that is not in force. The page names the reserved rule for automatic publication as three GitHub accounts of at least 90 days old combined with an AI confidence of at least 0.9, and states that it is currently off by default. So the automated path exists in the design and is disabled in the running system, which means today the throughput ceiling on the list is human review time.
The appeal path matches that philosophy from the other side. Clicking 申诉 in a badge opens a GitHub issue from a template, and a maintainer reviews it by hand. Mistakes are corrected by unhiding locally from the options page, and only human confirmed entries ever appear on the public roster with a stated reason.
The env template names LLM_BASE_URL while the instructions say LLM_API_BASE
The classification path needs an OpenAI compatible `/chat/completions` endpoint, and the page insists the configuration never enters the repository. For a local run it says to copy `.env.example` to `.env` and fill in `LLM_API_BASE`, `LLM_API_MODEL` and `LLM_API_KEY`. For the Worker it says to run `npx wrangler secret put` for `LLM_API_BASE`, `LLM_API_MODEL`, `LLM_API_KEY` and `ADMIN_TOKEN`.
The template disagrees with both on two of the three names:
LLM_BASE_URL=https://api.example.com/v1
LLM_API_KEY=your-key-here
LLM_MODEL=your-model-id
REPORT_SALT=replace-with-a-long-random-secret
REQUIRE_AUTH=0So a local run configured straight from the template leaves the documented base URL and model variables unset. Beyond the naming, two values in that file deserve attention before any deployment: `REQUIRE_AUTH=0` ships authentication off, and `REPORT_SALT` ships as a placeholder string rather than a secret. Both are exactly the values an example file should hold and exactly the values you must not leave in place on a live `services/edge` deployment.
pnpm everywhere except the Safari path, and an audit directory left in the root
The developer flow is one lockfile and one static check chain. Dependencies install with pnpm and the lockfile is committed, then three checks run in sequence, and the extension itself is a separate project under `extension/` built with WXT, React 19 and Tailwind v4:
pnpm install
pnpm typecheck && pnpm test && pnpm lint
cd extension
pnpm dev
pnpm dev:firefoxThe Chromium run watches and reloads and outputs to `.output/chrome-mv3`; the Firefox run produces `.output/firefox-mv3`. The Safari instructions then switch tools: `npm --prefix extension install`, a copy of `apple/Config/Signing.local.xcconfig.example` into an uncommitted local signing file, and two shell scripts, `./scripts/build-safari-app.sh` for macOS with automatic signing when a local Team ID exists and `./scripts/build-safari-ios-app.sh` as an iOS Simulator build check.
The root tree also explains where the linting boundary sits, since the `lint` script names `biome lint src test services/edge/src services/edge/app` and the root holds `src/` for the local classification CLI, `services/` for the Worker, `fixtures/`, `data/` and `pnpm-lock.yaml`. One entry there is worth a question rather than a guess: a directory named `.audit-2026-08-23/` sits at the root of an AGPL project whose license reaches both the extension and the shared Worker and D1 service.
Editorial conclusion
Read the Ghost Ban paragraph before anything else if you plan to turn on X mute or X block. Local hide is the default because it calls no X endpoint at all; the other two modes act through your real account, and the documentation itself says that bulk blocking can get an account ghost banned, feature limited or frozen. Given that, MXGA is worth using for what is actually shipped: the six hour list sync, the local match, the five second undo, the appeal through a GitHub issue, and the public roster of human confirmed accounts with reasons and report counts. The four remaining pillars are plans described in `docs/PRODUCT.md`, so do not evaluate this repository against the summary line that mentions KOL scores and profile digests. Before running the service side, reconcile the env names, because `.env.example` defines `LLM_BASE_URL` and `LLM_MODEL` while the instructions and the Worker secrets use `LLM_API_BASE` and `LLM_API_MODEL`, and the template ships `REQUIRE_AUTH=0` with a placeholder `REPORT_SALT`.
Frequently asked questions
What does Make X Great Again do when it hides a spam account?
Hiding is local by default: the extension hides the account's posts inside the page with no call to any X interface, and the hide can be undone within five seconds or later from the local hide list in the options page. Optional modes instead use your own X login state to call X's native mute, which is one directional, or X's native block.
Does Make X Great Again send my X data to the project's server?
Matching against the synced public list runs on your machine, and the sync request carries no page content, X identity, scan results or processing records. With a GitHub login, accounts missed by the local list, the cache and the official rules are submitted to /v1/classify, capped at 40 per page with at most 3 concurrent requests, and results are cached locally.
Is the KOL score and profile digest feature in Make X Great Again available now?
No. The page marks only pillar 01, the public blacklist with local hiding, as Live. The hover card for KOL signals, the profile digest, the social graph hints and the data export are all marked planned, with implementation paths in docs/PRODUCT.md.
Can I bulk block accounts with Make X Great Again without risking my account?
The page warns against it. Mute and block act with your real X account against X's own interface, so X's anti automation rules apply, and acting on many accounts at once, especially bulk blocking, can lead to a ghost ban, feature restrictions or a frozen account. The actions pass through a rate limit queue, and the advice is to work in small batches, prefer mute, and avoid dense blocking on new or recently restricted accounts.
How do I configure the LLM endpoint for Make X Great Again?
Copy .env.example to .env for a local run, or set Worker secrets with npx wrangler secret put for LLM_API_BASE, LLM_API_MODEL, LLM_API_KEY and ADMIN_TOKEN. The template itself defines LLM_BASE_URL and LLM_MODEL instead of LLM_API_BASE and LLM_API_MODEL, and ships REQUIRE_AUTH=0 with a placeholder REPORT_SALT.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/foru17-make-x-great-again)