Motivation: I'm trying to move away from Spotify, tired of renting my own playlists back month after month. So I'm paying for music downloads online (MP3s and FLACs) and ripping CDs, and generally moving to an old-is-new-again post-Spotify music workflow.

As Linux is my primary desktop environment, I'm reacquainting myself with the Linux music playback ecosystem for the first time in a decade, more or less. While many of the projects I once relied on (hello, Amarok!) are still around, on the whole the field feels neglected. Even Spotify's crappy client does get some things right, and usability standards have generally risen since my last outing. But open source offerings haven't entirely kept up.

I'm also struck by the lack of common infrastructure between projects. While low-level libraries are shared (e.g. libogg, libpulseaudio), the core file discovery, indexing, tag editing, playback, and playlist management functionality that music players rely on are cobbled together afresh by each project. (As well as transcoding, another common feature.)

The duplication applies not only to desktop music players (Amarok, Rhythmbox, Clementine, cmus) but also to music servers such as Navidrome or mpd.

Proposal: define an abstract music playback and management interface, the Music Server Protocol, and implement it definitively in musicd, a comprehensive music server, integrating with existing or newly-built clients.

musicd could run incidentally (like a language server in the LSP world) or as a persistent daemon, and optionally expose a public network interface.

The latter point, network transparency, allows such a system to be a true Spotify replacement, serving music to mobile apps from VPS or other servers.

Multiuser support would be a useful feature, allowing friends and family to integrate their music collections; a lock-based rights management scheme could ensure that music licenses are treated as finite in the shared environment.

Implementation: I would implement musicd in Rust, interfacing with the same libraries as the existing apps. If there's a sufficiently-mature Rust codebase that already does what I need, I'd happily fork it. I'm insisting on Rust because I'm more familiar with it than with C++ these days, and because I'd prefer Rust's rigors in what I hope would become a building-block for many projects.