FrostWire is a BitTorrent client whose peers share a search index

One monorepo, three source trees and a shared core

The FrostWire repository is the main one, and the readme explains its shape in three bullets. The android directory holds the sources for FrostWire for Android, the desktop directory holds the sources for the desktop client for Windows, Mac and Linux, and the common directory holds sources shared by the desktop and Android clients.

That layout is the practical consequence of shipping two applications from one codebase. Anything both clients need, and the readme calls the shared module the common sources, lives once. The split matters when you are evaluating the project as a dependency or as a codebase, because a change to a shared component lands in both products and has to be tested in both.

The project itself describes as an easy to use cloud downloader and BitTorrent client, with the tagline Search, Download, Share. The releases confirm the two product lines: FrostWire 7.1.1 build 333 for the desktop in October 2026, 7.1.0 build 332 a few days earlier, and FrostWire for Android 3.2.2 build 778.

The build numbers in the tag names are a small detail worth noting, since they signal a continuous build system rather than a hand packaged release. The repository also carries a telluride directory, a skills directory and a set of design documents at the top level, which are discussed further below.

IceBridge removes the central index from search

IceBridge is the part of FrostWire that is unusual, and it is a standalone relay servent providing reliable, authenticated, fragmented mesh transport between FrostWire peers for distributed search.

The problem it addresses is architectural. A search index has to live somewhere, and when it lives on a central server, that server is both a single point of failure and a party that can observe what people are looking for. The readme states the goal plainly: IceBridge enables peer-to-peer search without a central index server.

The deployment model is described next. Each FrostWire instance runs a local IceBridge daemon, in-process on the desktop and as a separate JAR for testing. So the search capability is not a client talking to a remote service, it is a component running on your own machine that talks to other people's components.

That is what the mesh transport is for. The daemons find each other, exchange signed search requests and return results through the peers that happen to be connected. The readme lists the protocol features as Ed25519-authenticated handshakes, ACK and retransmission, and fragmentation with reassembly for payloads that exceed the UDP MTU.

For a user, the visible effect is that search works without a central index, which also means the completeness of results depends on the peers currently reachable. That is a different kind of guarantee from a hosted index, and it is the trade the design accepts.

rUDP, Ed25519 signatures and a localhost control API

The mechanics of the IceBridge transport are described in enough detail to be useful to anyone considering the design.

The daemons communicate over rUDP, Reliable UDP, described as a custom protocol built on Netty. The reliable part is implemented in the protocol rather than assumed from TCP, because the peers are not connected by a stream: there is an ACK mechanism and retransmission for lost datagrams, and fragmentation with reassembly for payloads larger than the UDP MTU, so a large result set is split into datagrams and put back together at the other end.

Authentication is asymmetric. The handshakes are authenticated with Ed25519, search requests are signed with the peer's Ed25519 key, and responses are verified by the requester. So a peer cannot answer a query it did not receive, and a node cannot inject a result into a response without the key.

The client does not speak rUDP to its own daemon. The desktop client talks to its local daemon over a localhost HTTP control API, which keeps the boundary between the application and the transport simple, and it also means the daemon can be restarted or tested independently as its own JAR.

The design documents at the repository root make it clear that this is a system under active design discussion rather than a finished product. The top level carries ICEBRIDGE.md, a document reviewing the IceBridge architecture and another covering failure handling, alongside DESIGN_DYNAMIC_QUERYING.md, DESIGN_RELAY_REGISTRY.md and SPEC_KARMA_CHAIN.md. Reading the architecture review and the failure handling plan is the fastest way to understand what the authors consider settled and what they do not.

Building the desktop client needs JDK 19 and gettext

The build section is short. To build you need the Java Developer Kit 19, and then you go into the desktop directory and follow the instructions in its README.md file.

The extra requirements are conditional, which is worth noting. If you want to work with the translation bundles, you need gettext installed, because the text extraction and bundling tasks are run as gradle gettextExtract and gradle gettextBundle. On a Mac the readme gives the brew line, and on Ubuntu the apt line, and for Windows developers it recommends MinGW with the gettext package, along with using Git for Windows terminal rather than cmd.exe so that the scripts behave as they do on Linux and Mac.

That gettext requirement only bites if you touch localisation, and the JDK 19 requirement applies to everyone building from source. Both point at the same conclusion, which is that this is a Java project with a Gradle toolchain rather than something you run from a binary and patch.

The Android side is separate. The readme says to build with Android Studio or to go into the android directory and run ./gradlew assembleDebug, with debug builds created inside the android/build folder. The Gradle wrapper means the Android build does not need a system Gradle install, unlike the desktop path where you are expected to invoke Gradle tasks yourself.

Contribution runs through a fork, a feature branch and a rebase

The contribution guidelines are unusually detailed, and they describe a project where code review capacity is the scarce resource.

The procedure is the standard fork based flow, described step by step. Clone the repository, which is the origin repo, and make a fork of it into your own GitHub account. Then add your fork as a remote on your local copy under your username as the remote alias.

cd frostwire
git remote add your_github_username_here https://github.com/your_github_username_here/frostwire

For later contributions you create a branch with a descriptive name, named after the issue number if one exists, for example issue-233. The guidance on patch shape is the part to internalise: focus on the patch, and do not waste time reformatting code, because reformatting noise makes a real fix hard to review, and the readme says plainly that they are a very small team who cannot waste review time on lines that shifted. Adding tests for the issue and the fix is described as earning extra credit.

Pull requests should come from a feature branch on your fork, and the maintainers state that they merge to master only if the build is not broken. If the branch has been open a while, master will have moved, and the readme asks you to fetch and rebase rather than merge master into your branch.

    git fetch upstream master

    git checkout my-branch
    git rebase origin/master

The coding guidelines on top are short and opinionated: keep it simple, do not repeat yourself, and prefer well named methods and reusability over a lot of comments, since code should be self-explanatory.

GPL-3.0, regular tagged builds and a desktop plus Android split

The licence is GPL-3.0, which is the usual choice for a desktop application of this kind and matters more if you plan to study the code and build something on it than if you simply install it.

Activity is current. The repository is not archived and the last push was on 2026-10-21, and the release tags show a steady cadence in the weeks before that, with the desktop at 7.1.1 build 333 on 2026-10-16, 7.1.0 build 332 on 2026-10-10, and the Android client at 3.2.2 build 778 on 2026-10-09. The desktop and Android lines move on separate schedules, which is what you would expect from two products with different review and release constraints.

The version gap between the two products, desktop 7.x and Android 3.x, is a reminder that they share a codebase but not a release train. A change in the common module can reach users of both clients at different times, and the shipped versions will not match.

Where FrostWire is the wrong tool is narrower than the feature list suggests. The IceBridge design gives you search without a central index, and that is a real architectural advantage for anyone who objects to depending on a search server, but it also means the completeness and the latency of a result depend on which peers are reachable. If you need a search that reliably returns everything a server knows, a peer-to-peer index is the wrong shape, and a conventional index server is the alternative, with all the centralisation that implies.

Editorial conclusion

FrostWire fits people who want a torrent client and a general downloader in one Java application and who care that the search side does not depend on a single index server, since IceBridge spreads that work across the peers you are already connected to. It is a poor fit if you want a small client without a Java runtime, if you need search results that a peer-to-peer index cannot promise to be complete, or if you cannot work with a GPL-3.0 codebase. Check first that the JDK 19 and Gradle toolchain suits your machine, that the gettext path is available if you intend to touch the translation bundles, and that you understand the completeness trade-off in the IceBridge design before you depend on its search.

Frequently asked questions

Official sources

1. frostwire/frostwire on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases