# Sky Follower Bridge resolves your X following list into Bluesky accounts

> Sky Follower Bridge is a browser extension that takes the people you already follow on X, Instagram, TikTok or Threads, searches Bluesky for matching accounts and lets you follow them in bulk. It suits people migrating a social graph, and it depends on an undocumented name matching heuristic and on Bluesky's search rate limit.

**kawamataryo/sky-follower-bridge** — Instantly find and follow the same users from your X(Twitter) follower on Bluesky.

- Repository: https://github.com/kawamataryo/sky-follower-bridge
- Website: https://www.sky-follower-bridge.dev
- Stars: 879 · Forks: 35
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/kawamataryo-sky-follower-bridge

## One list on one platform, resolved on another

The premise is narrow and specific. You open a list of people you already follow somewhere else, and the extension finds the corresponding accounts on Bluesky so you can follow them without visiting each profile by hand.

The source lists come from X. The project documentation names the Following page, the Followers page, the Blocked users page and the members page of a public X list. The project description also claims support for Instagram, TikTok and Threads follows, so the list of supported sources is wider than the X examples in the usage notes.

The output is a modal listing of Bluesky users, each with a Follow button. The interaction is deliberately manual at the last step: the tool resolves names, it does not follow on your behalf. You still click Follow once per account, which keeps the action inside your own session and inside your own intent.

The interesting detail is that the matching is done on names. The package dependency list includes jaro-winkler, a string similarity library, which points to approximate name matching. How the extension disambiguates two people with the same display name, and whether it ever matches on handle text, is not described in the project documentation. That is the main uncertainty in the tool and the reason to test on a small batch first.

## Two sign in paths and the PDS question

Bluesky access is obtained in one of two ways, and the choice matters for anyone who is not on the default server.

The recommended path is OAuth. You enter your handle, click Sign in with Bluesky, and a browser window opens for a secure OAuth login. The extension depends on the atproto OAuth client package and the AT Protocol API package, so the flow is handled by the protocol libraries rather than by hand written requests.

The second path is an app password. You switch to the App Password tab and supply three values: your handle or email, an app password generated in the Bluesky settings, and a service URL such as https://bsky.social. For a self-hosted PDS, the service URL field takes your own PDS address instead, for example https://your-pds.example.com. Support for self-hosted PDS servers arrived in version 3.1.0, according to the project documentation, which is the reason the service URL is a required field rather than an advanced one.

One side effect of using app passwords is worth remembering: a Bluesky app password is a credential that can act on your behalf. Generating one for a browser extension means you should be prepared to revoke it, and to check the app password list in your account settings if you stop using the extension.

## Building the extension and removing permissions afterwards

The extension is built with Plasmo, and the project uses the MV3 manifest model, which is why a separate Firefox target exists. The package scripts are the clearest view of the workflow.

```json
  "scripts": {
    "dev": "plasmo dev",
    "dev:firefox": "plasmo dev --target=firefox-mv3",
    "build": "plasmo build && npm run remove-permissions",
    "check": "npx @biomejs/biome check  --write --unsafe ./src",
```

The build line is the interesting one. A Plasmo build is followed by a step named remove-permissions, which runs the script at scripts/remove_web_accessible_resources.js. Whatever that script strips, the effect is that the shipped extension exposes fewer resources to web pages than a default build would, and a Firefox package runs the same step.

The rest of the scripts describe a conventional setup: Biome for linting and formatting with a separate ci command, Vitest for tests, Storybook on port 6006 for component work, VitePress for the documentation site, and a source-zip script that calls scripts/create_source_zip.sh. There is a changesets setup, which is how version bumps are usually prepared in a repository that publishes to extension stores.

The repository also carries a server directory, a locales directory for translations, a scripts directory and a docs directory, so the project is more than a single script injected into a page.

## The search rate limit is the constraint you will hit

The project names its own limitation in one line: user search may fail because of a rate limit in the Bluesky API, and the advice is to wait two to three minutes and run the search again.

That is the failure mode that shapes the whole workflow. Resolution is a per name API search, so a list of several hundred people is several hundred requests. When the limit is reached, the extension cannot show a partial answer, it shows an error, and the documented recovery is a wait and a retry.

There is a second, vaguer failure in the troubleshooting notes. If you see an error message beginning with Error: Something went wrong, the instruction is to reload the page and click the extension icon again, which points to the extension state having been lost rather than to a wrong name.

A third quirk is browser specific. The Alt + B shortcut opens the extension, but the project warns that this shortcut may not work in Firefox, where you should click the toolbar icon instead. Since the same code serves both browsers, the difference is in how the keyboard command is delivered rather than in the extension logic.

## Three stores, one reference build

