LeyckerS/moondownloader for Windows Bulk Downloads

Two Host-Specific Extraction Paths

Moon Downloader addresses a narrow but concrete problem: downloading several files from two file-hosting services without treating every URL as an ordinary browser download. It is intended for Windows users who have batches of datanodes.to or fuckingfast.co links and want a single queue with extraction, transfer progress, completion states, and failures visible in one place. The project supports Python 3.10 and later and is distributed under the MIT license.

The two providers do not use the same extraction mechanism. datanodes.to requires real Chrome extraction over the Chrome DevTools Protocol, with tokens and page actions obtained from the rendered site. fuckingfast.co uses a pure-HTTP path that depends on `curl_cffi` and its Chrome TLS fingerprint. That distinction matters when evaluating whether the project is appropriate. Moon Downloader is not presented as a general download manager with pluggable host adapters. Its documented scope is datanodes.to and fuckingfast.co.

The choice of architecture also affects runtime behavior. A batch containing only fuckingfast.co links does not launch Chrome, according to the README. A batch containing datanodes.to links opens one shared Chrome instance on demand, even when multiple extractors are active. This keeps browser startup out of the HTTP-only path while avoiding one browser process per link. The GUI and CLI import the same `BrowserGate`, so the browser decision is centralized rather than independently implemented in each front end.

The README reports performance figures for specific configurations, including approximately 250 MB/s on a 2.5 Gbps fiber connection and 195.7 MB/s across 124 links with eight download streams. Those figures are claims documented by the project, not independent measurements, and they should not be treated as expected throughput for every network, host, file size, or disk setup.

Engine, Queue, and GUI Data Flow

The core is an engine-backed download process rather than a collection of independent browser actions. The repository includes `moon_engine.py`, `moon_extract.py`, `moon_download.py`, `moon_cli.py`, `moon_bridge.py`, and `render_gui.py`. The README identifies `BrowserGate` in `moon_extract.py` as the owner of browser startup, while the GUI and CLI consume the same engine state.

For GUI updates, the page does not receive direct writes from Python. It requests `snapshot(cursor)` roughly twelve times per second. This pull-based design keeps DOM changes on the page's own timeline. The interface can therefore receive a later snapshot without Python having to block on a UI mutation. The page also receives the current transfer rows, host names, phases, and log information from the engine snapshot model.

The log interface uses a bounded ring containing up to 6,000 lines and a monotonic counter. The page asks for entries after a cursor. If the reader falls behind by more than the ring can hold, the server returns the oldest line still available rather than silently dropping the gap. That behavior makes the limit explicit and gives the page a detectable recovery case.

Configuration input is normalized at `Engine.apply_cfg()`. The README says every numeric value sent by the page is coerced and clamped at this boundary before it reaches a semaphore. This is a meaningful security and reliability boundary because concurrency and other numeric settings are constrained in one audit point rather than being validated independently at every control. It does not mean that every host interaction is risk-free. The extraction path still depends on external pages and provider behavior.

Installing the Windows Runtime

The README directs users to the project's latest GitHub release page for downloads. The documented runtime requirements are Windows, Python 3.10 or later, Playwright, and Edge WebView2 for the GUI. The repository also provides `start.bat`, but its contents are not included in the available repository documentation, so a precise launcher command cannot be confirmed from the stated material.

The dependency file gives the required Python packages and their version ranges. `aiohttp` supplies asynchronous HTTP downloading, Playwright supplies browser automation, and `curl_cffi` is required for the Chrome TLS fingerprint used by the fuckingfast.co path. The file also states that `pywebview` is not needed for the main GUI because the interface runs in Edge or Chrome through the `--app` mode served by `moon_bridge.py`. It may be installed only for the optional `python moon_bridge.py --pywebview` route, which is the only optional installation note documented there.

The first-use sequence is therefore release-oriented rather than a documented one-command workflow. Obtain the Windows release, use the repository's documented dependency setup for Python 3.10 or later, and ensure that the required browser runtime is available for the provider path being used. The README does not provide a complete CLI invocation, a release archive structure, or a configuration file example. Those details should be checked against the selected release rather than inferred from the file names.

For a first real use, prepare a batch containing only supported provider links and choose either the CLI or the GUI. The CLI is the more appropriate starting point for a headless Windows task because it reports the engine's own counts. The GUI is more suitable when the user wants visible transfer rows, filtering, state chips, and an engine log. Neither interface should be expected to accept unsupported hosts.

CLI Progress and the WebView2 Interface

