What tunecat actually is — and why ‘simple and dumb’ is a design philosophy, not an insult

Tunecat calls itself “simple and dumb internet radio thingy” — and that self-description is the entire point. It is not a failure of ambition. It is a position statement against the sprawling complexity that defines most modern streaming infrastructure, where even a modest setup can pull in containerized microservices, proprietary licensing dashboards, and cloud egress fees nobody budgeted for.

The project is written in Go (99.2% of the codebase), with a thin shell layer (0.8%) handling audio pre-processing through a bundled script called opusify. That script does one job: transcode your music library to Opus at 128 kbps before tunecat ever touches it. The runtime itself connects to an IRC server, joins channels, streams audio, and listens for commands. That is the full scope of the software.

The directory structure makes the project’s philosophy legible at a glance. There are two source directories — cmd/tunecat and internal — alongside a go.mod file, a LICENSE, a .gitignore, the opusify script, and a README. No build system sprawl. No plugin architecture. A solo developer can clone the repository, read the entire codebase in a sitting, and have a working instance running the same afternoon.

Tunecat authenticates to IRC using CertFP — a TLS client certificate method — and the documentation explicitly suggests generating a self-signed ed25519 certificate with a single openssl command and pairing it with a NickServ account. The demo instance the author runs serves a Classical Music Mix released under Creative Commons Public Domain Mark 1.0, streaming into a channel on what the README describes as “a very chaotic IRC network.”

The command-line flags — -addr, -dir, -irc-addr, -irc-cert, -irc-channels — are the entire configuration surface. There is no YAML, no web UI, no database. Small community stations running on a VPS or a spare machine at home can deploy this without learning a new ecosystem. The simplicity is not a limitation waiting to be engineered away. It is the feature.

IRC as a control interface: nostalgia or genuine practicality?

The question answers itself the moment you look at where small radio communities actually spend their time. They are already in IRC channels, already chatting, already coordinating. Bolting a control interface onto that existing space costs nothing in terms of user behavior change — no new app to download, no account to create on yet another platform, no permission to grant. The control surface appears inside the conversation that was already happening.

Tunecat, an open-source internet radio tool written almost entirely in Go, makes this concrete. Its demo instance streams a Classical Music Mix — released under CC Public Domain Mark 1.0 — directly into the #chat channel of an IRC network. Listeners and the broadcast mechanism occupy the same channel simultaneously. Someone requests a track or triggers a command in the same place they discuss the music. The gap between audience and operator collapses to zero.

The technical footprint reinforces this. IRC is a text protocol from 1988. Clients for it run on hardware that predates broadband. A Raspberry Pi, a decade-old laptop running a minimal Linux install, a phone on a 2G connection in a rural area — all of these can connect to an IRC server and interact with a bot like Tunecat without strain. Compare that to a web-based control dashboard that demands a modern browser, JavaScript execution, and a stable low-latency connection just to render the interface.

Tunecat itself pre-transcodes audio files to Opus at 128 kbps using a provided shell script called opusify, keeping the server-side processing minimal and predictable. Authentication uses CertFP through NickServ and TLS client certificates generated with OpenSSL — standard, auditable, and compatible with every serious IRC network. The configuration is a flat list of command-line flags: listen address, file directory, IRC server address, certificate path, channel list. Anyone who can read a README can operate it.

That simplicity is the argument. IRC-based control is not nostalgia dressed up as innovation. It is a deliberate choice to use infrastructure that already works, already scales to low-resource environments, and already exists inside the communities these stations serve.

Security without complexity: certificate-based authentication via NickServ and CertFP

Tunecat sidesteps password-based authentication entirely. Instead, it directs operators to generate a self-signed TLS client certificate using OpenSSL’s ed25519 key type, then register that certificate’s fingerprint with NickServ via CertFP. The exact command the project recommends is:

openssl req -x509 -new -newkey ed25519 -sha256 -nodes -out tunecat.pem -keyout tunecat.pem

That single command produces a combined certificate and private key file, which tunecat accepts directly through its -irc-cert flag.

Ed25519 is an elliptic-curve signature algorithm built on Curve25519. It produces 64-byte signatures, resists side-channel attacks, and is faster to verify than RSA at equivalent security levels. Choosing it here isn’t cosmetic — it’s a deliberate decision to use a modern cryptographic primitive rather than defaulting to RSA-2048 or ECDSA-P256.