The extension is published on the Chrome Web Store, on Firefox Add-ons and on Microsoft Edge Add-ons, and the project explicitly recommends the Chrome Web Store version because it is always up to date while the other store versions may lag behind in updates.

That recommendation is worth taking seriously in a review of the source. The package version in the repository is 3.2.2, and the source tree contains the current work, but a user on Firefox or Edge may be running a build from an earlier review cycle. Reviewing the code and then installing from a lagging store is how you end up debugging a version you are not reading.

The store badges on the project page also carry user counts and ratings, which are the kind of numbers that change without notice and are not a useful measure of whether the name matching works.

There is also a self-hosting wrinkle for the platform itself. The project supports self-hosted PDS servers, which means the extension is not tied to bsky.social. In practice that means the sign in screen asks for a service URL, and a wrong value there produces a failure that looks like a credential problem rather than a configuration one.

## Where the code and the documentation actually sit

The top level of the repository holds the usual suspects for a browser extension project: src for the extension source, assets for icons and images, locales for translations, scripts for build helpers, and a docs directory that feeds a VitePress site. There are also two agent oriented files, AGENTS.md and BUILD_INSTRUCTIONS.md, and a package-lock.json rather than a pnpm or yarn lock.

One inconsistency is worth flagging. The project documentation tells developers to see CLAUDE.md for the development setup and the architecture, and the repository root listing does not include a file with that name, while it does include AGENTS.md. If you are trying to follow the documented route into the architecture, expect to find the equivalent content under a different filename.

The docs directory is not optional reading for a serious evaluation, because the project page itself is short and defers many details to the documentation site at sky-follower-bridge.dev, with a getting started page and a troubleshooting page. The extension description in the package manifest is not a literal string either, it is the key __MSG_extension_description__, which means the real text lives in the locale files and differs per language.

## Licence, versions and the cost of staying current

The project is published under the MIT licence, which is a permissive choice for an extension you might fork for your own community.

On versions, the package manifest reads 3.2.2, while the GitHub repository publishes no releases at all. Version bumps are prepared through the changesets tool in the repository root, which is the usual pattern for a project whose artefacts are built by an automated pipeline and pushed to three stores. The last push to the repository was on 2026-09-20.

For a browser extension, the practical upgrade cost is not the semver bump, it is the store review and the fact that a user on a lagging store cannot be pushed the fix. If you depend on this tool, expect to track the Chrome Web Store build as the reference version and treat the Firefox and Edge listings as lagged copies.

The runtime dependencies are all in the AT Protocol and React ecosystem: the atproto API, OAuth client and JWK webcrypto packages, Plasmo storage and messaging helpers, React 18, framer-motion for animation, react-toastify for notifications, TanStack virtual for long lists, use-debounce for the search input, and ts-pattern for pattern matching. That dependency set tells you the extension is a normal React app inside a manifest, not a script that scrapes the page.

## Conclusion

Use Sky Follower Bridge if you are moving a social graph to Bluesky and want to do it in one sitting, since it covers X, Instagram, TikTok and Threads lists and supports self-hosted PDS servers through a service URL. Do not expect exact identity matching, because the project does not document how a display name is turned into a Bluesky handle. Verify three things first: that the Chrome Web Store build matches the source you are reading, since the other stores may lag, that your Bluesky session works through OAuth before you import a long list, and that a small batch resolves cleanly before you run a full follow round on a personal account.

## FAQ

### How do I install Sky Follower Bridge?

It is published on the Chrome Web Store, on Firefox Add-ons and on Microsoft Edge Add-ons. The project recommends the Chrome Web Store build because the other store versions may lag behind in updates.

### How do I sign in to Bluesky with Sky Follower Bridge?

You can use OAuth, by entering your handle and clicking Sign in with Bluesky, or the App Password tab, where you supply a handle or email, an app password and a service URL. For a self-hosted PDS you put your own PDS address in the service URL field.

### What happens when Sky Follower Bridge hits the Bluesky search rate limit?

User search may fail because of a rate limit in the Bluesky API. The documented recovery is to wait two to three minutes and execute the search again.

### Does Sky Follower Bridge follow accounts automatically?

No. The extension finds the matching Bluesky users and lists them in a modal, and you click the Follow button on each account yourself.

## Sources

- [Issues](https://github.com/kawamataryo/sky-follower-bridge/issues)
- [kawamataryo/sky-follower-bridge on GitHub](https://github.com/kawamataryo/sky-follower-bridge)
- [License: MIT](https://github.com/kawamataryo/sky-follower-bridge/blob/main/LICENSE)
- [Project website](https://www.sky-follower-bridge.dev)
- [README](https://github.com/kawamataryo/sky-follower-bridge/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kawamataryo-sky-follower-bridge