PRIVACY

Privacy policy

Baton is a music player for a library you host yourself. It connects to your music server, offers an optional service for sharing songs, mixtapes, books, albums and playlists with friends, and can connect to other services you set up. This page explains where your data goes, including readable sharing previews and reactions, request diagnostics and optional voice or model services.

Applies to Baton for macOS and Baton: Navidrome Music Player for iPhone and iPad. Last updated October 21, 2026.

The short version

By default, Baton talks to the music server you set up and, on the Mac, checks for updates. Sharing a song, mixtape, book, album or playlist uploads encrypted audio to Baton's service; readable previews, reactions, pseudonymous identifiers and link activity are described in Sharing songs, mixtapes, books, albums and playlists. Crash reports, lyrics lookup, scrobbling, music discovery, the music friend, cloud models for book text and voice services are all optional, and each sends only what is described below to the service you chose. HTTP services also receive ordinary request diagnostics.

What stays on your device

  • Your settings and play history. Preferences, the play queue, liked tracks, listening history, and layout choices are stored locally on the device.
  • Your server credentials. The password or API key for your music server is stored in the system Keychain on that device. It is sent only to the server it belongs to.
  • Downloads. Tracks and podcast episodes you download are stored locally for offline playback.
  • Chat and voice history. Conversations with the music assistant, and feedback you give it, are stored locally. When you use a model provider, the conversation and relevant player context, preferences and tool results can also be sent to that provider. A configured messaging bridge or your own Baton server can be part of that path.

Your music server

Baton is a client for a Navidrome or Subsonic-compatible server that you run or choose. Browsing, searching, streaming, artwork, lyrics, and ratings are all requests to that server, using the credentials you entered. What that server logs is governed by the server, not by Baton; if you run it yourself, that is you.

Update checks

The Mac app checks for new versions automatically, out of the box, by fetching a small file from Baton's own site, batonmusic.app, using Sparkle, the standard macOS updater. That request tells the site's web server that some copy of Baton asked, along with the ordinary things any web request carries, such as an IP address. It carries no identifier, nothing about your library, and nothing about your server. To stop the automatic checks, turn off Automatically check for updates in Settings → About → Updates, and use Check for Updates Now when you want one.

The iPhone app has no update feed of its own. Updates come from the App Store, under Apple's terms.

Your own Baton server

Your Baton server (the Baton gateway) is an optional service you run yourself, usually on the same machine as your music server. We do not run one for you, and no server of ours is involved in it. It does two jobs, and you can use either without the other.

  • It keeps the preferences that belong to you rather than to a device in step. The equalizer, crossfade, banned radio stations, podcast subscriptions, search history, the play queue, and which model provider the music friend uses. Credentials are never among them: those stay in each device's Keychain and move by pairing instead.
  • It runs the music friend on the iPhone's behalf. When the phone is set up this way, what you say to the friend goes to your Baton server, which runs the same conversation loop the Mac app runs and queries your music server directly. Your messages, and the library results that come back, pass through your Baton server, and your model provider key stays on that machine instead of on the phone. The phone can also be pointed straight at a model provider instead, in which case the Baton server is not involved in chat at all.

When you turn a document into a book, your Baton server also keeps the document’s text and the book’s audio on that machine until you remove them, and none of it reaches us.

Your Baton server is a machine you control, so what it keeps and what it logs are yours to decide.

Sharing songs, mixtapes, books, albums and playlists

Sharing uses a server run by Baton's developer, at batonmusic.app. Nothing is uploaded until you share something. For your first share, open the sharing composer and press Create Link; the composer explains the upload before you create it. After that first manual share, the music friend and tools you have allowed to control Baton can create links too. Copying or sending a resulting link is a separate step.

Requests to batonmusic.app pass through Cloudflare, the network company that carries the site's traffic and handles its secure connection, on their way to Baton's server.

A song

  • The song is encrypted on your device before it leaves. Baton fetches the track from your own server, encrypts it, and uploads only the encrypted copy. The key is the part of the link after the #, which browsers and link previews never send to a server, so Baton's server stores audio it cannot play.
  • Song details, if you leave previews on. Show song details in link previews is on by default. So that Messages, WhatsApp, Slack and others can show a preview, the title, artist, album, length, artwork, your note and the name you share as are stored readable. So are the artwork's accent colour, the outline of the song's waveform, its MusicBrainz ID (a public catalogue number for the recording) and a preview card image made from these details. Turn the setting off and they are encrypted too; only a rough length, such as 3 to 5 minutes, stays readable.

A mixtape

A mixtape sends 2 to 12 songs as one link, each encrypted on your device in the same way. The track titles and artists are always encrypted, though the number of tracks can be seen. Show mixtape title and note in link previews is off by default, so the mixtape's title, your note and the name you share as are encrypted too, and only a rough total length is readable. Turn it on and those three details, and the exact total length, are stored readable for link previews.

A book

You can share some chapters of a book you made in Baton, or the whole book. Some chapters go out as a song link (one chapter) or a mixtape (two or more), and follow the rules above for those, so a single chapter shared with previews on also makes its cover readable.

A whole-book link sends every chapter, each encrypted on your device. Show book details in link previews is on by default, so the book's title, author, length, your note and the name you share as are stored readable; turn it off and they are encrypted. The book's text is uploaded only if you turn on Include the text for read-along, and it is encrypted in the same way as the audio.

A whole-book link admits the number of listeners you choose (10 by default, 50 at most), so the service keeps a record for each listener who starts, to count them. That record is deleted with the link. The book player remembers your friend's place in their own browser's storage, on their device, and sets no cookies. You can have 3 whole-book links live at a time.

An album or a playlist

An album or playlist link sends up to 200 songs, each converted to AAC and encrypted on your device, one at a time. The song names, artists, their order and the cover image are always encrypted; the service can see the number of songs, their encrypted sizes, the total length, and whether the link is an album or a playlist. Show details in link previews is on by default, so the album or playlist title, its artist, your note and the name you share as are stored readable for link previews; turn it off and they are encrypted, and the preview says only that someone sent an album or a playlist.

Like a whole-book link, it admits the number of listeners you choose (10 by default, 50 at most), and the service keeps a record for each listener who starts, to count them, deleted with the link. The player remembers your friend’s place, and their shuffle and repeat choices, in their own browser’s storage, on their device, and sets no cookies. Albums, playlists and whole books share one limit: 3 such links live at a time.

Reactions

Your friend can send back an emoji. From the song player or the Baton app they can also add a name and a short reply, both optional. Reactions are stored readable, not encrypted, whatever your preview settings, together with the daily listener hash described below. They are shown only to you, in Shared Links in your Baton app, and never on the link's public page. A reaction is kept until the link expires or you revoke it.

For a song, the service also records that a reaction was sent: the emoji and whether a name or a reply was included, but not the name or reply itself. That record is kept for up to 400 days.

What is counted, and how

The share service counts what happens to a link: created, opened, played, listened to past 30 seconds, finished, reacted to, and whether someone tapped Get Baton. That is how you see that a friend listened, and how we learn whether sharing is worth keeping. Your install is identified by a random key made on your device for sharing only, not tied to your name, your server or your Apple account. When you create a link, the service also records your app's platform and version.

For listeners, the service derives a hash from the network address, browser information, share ID and a daily salt (a random value that changes every day). It stores that hash instead of an IP address in its activity records and on each reaction; the hash changes between links and days. It also records the kind of device that opened the page (iPhone, Android, Mac, Windows or Linux) and, when a messaging app fetches a link preview, that app's name. This does not make a typed name or reply anonymous, and ordinary HTTP infrastructure also receives the network address. No cookies are set and no third-party analytics run on the share pages.

How long it is kept

  • While the link lasts. A link ends when it expires after the time you choose (one, seven or thirty days), or when you revoke it. Each Extend 7 Days moves the end later, up to 30 days from that moment, and everything the link holds is kept until the new end. A link that reaches its play limit stops playing for your friend, but its encrypted audio, details and reactions stay until it expires or you revoke it.
  • When the link ends. Its encrypted audio, artwork, details, text and reactions are scheduled for deletion. Cleanup is retried if it fails, so revocation is not a promise that every stored byte has already gone. The service keeps ended-link counters and associated identifiers for up to 400 days after the link ends; individual activity and failure events expire after 400 days. The installation record described below has no expiry.
  • Backups. The share service's data is copied each night to an encrypted offsite backup. A backup copy can remain for up to about 30 nights after a link ends, and longer for now, because automatic removal of old backups is not switched on yet. Revoking a link does not erase backup copies.

Service records

  • Installation and failure records. The service retains pseudonymous identifiers derived from the installation's random sharing key, its platform and first-sharing time after links end. That record lets the service recognize the installation and enforce its limits; it has no automatic expiry in the current implementation. A later sharing request can also report a few previous failures using only fixed categories such as network, transcode or quota. Those categories are stored with the installation identifier to diagnose sharing failures and measure reliability, without the failed song, URL or raw error message.
  • Request diagnostics. Baton's web server keeps a request log for troubleshooting. For share links it records the time, the page requested (which can contain a share ID), whether it worked and how long it took, not your address. The share service logs the same kind of line. These operational logs are separate from the share activity records and are not covered by their 400-day limit. Log copies have their own retention, and revoking a link does not erase them. Cloudflare, which carries the site's traffic as described above, handles requests under its own policies.
  • Disabled links and optional preservation. If operator controls are enabled, a disabled link remains unavailable. Without explicit preservation consent for that share, ordinary expiry continues to apply. If you choose preservation when creating a share, a reviewed hold can keep its encrypted song and existing details privately for up to ninety days from the link's first disable, within the configured retention limit. Its remaining public lifetime pauses; authorized restoration resumes only that remaining time, with the same play limits and counts. Repeated disable or restoration cannot reset the ninety-day ceiling. Held material counts toward storage quota. Revoke still schedules deletion, including during court review, and failed cleanup is retried. Restoration is not guaranteed. Private case, revision, review and action records have separate bounded deadlines; a minimal installation suspension stays active until removed. These live-store rules do not establish when backup copies disappear.
  • Optional iPhone integrity checks. If the share service enables Apple's App Attest policy, a supported iPhone uses Apple to verify the app when you explicitly share. The private key stays on your device. The share service retains a key identifier, public key, Apple's verification receipt and counter linked to the sharing installation; registrations expire after 90 days without use. Create-response recovery receipts expire after 24 hours, and challenges after five minutes. This is an app-integrity check, not an Apple account identity, and it gives no extra sharing quota. It does not run when the service has no App Attest policy.

Services you can switch on

Each of the following is off until you enable or configure it. Turning one on is the moment data starts flowing to that service, and turning it off stops the flow.

Crash reports

Off by default. If you turn on Send crash & error reports (on the Mac, in Settings → About → Diagnostics) or Send crash reports (on the iPhone, in Settings), crash and error reports are sent to Crashbox, a small self-hosted crash collector run by Baton's developer. No third-party crash-reporting service receives them. Baton uses the Sentry client library to package a report, but the hosted Sentry service is not a destination and the app refuses to start reporting if it is pointed anywhere but Crashbox. Reports describe what the app was doing when it failed. Before anything is sent, Baton strips server addresses, URLs, IP addresses, file paths, and authentication parameters from every report, and tells the reporting library not to attach your IP address or any user identifier. Your music, track titles, server address, and credentials are never included. Builds compiled from the public source have reporting disabled entirely. Turning it on means Baton will try to send a report after a crash, but it does not confirm that the report arrived.

Missing lyrics

