Open-source project
caigg188/LDStatusPro avatar
caigg188/LDStatusPro

LDStatusPro is a browser side dashboard bolted onto a Discourse forum

一款功能强大的 Linux.do 社区增强工具以及相关综合服务开源项目。包含论坛辅助脚本、LD 士多前端源码、LDStatusPro官网源码等。

1,197 stars69 forksVueMIT

At a glance

What is it?
LDStatusPro is a Tampermonkey userscript plus two front end sites that add reading time tracking, trust level progress, opt-in leaderboards, cloud sync and an AI post summariser to the Linux.do and IDCFlare forums. The repository holds only the front end, every feature reaches a hosted API, and the reading stats are the point of the whole thing.
Who is it for?
LDStatusPro suits a regular Linux.do or IDCFlare reader who wants visible reading statistics, trust level progress and an optional leaderboard without leaving the forum, and who is willing to log in through OAuth so the data can sync.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly Vue, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A panel that appears on the forum page

LDStatusPro is a userscript that runs in the browser through Tampermonkey and adds a panel to two Discourse forums, Linux.do and IDCFlare. The two sites get the same feature set, with independent OAuth authentication and data that does not mix between them.

The core idea is a reading time system. The script tracks how long the reader has been active and grades it against a set of levels with names and colour schemes, starting from a first tier for the first thirty minutes and climbing to a top tier beyond six hundred minutes. Administrators can redefine the level ranges and names from the backend system settings, so the thresholds are not fixed by the script. Activity detection is automatic, with sixty seconds of no interaction pausing the count, and a twenty four hour local cache means the level still shows offline.

Around that sit the features a forum regular actually notices. A trust level tracker shows progress as a ring, breaks activity into browsing, reading, likes, replies and posting, and offers 365 day trend views as a heatmap, a line chart and a bar chart, with a milestone notification when level five is reached. An activity panel lists read history, favourites, reply records, Discourse reactions, like history and a search over titles and tags. A CDK panel shows the user's avatar, nickname, trust level and score, the projects available, the remaining quantity, the claim requirements and a one click copy button for the code. A feedback ticket form opens from the user info area and supports two way replies with an unread badge.

This repository is front end only, and the API is the dependency

The most important structural fact is stated plainly: the repository contains only the front end trio, and the backend, admin panel, security service and observability platform are separate repositories. That means the features that need a server are not self contained here.

The three parts are laid out in the README as a tree. LDStatusPro.user.js is the Tampermonkey script and calls api1.ldspro.qzz.io for OAuth, reading data, leaderboards and tickets. ld-store/ is the store web front end, built on Vue 3.5, Vite 8, Pinia, Vue Router 4 and Tailwind 3.4, and it points at ldcstore.com, routing authentication to api1, business calls to api2 and images to a separate host. website/ is the product site, built on React 19.2, TypeScript, Vite 7.2, Tailwind CSS 4 and Framer Motion, and its annual report calls api.ldspro.qzz.io. The home page of the site is static text and does not go through a CMS API.

Authentication is OAuth, and api1 issues the JWT for the user token. The admin panel is not part of this repository either, so a reader cannot self host a copy of the whole product from these files. The store entry is deliberately separated from the main script and opens in a new tab, which the README presents as avoiding the compatibility problems that an embedded panel caused.

The privacy story is mixed but stated. Data is kept in local storage and is not forcibly uploaded, cloud sync and the leaderboard are opt-in, a user can leave the leaderboard or sign out, and accounts and sites are stored separately. XSS protection is described as complete input validation and escaping on both sides, and SQL injection protection as parameterised queries, which is a claim about the backend that this repository does not contain.

Leaderboards are opt-in, capped at fifty, and rate limited by hand

The reading leaderboard has three switches, a daily, a weekly and a monthly board, and it shows the top fifty readers by time. The top three get distinct medal treatment, and joining is a choice the user makes rather than a default.

Refreshing is manual rather than automatic, and each board has its own five minute cooldown. That is a deliberate design choice with a visible consequence: the numbers you see are as fresh as the last manual refresh, and hammering the refresh button does not give you a fresher board. For a community that cares about the reading contest, that is a fair trade, since automatic polling would also be a load problem for a hobby project.

The cloud sync feature is the other half of the tracking story. It synchronises across browsers, covering Chrome, Firefox, Edge and Safari, and across devices from desktop to tablet and phone. Merging is smart in a specific sense: when two devices report different values for the same day, the larger one is kept. New devices restore from 365 days of history, and the README states that history synchronisation is available to users at every level rather than only some tier of the community.

The performance work behind those features is described in the same document, and it reads like a list of things that went wrong before. Historical data is aggregated with an LRU cache, writes are batched to reduce storage operations, API responses are cached with request de-duplication and buffering, rendering is asynchronous so the interface does not block, failed calls retry with exponential backoff, and a global request queue exists to prevent 429 responses.

The AI summary and the credit panel both lean on the hosted side

Two features extend beyond measurement. The first is an assistant for summarising forum threads: one click produces a summary of the topic in a brief or a detailed mode, the summary can be followed up with a multi turn conversation based on it, replies stream in as they are generated, the history of summaries is kept and can be viewed, copied or deleted, and the prompts are customisable so the behaviour can be shaped.

