Johnserf-Seed/f2: three version numbers, one downloader, and a release trail that stopped in 2024

Three version schemes, and the published one stopped in 2024

Three numbering schemes describe this project and none of them line up. The releases stop at v0.0.1.7 dated 2024-12-31, then v0.0.1.6 dated 2024-06-28 and v0.0.1.5 dated 2024-04-04, while the last push to the default branch is dated 2026-09-12. Code has therefore moved for more than a year after the last upload. The README opens by warning that the branch shown by default is the development branch `v0.0.1.8-pw3` and that its changes may not have reached PyPI, and pyproject.toml keeps the version out of the manifest entirely by listing `dynamic = ["version"]`. A third scheme sits in the release notes themselves, which are headed `v0.0.1.7-pw2`, `v0.0.1.6-pw2` and `v0.0.1.5-pw2`, carrying a suffix the published tags do not have. Anyone pinning a version has to decide which of the three to record, and the repository never states which one matches the code a given install contains.

Every runtime dependency uses an exact pin, and a formatter is in the list

pyproject.toml pins each dependency to one version instead of a range:

dependencies = [
    "babel==2.13.0",
    "black==24.10.0",
    "click==8.1.7",
    "rich==13.9.3",
    "httpx==0.28.1",
    "aiofiles==24.1.0",
    "aiosqlite==0.20.0",
    "pyyaml==6.0.2",
    "jsonpath-ng==1.6.1",
    "importlib_resources==6.4.5",
    "m3u8==3.6.0",
]

Two consequences follow. With exact pins, a later fix to httpx or click lands only when somebody edits this file, so an install reproduces a frozen set of libraries rather than a patched one. And the list carries `black`, a source formatter, in the runtime set beside the async HTTP stack, which puts a code formatter into every environment that installs the package. The manifest asks for `requires-python = ">=3.10"`, the classifiers name 3.10 and 3.11, and the development status is declared as 4 - Beta, so a newer interpreter is allowed by the constraint but not represented in the metadata.

The keyword list advertises two platforms that are only todo items

The keyword list in pyproject.toml includes `bilibili`, `netease` and `watermark`. Bilibili and NetEaseMusic appear nowhere in the feature tables; they are entries on the project's own todo list for version 0.0.1.8, sitting beside a WebAPI version, Socket proxy support and Cookie, Proxy and User-Agent pools. The word `watermark` is stranger still, because nothing in the README explains what watermark handling does here and no endpoint in the tables carries that name. The description line calls the package an asynchronous full-platform download tool, and the classifiers declare both Chinese and English as natural languages, so the packaging metadata is written for discovery while the documented surface trails behind it. Keywords are the cheapest place for a project to name a platform, and this list names three things the tables do not document.

The ab signature is the load-bearing part, and platforms own it

The release notes for v0.0.1.6 record a fix for a tiktok video address returning 403 and record that douyin requests switched to the `ab` algorithm by default. The notes for v0.0.1.5 add custom User-Agent support to the `XBogus` parameters, and the notes for v0.0.1.7 say the full version of `ab` was open sourced, again with custom User-Agent support and a request that any custom User-Agent conform to the specification. Read together, these say the request layer rests on signature schemes the platforms own. The project's own history shows what happens when one of them moves: a release was needed just to restore video downloads for a single platform. Nothing in the scripts or the manifest offers a dry run, a per-target permission check or an abort switch, because each endpoint targets one platform's public API by design. Assume the signatures go stale, and keep the library pointed at material you are allowed to fetch.

Login state is a documented axis, and one marker ignores your own privacy settings

The feature tables carry a second column for account state, and the legend spells out the cost. A purple circle marks endpoints that need a login and that, in the project's own wording, ignore your own account privacy settings once you are signed in, which is how private collections, favourites and liked works become reachable at all. A black circle marks endpoints that work without a login, limited to works other people have made public. A white circle leaves the state unknown. The distinction is applied row by row rather than per app: `fetch_user_collection_videos` and `fetch_user_music_collection` are purple only, while `fetch_user_mix_videos` is black only, so inside one table some rows require your account and others forbid it. Credentials are not extracted from anywhere. The configuration documentation has a page for setting a Cookie, and the Bark table exposes `ClientConfManager` for managing client configuration, so the cookie value you supply ends up in a config file the library reads.

A database rebuild drops what was stored, and a bad file name now throws

The v0.0.1.5 notes describe three breaking changes to stored data and to file output. The database was rebuilt so that it holds the raw interface data, and readers are told to migrate or back up old records first, which describes a rebuild that replaces rather than merges. All `fetch` methods were unified to return the filter type, with a new `_to_raw` method added to turn a filter back into raw interface data, so the two shapes convert in one direction on purpose. The file name template was tightened in the same release, and a name that does not match the new specification raises an exception instead of quietly writing a file. The v0.0.1.6 notes then adjusted formats again: douyin live stream file names became `flv`, the gallery format returned to `webp`, and every timestamp defaulted to `UTC/GMT+08:00`. A script that shells out to this library across versions has to expect both the file names and the stored records to move.

Two documented endpoints are marked as never planned

The status legend has five values: implemented, in progress, not to be implemented, planned for the future, and to be deprecated. Two DouYin rows carry the never-planned value. `fetch_user_series_collection`, for short drama collections, and `fetch_user_following_videos`, for the works of accounts you follow, are both listed with a usable account state, so they read like ordinary working endpoints until the status cell is noticed. `fetch_user_mix_collection` is marked for the future. One row also reuses an existing name, since `fetch_one_video` is listed for both a single work and for a live gallery set, so the method name alone does not tell you which behaviour you get. The detail in the README is uneven across apps: Bark gets a short table of three notification endpoints plus two byte generators, DouYin gets the per-endpoint table with account and status columns, and that DouYin table is where the login legend gets applied in detail.

A Chinese README that is mostly a link list to a separate wiki

The repository's primary README is written in Chinese, and the tree also carries README.en.md. Almost every section is a list of links into f2.wiki rather than prose: install anchors for prerequisites, package manager install and compile install, a quick start page, six configuration pages including one for setting a Cookie, three command line pages, an advanced guide, an FAQ, a team page, and API and CLI pages for Bark, DouYin, TikTok, Twitter and WeiBo. The install steps themselves are not in the repository, so a reader has to leave before learning what to run. The badge row points at coverage, package metadata, a Discord invite and a third party API service whose signup link carries a referral code parameter. A CNAME file and a docs directory sit in the tree, so the site and the code are maintained as separate pieces.

Editorial conclusion

Take this library when you have a reason to archive your own feed or your own private collections, and read the version numbering before pinning anything: the published releases stop at v0.0.1.7, the branch suffix runs ahead of that, and the manifest keeps its version dynamic. Two things to check yourself before the first run are the account Cookie you are asked to place in a config file and the request signature layer, which has already needed a release of its own just to restore video downloads for one platform. The keyword list advertises Bilibili, NetEaseMusic and watermark handling that the documented endpoints do not cover, so treat the packaging metadata as intent rather than as a feature list.

Frequently asked questions

Official sources

1. Johnserf-Seed/f2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases