Bilibili_Danmuji: a Spring Boot danmuji configured from a browser panel

A helper built for a room that runs all night, not a desktop overlay

Bilibili_Danmuji targets the streamer who leaves a live room open for hours and wants the thank-you messages handled without a human watching the chat. The project description names the work it does: gift thank-yous, scheduled advertisements, follower thanks, automatic replies, room moderation, daily check-in, and a danmuji client that speaks the WebSocket protocol. The implementation language is Java and the project is built on Spring Boot, so it is closer to a long lived service than to a small binary you launch, watch and close.

That shape has consequences. Because the tool is a server side process, the operator still has to drive it through a browser, and the README is explicit that all configuration happens in a web panel. The project ships a console oriented workflow as well, so the barrage appears in the terminal, but the settings themselves are not edited there. A new user therefore has to accept a two surface arrangement: the process runs in one place, the control panel runs in another, and the two are joined by the running service.

The audience is narrow. If you want a floating chat window over your game, this is the wrong shape of tool. If you want a machine in the corner of a server room that thanks every gift and reminds viewers about a promotion, the feature list is unusually long for something you can host yourself.

The browser panel is the only place configuration happens

The README states the operating rule plainly: the project is operated through a WebUI, meaning browser based operation. The browser matrix that follows is a real constraint rather than a formality, because the interface is built on Bootstrap 5 and the documentation notes that Bootstrap 5 dropped support for Internet Explorer. On Linux, Chrome and Firefox are listed as supported while Edge, Opera and Safari are not. On macOS every browser in the table is listed as supported. On Windows, Chrome, Firefox, Edge and Opera are supported but Safari is not.

The practical reading is that a Linux streamer on a headless server still has to open a panel from a desktop browser somewhere, and that a Safari-only macOS setup is fine while a Safari-only Windows setup is not. The documentation does not describe a fallback interface, so there is no documented way to configure the tool if your only browser is outside the matrix.

The same page also records the runtime floor: a Java JDK or JRE of version 8 or higher is the only stated prerequisite, and the check is a version query.

Two ways to run it, and a filename that does not match the release

For a release build on a machine with Java already configured, the README gives a console command from the project directory. Note that the file name printed in that example is not a plain jar name, so check the archive contents before typing it exactly.

$ java -jar BiliBili_Danmuji-2.7.0.0beta.j

Two details deserve attention. First, the version in the sample command is 2.7.0.0beta, while the newest published release is 2.7.0.7, so the documented command is not guaranteed to match the artifact you just downloaded. Second, the extension ends in .j rather than .jar. Both are traceable to the documentation as written, and both mean you should list the files in the release archive rather than trust the sample line.

There is a second route for people without Java. The 2.7.0.7 release also publishes a Windows 64 bit portable build, described as the green version, that needs no Java environment configuration, and which is built on an openjdk8 distribution. A Docker image is offered as well, published by a third party repository rather than by the project author, with a companion build repository linked alongside it. An earlier Heroku deployment path is struck through in the documentation and marked as being in a testing stage, so treat that route as retired. The check for the regular build is a version query on the local runtime.

Delay merging is what keeps thank-you spam off the chat

The most interesting mechanism in the project is the delayed thank-you. The gift thank-you feature can count gifts, including quantity, that arrive inside a delay window and merge them into a single message. The documentation states that any new gift or any change in quantity inside the window refreshes the delay, so the timer restarts rather than firing on a fixed schedule. The same pattern is applied to follower thanks and to entry welcomes, where a new arrival inside the window also refreshes the timer.

This is a real engineering decision rather than a cosmetic delay. Without merging, a streamer who receives a burst of small gifts gets a matching burst of thank-you messages, which pushes the real chat down and can bury the answers to actual questions. With merging, a burst becomes one line.

The trade-off is stated in the documentation rather than hidden. The note says that repeated barrage messages on the platform now appear to be allowed after roughly three seconds, so the delay is usually set above three seconds to keep most thank-you messages from disappearing. The same note warns that a delay set too high, combined with continuous gifting, can cause message flooding of its own. The same warning applies to the merged follower and entry messages, so the value is a balance between visibility and patience rather than a simple slow down button.

A template parameter table is where the real control lives

Almost every message the tool sends is a template with placeholders, and the set of placeholders is the feature list in practical form. The private message to a captain supports a user name field, a guard level field and a gift code field, and the gift code is deleted after it is sent, so the operator refreshes the page to see the current list. Gift codes are separated by a line break, and a prefix selects the target guard rank, so a code intended for a specific rank carries a rank prefix while a code with no prefix is offered to all ranks.

