Stash: the lossless relay is a pool of the maintainer's own accounts, and the downloader binary refreshes itself daily whether you use it or not

The lossless relay runs on the maintainer's own accounts

The lossless story has three options and the third is the one worth reading twice. You can connect your own lossless account, in which case the app asks for your email and password once, sends them to that service to mint a token, stores the token and discards the password, and then works from your own subscription. You can point it at a relay you run yourself. Or you can use the project's relay, which the page describes as running on a few paid accounts the maintainer holds. The page is careful to say the audio never passes through the relay: it hands the phone a short-lived link to the service's own content network. What is shared is the account, not the audio, and the page also says the relay hostname is not compiled into the app, so a build you make from a plain checkout has that path switched off entirely.

The relay address arrives by signed configuration, on every cold start

That last point is a mechanism as much as a guarantee. The official build fetches a signed configuration document at each cold start, and that document is what names the relay. A source checkout has no configuration address at all, so a self-built application has nothing to fetch and the lossless path is inert. The design is sensible in one direction: the signature means the build will not accept a relay address from anyone but the project. In the other direction it is worth being clear about what a remote, signed, runtime-selected endpoint means. The host your phone sends track requests to is not fixed at build time, and the set of hosts the app can reach is therefore decided by a document you did not compile, on a network you did not choose, at the moment you launch it.

A downloader binary updates itself daily whether you use it or not

The host list is the most useful page in the project because it is a disclosure rather than a claim, and two entries in it deserve attention. One says a media downloader used for YouTube audio updates itself from its own nightly release channel. The next says the downloads that fetch it come from a code host and its object store, and that the nightly binary is refreshed every twenty four hours whether or not you use streaming. So an executable from a third party nightly channel is fetched daily on every install that has the official build, independent of whether the feature is enabled, and the privacy section's claim that no analytics and no trackers exist sits alongside a routine unattended code download. That is a normal trade for a project chasing a fast-moving upstream, and it is a supply chain decision rather than a privacy one.

The official build carries shared API keys and a self-built one does not

The page draws a line between what the official release can reach and what a build from a plain checkout can reach, and the difference is not small. A self-built version has no keys for a scrobbling service, no proxy and no relay configuration. The official build carries the keys, which means the scrobbling calls are made with credentials the project holds rather than ones you hold. Scrobbling is off by default, so the default install makes no such call. The more interesting item is the recommendation source: connect that same service and it appears as a sync source and maintains a rotating playlist of tracks it suggests from your listening. That is a third party influencing what gets downloaded and then scrobbled back, which sits oddly beside the claim that credentials never leave the device.

A catalogue endpoint is called on by default, with no account

One entry in the host list is not optional. The lossless service's own catalogue hosts are used for three rows on the home screen, and that is marked as needing no account and being on by default, with instructions for turning it off in settings or hiding the rows in the layout. The same entry notes a second host used to refresh the service's public web player key, which is the credential that service uses to gate its own browser player. So on first launch, by default, with no account connected, the application fetches a public key from that service and uses it to show three rows of recommended albums. It is disclosed, it is switchable, and it is the only default-on call to a host that is not one of the two streaming services.

Credentials are split between an encrypted store and app-private storage

The privacy section is specific about how things are kept. There is no account server, no login, no analytics and no third party crash reporting, and it concedes that a handful of hosts the project itself runs are contacted, with the claim that none of them ever sees a credential. Cookies are encrypted with a modern authenticated cipher using Google's crypto library. The tokens for the three services the app connects to are encrypted, and the note is that each is only ever sent back to the service it came from. Everything else sits in app-private storage without that extra layer. So the credential inventory is split: the tokens that grant access to an account are encrypted, and the rest of the local state is private to the application but not encrypted by the application. A rooted device changes the second category and not the first.

Ninety nine percent match rate, and a button for the other one

The library section leads with matching, described as finding the right version of a track ninety nine percent of the time. No method, no test set and no measurement appear anywhere in the page, and the claim is about cross-service version matching, which is the hardest part of merging two catalogues with different masters, different durations and different regional releases. What makes the claim usable rather than marketing is the correction path sitting immediately next to it: if the wrong version was chosen, one tap from the now playing screen queues a re-search. The same pattern runs through the rest of the page. When no lossless source is connected, playback falls back to a lossy format or to nothing, and the home screen says so rather than pretending. A product that tells you when it is degraded is worth more than one that claims a percentage.

Editorial conclusion

Use Stash if you want your own streaming library mirrored to a phone with real files on disk, and if you connect your own lossless account rather than relying on the project's relay. Five things to know first. The lossless relay is backed by a small number of paid accounts the maintainer holds, and whether that is acceptable depends on the terms of the service providing them, which is a question to ask before you rely on it rather than after. The relay address is not compiled into the app; the official build fetches a signed document naming it on every cold start, which is a good security design and also a channel the project can change at any time. A media downloader binary is downloaded from a nightly channel and refreshed every twenty four hours whether or not you use the feature that needs it. The official build ships shared API keys for a scrobbling service that is off by default but can also suggest tracks into your library. And the claim that a track match is right ninety nine percent of the time is a figure with no method behind it, which is why there is a one-tap way to flag a wrong one.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes