Nixie is local-first. It has no Nixie account, backend, telemetry, analytics, crash uploader, advertising SDK, or media cache.
The app stores playback restoration, preferences, bounded loudness measurements, recent searches, window bounds, and the YouTube parser cache on this computer. Website cookies remain in a dedicated Electron session. Lyrics are fetched when requested and are not persisted.
Signing in adopts the YouTube cookies from a browser profile you pick. On macOS and Linux, for Firefox on every platform, and on Windows for a Chromium browser whose cookie store still uses the older DPAPI scheme, Nixie reads that profile's cookie store off disk. On macOS this can ask your Keychain for the browser key, and recent macOS versions refuse the read until you grant Nixie Full Disk Access, which lets it read files other apps keep and which Nixie asks for on screen when macOS refuses. On Linux it can ask the Secret Service. On Windows it asks DPAPI, which answers only for your own user account. A Windows Chromium profile that has moved to app-bound encryption (Chrome 127 and later today) protects its cookies so that only the browser can read them, so there Nixie Link reads its own YouTube cookies through the browser extension API. Nixie authenticates each request with a private pairing code and a fresh nonce. The extension encrypts each accepted cookie payload with AES-256-GCM before local native messaging carries it.
Google expires that session every few minutes and only the browser holds the current value, so Nixie asks for it again while it runs, at most once a minute, for as long as the account stays linked. It takes the YouTube cookies and nothing else. Direct Firefox import uses the regular profile session, not cookies from container tabs or third-party partitions. It records the disk profile or connected extension in its own directory. An extension pairing value is protected through the operating system facility exposed by Electron safeStorage; pairing is refused on Linux when only the insecure basic_text backend is available. Browser sign-out, extension removal, a pairing reset, or an authenticated empty cookie set clears the copied extension session on the next refresh. Signing out in Nixie clears it immediately. Those cookies are sent to YouTube, which is what makes the session work, and nowhere else.
A play is reported to YouTube Music's watch history over the same signed-in session, once when it starts and once with the position it reached, so what you listen to here shapes the recommendations the app then shows you. Nothing about the play is kept locally, and turning off watch history in Settings stops the report. Apart from the update check described below, it is the only thing Nixie sends anywhere that was not asked for by a page you opened.
Settings reads and writes a handful of settings that belong to the linked account rather than to this computer: whether liked music from YouTube appears in your playlists, whether queues and radios update dynamically, and whether watch and search history are paused. Those are the account's own settings, so a change made here applies to every app signed in to it, exactly as it would if it were made in YouTube Music. They are read on request and never stored locally. Every other setting on that page, including theme, audio quality, normalization, content region, and restricted mode, stays on this computer and is sent nowhere.
Nixie asks GitHub for the latest release when it starts, every six hours while it runs, and whenever you press the button in Settings. That request carries no YouTube cookie and identifies neither the account nor the computer. GitHub receives it like another download request, sees the address it came from, and applies its own policy. A packaged app downloads an available update automatically and asks before restarting. If you defer the restart, the update installs when you later quit. A development build never checks or downloads.
Diagnostics stay on this computer until you choose to copy or export a report, or open an issue. Local logs record operation names, times, fixed error categories, HTTP status codes, and session-check results. They do not record account names, cookies, tokens, URLs, filesystem paths, raw error messages, parser objects, lyric text, or media data. The current log and one previous log are limited to approximately 1 MB each. Reports include the latest 100 events, the app and runtime versions, operating system version, architecture, build type, app language, and connection method and browser name. Older log formats are not included.
The error report can be reviewed before sharing, including before sign-in. Opening an issue copies the full report to the clipboard and opens a GitHub draft with app and system information. You must paste the report and submit the issue yourself. GitHub receives the information in the draft URL when your browser opens it; a submitted public issue can be read by anyone. No error report is sent automatically.
YouTube Music, LRCLIB, and NetEase Cloud Music receive the requests needed to provide their services and apply their own policies. A lyrics lookup asks them in order and stops as soon as one answers, so the later sources are reached only when the earlier ones came back empty. LRCLIB and NetEase are sent a title, an artist, and a length, with no cookie and nothing that identifies the account. YouTube Music is asked over the same signed-in session that streams the audio, so that request is tied to the linked account like every other request to it. Clearing all local data removes Nixie state, measurements, and the website session.
Nixie is an independent, unofficial client. It is not affiliated with, endorsed by, or sponsored by YouTube, Google, Spotify, LRCLIB, or NetEase Cloud Music. YouTube and YouTube Music are trademarks of Google LLC, named here only to state which service Nixie connects to.