Version 4.2 changes the CLI progress line so that it reads the same `Engine.snapshot()` used by the GUI. According to the release description, the line names the current phase, such as `extracting 12/48` and later `downloading 30/48`. It also stops repeating output while extraction is slow. This is useful for scripts and for users who need to distinguish a stalled extraction from active transfer work.

The CLI also has structured exit codes in the documented release history. That matters when an automated script needs to distinguish success, partial completion, and total failure. The release notes do not enumerate the exact numeric exit-code values, so a caller should inspect the selected version's documentation or implementation before building automation around them.

The GUI is served by `moon_bridge.py` and rendered through Edge or Chrome in `--app` mode. Its transfer view shows live transfers, completed items, downloaded data, ETA, host identity, and filtering controls. The README states that the visible rate is the primary figure, with completed, downloaded, and ETA treated as reference values. The interface also includes a bounded engine log. The screenshots are explicitly based on a page mock engine, so the displayed values in the screenshots must not be read as evidence of live throughput.

The GUI and CLI are not separate download implementations. That shared engine is a useful design choice for consistency, but it also means that a defect in the engine can affect both front ends. Users who need automation should prefer the CLI, while users who need local visibility should use the GUI and understand that it depends on WebView2.

Failure Handling and Provider Boundaries

Moon Downloader has a few clearly documented failure boundaries. Version 4.1 fixed handling of `ENOSPC`. Previously, a full destination disk was treated as an ordinary transfer error, allowing the queue and retry machinery to fetch data that could not be written. The current behavior detects the error by `errno`, aborts the run, identifies the destination folder and shortfall in the live log, and leaves temporary files resumable. This is a direct operational constraint: destination capacity must be checked before a large batch begins.

Stopping the application is also intended to interrupt transfers already in flight. The earlier implementation set a stop flag and closed Chrome while an active transfer could continue, making the stop action appear ineffective during large downloads. The release notes say that behavior was corrected. Temporary files are relevant when diagnosing interrupted or disk-related runs, and the documentation does not describe a separate rollback command.

Provider changes are a larger operational risk than ordinary queue errors. The V4 release notes explain that datanodes.to removed an earlier form step and that the extractor had to be adjusted for the new step-two flow. The same release notes say that fuckingfast.co added Turnstile to `POST /f/<id>/go`, causing the pure-HTTP path to return 403 until it was repaired. The project therefore depends on the current behavior of external services. A host change can break extraction even if local queue logic and storage remain unchanged.

The `curl_cffi` dependency is required for the documented Chrome TLS fingerprint on the fuckingfast.co path. Removing it would conflict with the stated provider design. Likewise, the browser-free claim applies to batches containing only fuckingfast.co links, not to mixed batches containing datanodes.to links.

Choosing Between Moon Downloader and Browser Downloads

The practical alternative is a normal browser download workflow: open each supported provider page, let the browser perform its own page interaction, and save files individually or through browser download management. That approach avoids Moon Downloader's provider-specific extraction code and its Python runtime, but it does not provide the same project-defined batch queue, engine snapshot, host-aware progress table, or CLI phase reporting.

Moon Downloader is more appropriate when the input is already a collection of supported links and the goal is a single asynchronous transfer process. Its aiohttp streaming and configurable download concurrency are designed for queues rather than isolated page saves. The shared engine also gives the GUI and CLI the same view of extraction and transfer state, which is more useful than maintaining separate scripts for the two interfaces.

Browser downloading is the simpler choice when there are only a few links, when the user does not want to install Python dependencies, or when a provider is outside the two documented services. Moon Downloader should not be selected merely because it is called a bulk downloader. Its documented implementation is tied to datanodes.to and fuckingfast.co, with browser automation required for one provider and TLS-fingerprint HTTP extraction required for the other.

There is also a maintenance tradeoff. The repository is not archived, and the last push was on 2026-10-03. Recent releases include v4.2 on 2026-09-09, v4.1 on 2026-08-12, and v4.0 on 2026-08-05. Those facts indicate recent project activity, but they do not remove the upgrade cost of checking release notes, dependency changes, and provider repairs.

Editorial conclusion

Moon Downloader fits Windows users who already have links from datanodes.to or fuckingfast.co and need queued transfers with progress reporting. It is a poor fit for other hosts, non-Windows environments, or workflows that require a documented generic file-hosting integration. Verify the release you download, confirm that the selected provider path matches your links, and check destination disk space before starting a large batch.

Frequently asked questions

Official sources

1. LeyckerS/moondownloader on GitHub
2. License: MIT
3. Project website
4. README
5. Releases