The auto reply placeholders cover a different set of live values, including the number of followers, the number of viewers, the live room like count, the current live duration, the popularity value, Beijing time and a recommended weather line. A separate weather block accepts a city, a date, a weekday, humidity, day and night temperature, minimum and maximum temperature, wind direction for day and night, wind force, sunrise and sunset, and a set of short daily tips for washing a car, going out, applying makeup, choosing clothes and catching a cold. A keyword ban parameter carries the ban duration in hours, and the documentation states that a value above 720 or below 1 falls back to one hour.

The weather trigger has a strict format: the question must start with @ or # and end with the Chinese word for weather, with a time expression in between.

%giftCode%
提督-456
#广州后天天气

The reply condition syntax is also specific. A keyword can carry a condition A, a condition B and a send value C, and the same mechanism works with multiple keywords, which is how a single message can be triggered by several different words with different conditions.

Captain state lives in a local file named guardFile

One feature stands out because it reaches outside the WebUI into the filesystem. When the option to send repeatedly to captains is enabled, the captain information is saved locally, and the documentation says this setting needs the danmuji to be restarted so it can read the existing count. The restart also slows the connection to the room while the existing list is read, which the documentation states outright.

The local folder is called guardFile and the file format is guards, with the room number in the name, holding entries in the form uid,uname. The documentation says the file can be edited by hand to add entries, and warns that entries must not be empty. The reason this matters is scope: the feature only counts captains that were present while the danmuji was running, so a file-based history is the only record. That is a useful audit trail for a small room and an obvious gap for anyone who needs a complete history of who joined the guard programme.

The same area of the project exposes cookie handling. Login is done either by scanning a QR code or with a cookie, and the minimum parameters for a manual cookie are bili_jct and SESSDATA. Those two values are session credentials for a Bilibili account, and the documentation shows that the tool can also change them by hand. Anyone running this on a shared or hosted machine should treat that machine as holding a logged in account.

Uneven release dates, a GPL-3.0 licence, and a GPL-3.0 copyleft question

The release history is not on a metronome. Version 2.7.0.5 was published on 2025-07-29, version 2.7.0.6 on 2026-04-28 and version 2.7.0.7 on 2026-09-03, and the last push to the repository was on 2026-09-03 as well. Between the first and second of those dates is a gap of about nine months, which tells you that a gap of several months between versions is normal for this project rather than a sign of trouble. The repository is not archived.

The licence is GPL-3.0, and the README carries a badge pointing at the GNU licence text. Two consequences follow for anyone planning to build on it. A GPL-3.0 project distributed as a binary obliges you to pass on the corresponding source under the same terms when you redistribute it, so if you want to ship a modified build to your own viewers, you need to be ready to publish your source. Separately, the inclusion of a bundled runtime in the portable Windows build, which the documentation says uses an openjdk8 distribution, is exactly the situation where the runtime's own licence terms and the project's terms both apply. This is not legal advice, only the reason to read the licence file in the repository root before redistributing anything.

The repository layout also indicates a conventional Gradle build, with build.gradle, settings.gradle, gradlew, gradlew.bat, a lib directory, a deploy directory and a src directory at the top level, so building from source rather than from a release archive is possible in principle.

Where a Java danmuji is the wrong tool

The honest failure modes are visible in the documentation rather than hidden. The tool is a Java server application, so it asks for a runtime, a long lived process and a browser reachable panel, which is more than a chat overlay needs. The experimental features are labelled as such: auto reconnect, live auto check-in, the daily first day plus one hundred affinity task, simulated online presence and the retired online heart. The daily check-in description is blunt, the daily check-in completes the first day task worth one hundred affinity points from the existing medal list, and any barrage sent by the danmuji can also complete that first day task.

Moderation is present but thin. The web advanced barrage view can mute a user manually, open a user's personal space and revoke a mute through room management, and the keyword ban is embedded inside the auto reply feature rather than being a separate moderation engine. A blacklist helper can be consumed by the gift thanks, the welcome helper, the follower thanks and the auto reply, matching on user id and a fuzzy name.

The comparison worth naming is not another danmuji product but the class of tools this one belongs to. A plain browser extension or a local chat client is thin, disposable and needs no credentials, while this project is thick, persistent and holds a session. If the job is simply reading chat, this project is heavier than the job. If the job is thanking gifts and posting scheduled adverts unattended, the feature surface here is where the weight pays for itself.

Editorial conclusion

Adopt it if you run a Bilibili live room from a machine that can stay on all night, you accept holding SESSDATA and bili_jct cookies on that machine, and you want gift, follow and entry thanks on timers rather than by hand. Do not adopt it if you need a thin desktop overlay, if you cannot dedicate a Java runtime, or if you want a moderation product with an audit trail. Verify first that the browser you plan to use matches the support table, that the release archive you download actually contains the jar name the documentation prints, and that the platform tolerates the gift and follow messages your templates generate before you point the tool at a live room.

Frequently asked questions

Official sources

1. BanqiJane/Bilibili_Danmuji on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases