B2Y, syncing Bilibili danmaku onto YouTube and Quark Drive playback

The premise: the same upload, better video quality, missing comments

B2Y exists to solve a specific mismatch between two platforms. The project states the situation in one line: an uploader you follow posts on both YouTube and Bilibili, you would rather watch the higher quality YouTube copy, but you still want the danmaku that only exist on Bilibili. The extension closes that gap by pulling the comment stream from one site and drawing it over playback on the other.

The danmaku model matters for understanding what is being rendered. These are scrolling bullet comments positioned at a point in the video timeline, not a separate comment thread. That is why the feature list is heavy on timing and layout controls: you can adjust font size, opacity, scroll speed and vertical track spacing, restrict the display area, apply intelligent filtering, and search the danmaku and jump the timeline to a matching moment.

The scope grew during 2026. Alongside YouTube, the extension now covers Quark Drive video playback, with a floating button next to the playback history, a hover list of search results, editable search keywords, and support for full screen and playback speed. The anime channel case is handled too: official series episodes published on the Bilibili Anime channel can be matched automatically with no configuration.

There is also an advertisement skipper. When a matched danmaku source contains ad segments, the extension intelligently skips the danmaku over those segments, a feature credited in the changelog to the BilibiliSponsorBlock project.

The audience is a viewer, not a developer. This is a personal-use extension that happens to be open source, and the documentation is written for someone who wants danmaku on a video they are watching right now.

Version 2.0 replaced uploader linking with title search

The biggest change in the project is also its most fragile, so it is worth reading the 2.0 changelog closely.

Before 2.0, the extension matched a YouTube video to its Bilibili counterpart by uploader association or by searching the uploader's Bilibili space. The 2.0 release dated 2026-05-15 changed the default on YouTube to a title-based search that needs no uploader link at all, and added the same automatic title search to the Quark Drive path. When several results clear the match threshold, the default pick is the one with the most danmaku, with an option to pop up a chooser instead and select manually.

The old behaviour is still reachable. The Popup has a recognition mode setting where you can switch to the legacy mode and go back to uploader association and Bilibili space search. Keeping that switch is the right call, because the legacy path is the deterministic one and the new path is the heuristic one.

The 2.0 release also fixed a long-standing problem, described in the changelog with some understatement, where YouTube's single page app navigation prevented danmaku from matching at all. The fix only works with the new matching mode, which is why the changelog pairs the two.

Two more fixes in the same release point at the fragility of talking to Bilibili from an extension. Search requests that hit a blocked keyword could be stopped by a `csrf` check, and the WBI key now has a six hour cache, which the changelog says reduces repeated requests and startup waiting. The key caching is a good sign that the maintainer profiles the startup path.

Rendering danmaku with the Web Animations API

The drawing technique is stated in the changelog for version 1.1.2, dated 2025-08-18, which switched to the Web Animations API to get Safari and Firefox compatibility and to improve animation performance. That single decision explains a lot of the extension's behaviour, including one of its complaints.

Animating a few dozen comment elements is trivial. Animating a few hundred simultaneously is where a naive implementation falls over, and the changelog records a fix for danmaku flickering in some browsers in 1.1.3, along with a performance improvement in the same release. Earlier releases added ten percent more danmaku coverage, and 1.0.6 raised the danmaku frame rate.

The fact that the project had to move to the Web Animations API to support Safari and Firefox at all is the interesting part. A canvas-based renderer would have avoided the DOM pressure, at the cost of losing the browser's own compositing and text rendering. The chosen path gives crisper text and simpler layout, and it puts the load on the compositor instead of on JavaScript, which is the right trade for a busy timeline.

The remaining performance caveats are documented honestly. The manual installation instructions for Firefox note that performance problems still exist there, with stuttering, and that Firefox needs the extension reloaded after a restart. Safari has the same reload-on-restart caveat. A user who switches browsers often will notice both.

A separate changelog entry fixes a z-index problem, which is the kind of bug that only appears when the extension draws on top of someone else's video player and the player's own overlays fight for the same stacking order.

A WXT codebase with four entrypoints

The project migrated to the WXT framework in version 1.1.1, dated 2025-08-17, and the repository layout follows that convention closely. The entrypoints directory holds the background script, the YouTube content script, a separate Quark Drive content script, and the popup interface, with utils for shared modules, public for static assets, and a wxt.config.js at the root.

The package manifest makes the cross-browser story concrete. There is one WXT dependency and one Prettier dependency, and the script set is a matrix of build targets: `dev` runs WXT with hot reload, `dev:firefox`, `dev:chrome`, `dev:edge` and `dev:safari` each pin a browser, `build` and `build:all` do the same for production builds, and `zip` and `zip:all` package the results. A `postinstall` hook runs `wxt prepare`.

WXT is doing the work that makes four targets practical. The documentation describes the stack as modular ES6 with import and export syntax, hot reload during development, automatic code splitting to optimise resource loading, and a single codebase for multiple browsers. The code splitting claim is the practically important one, since a content script that injects into every page should not carry the danmaku renderer until it is needed.

The top-level tree also shows two JSON data files that are not code: `channel-associations.json` and `social-config.json`, alongside a `lib/` directory, a `utils/` directory, an `images/` directory and a formatting setup with a `.prettierrc` and a `.prettierignore`.

Building it yourself and keeping a Bilibili session

The development setup is documented with the browser data directory trick that makes iterating on this project bearable. The project configures a persistent browser profile so that the Bilibili login state and cookies survive between dev sessions, and the configuration lives in `web-ext.config.js`.

For Chrome and Edge the data is stored under `.wxt/chrome-data/`, that directory is in `.gitignore` so it is never committed, and the first `npm run dev` run captures the logged-in state so later runs do not need to log in again. Firefox needs more work: the instructions have you open `about:profiles`, create a profile named `wxt-dev-profile` or any name you then write into `web-ext.config.js`, launch it in a new browser, log into Bilibili in that window, close the window and only then run the Firefox dev command. The documentation warns that logging in inside the dev mode window is not saved, so the state has to be established in a normal browser window first.

The build commands are the standard set.

npm install
npm run dev
npm run build
npm run zip

For the Firefox target the same pattern applies with the suffixed scripts, and the packaging scripts per browser are named after their target, so `zip:firefox` and `zip:safari` exist alongside the generic ones.

The Bilibili login is not a development convenience only. The user instructions for YouTube begin with installing the extension and making sure you are logged into Bilibili. That is the single most important operational fact about this project: the extension carries a session with a third-party service in your browser, and every danmaku request is made as that logged-in user.

Four browsers, three install paths, and an unfinished Safari story

Distribution is the messiest part of the project and the documentation is candid about it.

Chrome has a Web Store listing, and the recommended path is three clicks and a confirmation. Firefox has an add-ons listing with the same shape. Edge has no separate store entry of its own; the recommendation is to install the Chrome Web Store version instead. Safari is not published on any store at all, and the documentation says so plainly, stating that manual installation is still required.

Manual installation is a per-browser ritual. You download the ZIP for your browser from the Releases page, named with the version in it, then either unpack it and load the unpacked extension through the developer mode in `chrome://extensions/` or `edge://extensions/`, or use `about:debugging` in Firefox and load the add-on temporarily, or in Safari go through the Develop and Settings menus to allow unsigned extensions and add the temporary extension. The documentation recommends the store versions and calls manual installation the fallback for when the stores are unreachable.

The manual path is also where the two rough edges live. The Firefox instructions state that performance problems still exist with stuttering, and that the extension must be reloaded after a Firefox restart. The Safari instructions state that the extension must be reloaded after a Safari restart. A temporary extension is temporary by design, which is why the note is there.

For other Chromium-based browsers, the support status is marked as theoretical, with domestic Chromium forks and Opera named as examples. That is an honest way to say it is untested.

MIT licensed, one maintainer, and a slow patch cadence

The licence is MIT, declared in the package manifest and with a LICENSE file in the tree, so the extension can be redistributed and modified as long as the notice travels with it. The repository also carries a DONATE.md, and the README links to a separate tool the author has built for removing watermarks from Sora output, which tells you this is a one-person project with side projects.

The release history is short and irregular. The recorded releases are v2.0.0 on 2026-05-15, v1.1.6 on 2026-01-19 and v1.1.5 on 2025-08-19. The changelog in the README goes back further and lists roughly one version every few days through August 2025, including 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.1.0, 1.1.1, 1.1.2, 1.1.3 and 1.1.5, then a gap to 1.2.0 in January 2026 and 2.0.0 in May.

The last push to the repository was on 2026-05-15, the same day as the 2.0.0 release. So the code you would install today is the code from that release, and there has been no commit since. There is no statement in the documentation about a support policy for the 1.x line, so a user still on the older matching logic has no defined path forward.

Two operational points round out the picture. The `csrf` and WBI key fixes from 2.0 show that Bilibili changes its web defences, and when it does, the extension has to follow, which means a browser extension user needs to update the extension from a store that will not necessarily tell them loudly. And the extension is distributed through stores for the most part, so a build that breaks against a site change can be pulled by the store review process without a published changelog entry.

Editorial conclusion

B2Y suits a viewer who watches a lot of Bilibili-sourced content on YouTube, where the danmaku are the point of the video, and who is willing to keep a Bilibili session alive in the browser. It does not suit a team building a product, a user who wants a private browsing profile, or anyone expecting the extension to work without a Bilibili login, since the documentation makes the login a precondition. Verify first that the title-based match picks the video you meant on the specific content you watch, since that is the mechanism the whole extension now depends on, and check the browser you use against the build list, because the Safari and Firefox paths still require manual installation and Firefox is documented as stuttering.

Frequently asked questions

Official sources

1. ahaduoduoduo/bilibili-youtube-danmaku on GitHub
2. Issues
3. License: MIT
4. README
5. Releases