CertFP is the mechanism that ties everything together. When tunecat connects to the IRC server over TLS, it presents the client certificate. The server computes the certificate’s fingerprint and checks it against the fingerprints registered to a NickServ account. If they match, NickServ automatically identifies the bot as the account owner — no password transmitted, no password stored in a config file, no password to leak.

The architectural payoff is significant. Tunecat itself never handles credentials at runtime. Authentication responsibility sits entirely with the IRC network’s existing identity infrastructure. The tool stays stateless with respect to auth, which shrinks the attack surface and eliminates an entire category of misconfiguration risk. There’s no secrets management problem to solve, no encrypted credential store to maintain, and no rotation workflow to document.

For a small community radio station running a bot on a VPS or a home server, this matters. The operator generates one certificate, registers one fingerprint, and the security model is done. Compromising the running process doesn’t expose a reusable password. Rotating credentials means generating a new certificate and updating the NickServ registration — a clean, auditable action.

Tunecat brands itself as “simple and dumb,” but the authentication design is neither.

The content layer: open licensing and the case for public domain music

Tunecat’s demo instance streams a Classical Music Mix released under the CC Public Domain Mark 1.0. That licensing choice eliminates every friction point that kills small radio projects: no royalty calculations, no takedown notices, no licensing agreements with collecting societies, no legal exposure for anyone who clones the repo and replicates the setup. The math is simple — public domain content costs nothing to stream and nothing to defend.

That choice is not incidental. Tunecat is built for communities that want to operate completely outside commercial rights regimes. Most internet radio projects eventually collide with DMCA takedowns or the labyrinthine fee structures of ASCAP, BMI, and SoundExchange. Tunecat sidesteps that entire system by making public domain the default, not an afterthought. A station running on this stack can go live without a single conversation with a rights holder.

The audio pipeline reinforces the same philosophy at the technical level. The repository includes a shell script called opusify, which pre-transcodes source audio files to Opus at 128 kbps before tunecat ever touches them. Opus is an open, royalty-free codec — no patent licenses, no per-stream fees. It was designed specifically for low-latency internet audio and outperforms MP3 at equivalent bitrates. By requiring operators to convert their library before streaming, tunecat keeps the runtime simple and predictable: the server reads a directory of .opus files and streams them. No on-the-fly transcoding, no codec negotiation overhead.

The combination of public domain content and an open codec stack means a community radio station built on tunecat has zero recurring rights costs and zero proprietary dependencies in its audio chain. That is a meaningful baseline. Commercial streaming infrastructure typically bundles licensing costs, codec fees, and platform lock-in into a single opaque bill. Tunecat separates those layers and makes each one free.

What mainstream coverage misses: this is about community infrastructure sovereignty

Tech journalism about internet radio starts and ends with Spotify’s 600 million users, Apple Music’s algorithmic curation, and whatever AI playlist generator launched last week. tunecat operates in a completely different tradition — one that predates the streaming wars and will likely outlast them. This is community-owned, self-hosted micro-broadcasting: a single Go binary, a directory of Opus-encoded audio files, and an IRC channel. No venture capital. No terms-of-service changes at 2am. No dashboard.

The project’s README contains one quietly significant detail: the demo instance serves a Classical Music Mix for #chat on “a very chaotic IRC network.” That phrasing is not embarrassed self-deprecation. It’s an accurate description of how real human communities actually operate — noisy, unpolished, and completely uninterested in enterprise-grade tidiness. tunecat is designed for that environment, not despite it. Corporate deployment tools optimize for control and uniformity. tunecat optimizes for actually working inside the beautiful mess of a community that’s been running on IRC for years.

That design philosophy has concrete stakes right now. Centralized platforms routinely kill the features communities depend on. Twitter gutted its API and charged $100 a month for what was previously free. Discord has changed bot permissions multiple times, breaking integrations built by volunteer developers. Last.fm gutted its scrobbling infrastructure. Each of these events left communities scrambling to rebuild something they never owned in the first place.

tunecat’s approach closes that trap entirely. You run the IRC bot. You run the audio stream. You pre-transcode your own music library with the included opusify script. The TLS certificate is self-generated with a single openssl command. Nothing in that stack requires permission from a third party to keep functioning. When a platform pivots, raises prices, or simply disappears, a tunecat-based radio station keeps broadcasting because the operator owns every layer from authentication to audio delivery.

That’s not a niche technical preference. It’s digital resilience — the capacity for a community to maintain its own infrastructure regardless of what the commercial internet decides to do next.