The second is the LDC credit panel, which reads the balance from credit.linux.do, estimates the day's earnings from changes in the Linux.do points, plots a seven day income and spending trend, lists transactions with filtering by time and type, and offers tip tiers of 2, 5, 10 and 50 LDC.

Both of these are the clearest demonstration of the repository's boundary. The userscript is the front end, and the intelligence behind the summaries and the credit data comes from services the repository does not include. The userscript itself is plain JavaScript with no runtime npm dependencies and around seventeen thousand lines, which is a reasonable size for a single file that has to run inside a page it does not control, but it also means the reading data itself is largely local until you sign in.

For a reader who cares about the statistics, that is a fine arrangement. For anyone who wants to run their own instance of the community tooling, the split described in the README is the obstacle, not the script.

Versions are tracked in the script header, not the changelog

The version story has a wrinkle worth knowing before you install. The README states that the script version is whatever the @version header in LDStatusPro.user.js says, currently 3.9.0.6, and that update_log.md stops at v3.5.4.10, with later changes to be read from git and the recent entries. So the changelog file is not the current source of truth for what changed.

The releases tell a similar story with a different numbering. The published releases are v3.9.0.6 on 2026-10-06, v3.9.0.1 on 2026-04-20 and v3.9.0.0 on 2026-03-12, while the technical stack section of the README still quotes version 3.9.0.3 for the userscript, and the package metadata in the repository root carries version 0.0.0 with private set to true. Three different version numbers are visible in the project at once, and only the one in the script header governs what actually runs in your browser.

The repository is not archived, and the last push was on 2026-10-19. The licence is MIT, so the script and the two front end sites can be read, modified and redistributed under that licence, and the repository also carries a CODE_OF_CONDUCT.md, an AGENTS.md, a CI.md, a DOCS.md, a prd.md and a design/ directory that holds the brand assets, logo, static resources, motion guidelines and the desktop, tablet and phone adaptation standards.

Installing it and seeing the panel

There is no build step for a user, because there is nothing to build. Install a userscript manager first: Tampermonkey is the recommendation for Chrome, Edge, Firefox and Safari on macOS, and Stay is the option listed for Safari on iOS. Then install the script itself, either directly from the raw file on the main branch of the repository, which gives the latest version and updates immediately, or from the GreasyFork listing, which is described as a backup source that syncs automatically.

After installation, visit Linux.do or IDCFlare and the panel appears on the page. Clicking the login button is what enables cloud sync and the leaderboard, which is the moment your reading data starts leaving the browser, so it is worth being deliberate about it. The store entry in the panel opens the store web version in a new tab, leaving the forum page untouched.

For developers, the repository root has a package.json with a small set of scripts. The lint target runs eslint over the userscript, the format target runs prettier over the same file, and the check target runs the lint, the tests and the embedded core check in sequence:

bash
npm run lint:userscript
npm test
npm run embed:core:check

The test script runs node --test over the files in tests/, and there is a separate script that validates the agent samples. The embedded core step, with a matching check mode, suggests the script embeds a generated core that has to be kept in step with its source, which is exactly the kind of detail that a fork of this project needs to get right.

Editorial conclusion

LDStatusPro suits a regular Linux.do or IDCFlare reader who wants visible reading statistics, trust level progress and an optional leaderboard without leaving the forum, and who is willing to log in through OAuth so the data can sync. It does not suit a reader who objects to any of its reading behaviour being reported to a hosted service, and it is the wrong tool for anyone who needs a self hosted version, because the repository states that the backend, admin panel, security service and observability platform live in separate repositories. Verify first that the version in the script header matches the release you expect, since update_log.md stops at v3.5.4.10 while the current script is 3.9.0.6, and read the privacy table before turning on cloud sync or joining a leaderboard.

Frequently asked questions

What is LDStatusPro and what does it add to Linux.do?

It is a Tampermonkey userscript that adds reading time tracking with graded levels, trust level progress, 365 day activity trends, an optional reading leaderboard, cloud sync and an AI post summariser. The same feature set is provided for Linux.do and IDCFlare, with separate OAuth and separate stored data.

How do I install LDStatusPro?

Install Tampermonkey in your browser, then install the script either from the raw LDStatusPro.user.js file on the repository's main branch or from the GreasyFork listing, which is described as a backup source that syncs automatically. Open Linux.do or IDCFlare and the panel appears, and signing in is what turns on cloud sync and the leaderboard.

Is my reading data uploaded automatically?

No. The README states that data is stored in the browser and is not forcibly uploaded, that cloud sync and the leaderboard are opt-in, and that a user can leave the leaderboard or sign out at any time, with accounts and sites stored separately.

Can I self host the backend for LDStatusPro?

Not from this repository. It contains only the front end trio, and the README states that the backend, admin panel, security service and observability platform are independent repositories, with the script calling api1.ldspro.qzz.io for OAuth, reading data, leaderboards and tickets.

Which version of the LDStatusPro userscript is current?

The @version header in LDStatusPro.user.js, which the README says is 3.9.0.6. The changelog file update_log.md stops at v3.5.4.10, so later changes have to be read from the repository history.

Official sources

  1. caigg188/LDStatusPro on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
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.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/caigg188-ldstatuspro.svg)](https://hysenlabs.com/projects/caigg188-ldstatuspro)

Was this useful?