Off by default. If you turn on Look up missing lyrics (on the Mac, in Settings → About → Lyrics), Baton asks LRCLIB, a free public lyrics database, for words your own server does not have. The request carries the track title, artist, album, and length, and nothing else. Lyrics already embedded in your files are used without any request being made.

Scrobbling

If you connect ListenBrainz or Last.fm, Baton sends each finished track's artist, title, album, and the time you played it to that service, under the account you connected. That is what scrobbling is. If you choose Handled by my music server, your music server sends them instead of Baton. Disconnect the service in Settings to stop.

Discovering music outside your library

Look outside my library is off by default (on the Mac, it is in Settings → Playback). With it on, asking "what sounds like this" queries MusicBrainz and ListenBrainz, and, if you added keys, Last.fm and YouTube. Each source also has its own switch. A query necessarily tells those services which artist or track you asked about. Nothing is sent while the main switch is off.

Chat, voice, and agent control

The music friend works once you turn on Understand plain English and choose a model provider. It then sends your conversation to that provider. Every request includes what is playing (title, artist and album) and its place in the queue, along with the results of the library tools the friend uses. With Let it look around first on, it also sends a summary of your taste, what it remembers about you and its recent picks. The provider may be a machine on your network or a hosted API with your key. On the iPhone these requests can go through your own Baton server. Summarizing a transcript or screen text sends that text to the configured model; a non-local summary endpoint requires separate consent. If you configure Telegram or Discord control, commands and replies pass through that platform under its terms. Local MCP connections can also pass tool results to the agent you chose.

For microphone input, Baton uses Apple's speech recognizer and requires on-device recognition when the recognizer supports it. Otherwise recognition requires a network connection and may send speech to Apple's recognition service. The recognized text can then become part of the conversation sent to your configured model.

Book text and cloud models

When you turn a document into a book, models on your Mac, on your Baton server and Apple Intelligence never need asking, because the text stays on your own machines. A cloud model receives book text only for what you allow on the Mac in Settings → Agents → Book text and cloud models: short excerpts from the opening to suggest a narrator, names a voice might stumble on, or the chapters you have already heard, for a recap. Anything that looks like a password or key is taken out first. Forget My Answers turns all of it off again.

Transcription and speech

Transcribing a track or episode uploads its audio to the transcription host you configured. Spoken summaries and document narration send their text and voice selection to the configured speech host. These hosts can be on your network or elsewhere. Their operators determine what they retain; choosing a host does not make its processing local or establish a deletion period.

Content you point Baton at

Some things you play do not live on your server, and playing them means fetching them from whoever publishes them:

  • Podcasts. Subscribing to a feed fetches it, and episodes download or stream from the publisher's host. The publisher sees the request, as it would from any podcast app.
  • Internet radio. Tuning a station streams from the station's own URL, and Baton may fetch the station's logo from its homepage. The station sees the connection, as it would from any player.

In both cases your device connects directly to the third party; Baton adds no identity of yours beyond the connection itself.

The iPhone app

  • Demo mode makes no network requests. The built-in demo library is bundled with the app, plays entirely offline, and sends nothing anywhere, including scrobbles.
  • The camera is used only to read the pairing code shown on your Mac's screen, so you can connect without typing. Nothing is recorded or stored.
  • Purchases are handled by Apple. Baton receives no payment details and keeps no record of who bought it.

Data use and service boundaries

  • No Baton account is required to use your music library.
  • Baton includes no advertising or advertising analytics SDK and does not request an advertising identifier.
  • The sharing service retains the content, pseudonymous activity and diagnostics described above. Optional features send information to the recipients you configure.
  • The source contains no integration that joins sharing records with other companies' data for targeted advertising or a data broker.
The design principle: if a feature would send data somewhere new, it ships off, it says where the data goes, and the switch is yours.

Changes and contact

If a future version changes what Baton sends or stores, this page will change with it, with the date above updated. Baton is open source, so the code itself is the authority; the crash-report scrubbing, the discovery switch, and the demo mode's offline guarantee are all inspectable in the public repository.

Questions about privacy are welcome as issues on GitHub.