Fastpotify: un cliente de Spotify en Rust y sin navegador dentro
Hay una línea en el repositorio Debian de Spotify que cuenta toda la historia mejor de lo que voy a contarla yo. Es el campo Depends del paquete spotify-client, y dice esto:
libc6, libasound2, libatk-bridge2.0-0, libatomic1, libgbm1,
libglib2.0-0, libgtk-3-0, libnss3, libxshmfence1, libxss1,
libxtst6, xdg-utils, libayatana-appindicator3-1
Mira libgbm1. Mira libnss3. Mira libxshmfence1. Esas no son las dependencias de un reproductor de música: son las dependencias de Chromium. Gestión de búferes de GPU para compositar, la pila criptográfica de Mozilla que usa el navegador de Google, primitivas de sincronización de memoria compartida entre procesos de render. Lo que instalas cuando instalas Spotify en Debian no es un reproductor. Es un navegador que, entre otras cosas, reproduce música.
El paquete de la rama stable, versión 1.2.95.453, pesa hoy 171.638.972 bytes. Ciento sesenta y tres mebibytes comprimidos para escuchar canciones.
Un navegador que además reproduce música
No voy a darte una cifra de RAM inventada, porque las que circulan son de hace años y de máquinas que no son la mía. Te propongo algo mejor: abre el cliente oficial y mira el árbol de procesos con pstree. Vas a encontrar lo que encuentras siempre con una aplicación CEF: un proceso principal y una pequeña corte de procesos hijos —GPU, red, renderizadores— repartiéndose el trabajo de dibujar unas listas de texto y unas carátulas cuadradas.
Entiendo la decisión de negocio: Spotify tiene una web que funciona, y empaquetarla con Chromium dentro le da la misma interfaz en tres sistemas operativos por el precio de mantener una. Ya escribí sobre esa aritmética en Pake frente a Electron y sigo pensando lo mismo: es racional para quien la toma y un impuesto que pagamos los demás. Pero llevo veinticinco años viendo cómo el software se come el hardware que compramos para ir más rápido, y hay algo que no se me pasa: el ordenador donde escucho música es el mismo donde compilo y tengo cuatro terminales abiertas. Cada proceso de Chromium que no reproduce nada es un proceso que no pedí.
Por eso el 27 de agosto me llamó la atención un repositorio que llevaba dos días existiendo.
Qué es Fastpotify
Fastpotify es, en palabras de su propio repositorio, «Spotify, native and fast. One lightweight Rust app for your whole library, local playback, and Spotify Connect on Linux, macOS, and Windows». Un cliente nativo de Spotify escrito en Rust, con licencia MIT, publicado en github.com/crmne/fastpotify.
Los datos, tal cual estaban cuando escribí esto: 525 estrellas, 29 forks, 196 commits, once issues abiertos. Repositorio creado el 27 de agosto de 2026. La versión etiquetada es la v0.3.0, publicada el 29. Es decir: cuando lo miré, el proyecto tenía tres días de vida. Guárdate ese dato, porque vuelvo a él más abajo y es la mitad del post.
El .tar.gz de Linux para x86_64 pesa 11.660.875 bytes. Once mebibytes. Frente a los 163 del .deb oficial, eso es quince veces menos descarga, y no porque hayan recortado funciones: dentro hay biblioteca completa, búsqueda, colas, edición de playlists, ecualizador de diez bandas, bandeja del sistema y MPRIS. Hay quince veces menos porque no hay un navegador ahí dentro.
La web oficial promete que «starts in well under a second» y que «uses little memory while it runs». Lo primero es fácil de creer: es un binario nativo que abre una ventana. Lo segundo, sensato pero sin cifras publicadas, que es exactamente como prefiero que me lo cuenten.
Por dentro: egui y librespot
Las dos piezas que explican el proyecto entero son estas.
La interfaz es egui, una biblioteca de GUI en Rust de modo inmediato. La diferencia con lo que estamos acostumbrados es más grande de lo que parece. En una interfaz web hay un DOM: un árbol de nodos que persiste, con estilos en cascada, que recalcula su distribución cada vez que algo cambia. En modo inmediato no hay árbol que mantener: cada fotograma, tu código vuelve a declarar qué hay en pantalla y se dibuja con la GPU. No hay reflow porque no hay layout persistente. No hay motor de CSS porque no hay CSS. No hay JavaScript porque no hay JavaScript. Es la técnica que usan los depuradores y los editores de videojuegos, y es rápida por la razón menos glamurosa del mundo: porque hace muchísimo menos trabajo.
La reproducción es librespot, la implementación libre del protocolo de Spotify Connect. Es el mismo motor que hay debajo de spotifyd, de Raspotify y de media docena de proyectos que llevan años convirtiendo Raspberry Pis en altavoces. No es una API documentada ni bendecida por Spotify: es un protocolo que la comunidad entendió por su cuenta y mantiene desde entonces.
El resultado de juntar ambas es que Fastpotify se anuncia en tu red como un dispositivo Spotify Connect más. Reproduce en local sin huecos hasta 320 kbps, con normalización de volumen opcional y caché de audio en disco, y a la vez puede mandar la reproducción al altavoz del salón o recogerla del móvil y seguir donde ibas. Descubre dispositivos por mDNS. Te da las playlists, las Liked Songs, los álbumes guardados, los artistas seguidos, los podcasts y los episodios pendientes. Colorea la interfaz según la carátula que suena. Y trae, por si alguien echaba de menos 1998, un mini-reproductor estilo Winamp que admite skins .wsz.
Las dos puertas de entrada
Esta es la parte que conviene entender antes de instalar nada, porque es donde está el requisito duro.
Fastpotify te pide dos inicios de sesión distintos, porque Spotify concede dos permisos distintos.
El primero es para leer tu biblioteca, y usa Authorization Code con PKCE: se abre tu navegador en la página de consentimiento de Spotify, autorizas allí y vuelves. El README es explícito —«Fastpotify never sees your password»— y así debe ser: la aplicación recibe un token, nunca tus credenciales. El refresh token acaba en ~/.local/state/fastpotify, con permisos de solo el propietario.
El segundo es para reproducir en este ordenador, se activa desde el menú de dispositivos («Play here, set up once») y aquí llega el requisito que descarta a mucha gente: hace falta Spotify Premium. No es capricho del proyecto, es política de la plataforma: solo las cuentas de pago pueden reproducir a través de una aplicación de terceros. Con una cuenta gratuita, Fastpotify te deja navegar tu biblioteca entera y no te deja darle al play. Conviene saberlo antes de bajar nada.
Sobre la pregunta que todos nos hacemos —¿me pueden cerrar la cuenta?—, el proyecto responde con una prudencia que agradezco: «We are not aware of a Spotify account being suspended for using Fastpotify or another librespot player with Premium». Y explica por qué: el login ocurre en las páginas de Spotify, el audio es la calidad que ya incluye tu Premium, el DRM se respeta, no se rippean pistas y no se bloquean anuncios; los casos de suspensión conocidos son de aplicaciones modificadas que hacen justo eso. Es un argumento razonable. También es, literalmente, «no nos consta», que no es lo mismo que «Spotify lo aprueba». Sin dramatismo: es un cliente no oficial y hay que instalarlo sabiéndolo.
Instalarlo, y el peaje de ser de Debian
Si usas Arch, esto es un renglón, porque ya está en el AUR:
yay -S fastpotify-bin # binario precompilado
yay -S fastpotify # compilado desde fuente
yay -S fastpotify-git # último commit
En macOS hay cask de Homebrew (brew install --cask crmne/tap/fastpotify) y un DMG universal, y en Windows instaladores para x86_64 y aarch64. Y en Debian, que es donde vivo yo desde siempre, el destino de costumbre: no hay .deb. Queda el .tar.gz genérico —descomprimir, dejar el binario en el PATH y listo, las dependencias son «ordinary desktop libraries»: ALSA, PulseAudio o PipeWire, y Wayland o X11—, un Flatpak anunciado a partir de la v0.4.0, o compilar. Para compilar hacen falta Rust 1.95 o superior y las cabeceras de sonido y ventanas:
sudo apt install libasound2-dev libpulse-dev libxkbcommon-dev libwayland-dev
cargo install --path .
La configuración vive en un único JSON en ~/.config/fastpotify/settings.json, escrito de forma atómica —detalle que me hace una gracia especial, porque es exactamente la misma decisión que tomé en este blog para no depender de una base de datos—. Dentro está lo previsible y bien elegido: device_name (el nombre con el que apareces en Connect), bitrate (96, 160 o 320; por defecto 320), normalisation (desactivada), gapless (activado), audio_cache_mb (1024), theme y, en Linux, audio_backend para elegir entre PulseAudio y rodio. Las cachés de audio, carátulas, letras y playlists están separadas bajo ~/.cache/fastpotify/, y borrarlas no te desloguea. Nada de esto es espectacular; simplemente está donde tiene que estar, en texto plano, en tu disco.
Lo que no hace
Me gusta un proyecto que enumera sus límites en la portada, así que los recojo tal cual: máximo 320 kbps, porque los flujos sin pérdida van con un DRM que librespot no soporta; no hay podcasts en vídeo; no hay funciones sociales; y las playlists se reordenan por menú, no arrastrando. Ni rippea pistas, ni manipula flujos, ni quita anuncios a las cuentas gratuitas. Es, en sus propias palabras, un cliente no oficial construido sobre la Web API pública de Spotify y sobre librespot.
Ninguna de esas ausencias me duele. La única discutible es el tope de 320 kbps, y aun así: para escuchar mientras trabajo, con los altavoces de un escritorio y el ruido de fondo de Mijas Costa en verano, es una conversación teórica.
Lo que me hace dudar
Ahora la parte honesta, que es la que hace que este post valga algo.
Es un proyecto de tres semanas. Cuando lo miré tenía tres días y 196 commits, lo que dice muchísimo del ritmo de su autor y absolutamente nada sobre cómo se comporta a los seis meses. Una v0.3.0 no es una promesa de estabilidad, es una declaración de intenciones. No lo he tenido corriendo un mes; esto es lectura del repositorio, de la documentación y de las notas de versión, más la comprobación de las cifras que doy. Lo que pase con tu biblioteca de 400 playlists un martes cualquiera, no lo sé.
Depende de librespot, y librespot depende de que Spotify siga sin cerrar la puerta. El protocolo de Connect no está documentado ni soportado para terceros. La comunidad lo mantiene desde hace años y ha sobrevivido a cambios, pero el equilibrio no es contractual: es inacción. El día que a Spotify le convenga apretar no habrá nada que reclamar, porque nunca hubo nada prometido: el interruptor lo tiene otro.
Y sigue siendo un cliente de una plataforma cerrada. Este es el punto que me importa más, y va aparte.
Un cliente excelente para música que no es tuya
Escribí hace poco sobre ser inquilino de tus propias herramientas, y aquí aparece la misma criatura con otro disfraz. Fastpotify hace maravillosamente bien una cosa: mejorar el acceso a un catálogo que no posees. Puedes cambiar de cliente cuantas veces quieras, pero eso no cambia quién decide qué hay en el catálogo, qué se retira mañana, cuánto cuesta el mes que viene ni bajo qué condiciones te lo sirven. El cliente es tuyo; la música, no.
Es exactamente la asimetría que describí en el capital en la nube: la infraestructura es de otro, tú aportas la atención y el pago recurrente, y lo que te queda al final del año no es un activo sino un historial de escucha. Cuando hablé de salidas no propuse quemar las suscripciones, que sería una tontería; propuse saber en cuál de los dos lados de la línea está cada cosa que uso. Fastpotify está del lado del alquiler, con un mueble mucho más bonito.
Lo cual, ojo, tiene su valor. Que el mueble sea libre, MIT y auditable es exactamente el tipo de mejora que sí depende de nosotros. Y hay un detalle nada menor: al ser un dispositivo Connect, no te ata. Si mañana lo desinstalas, tu cuenta sigue igual, tus playlists siguen ahí y vuelves al cliente oficial sin migrar nada.
Aun así, la lección que llevo tiempo repitiéndome es esta: lo que de verdad no te pueden revocar es el disco que tienes en la estantería, el concierto al que fuiste con tus amigos o el rato que dedicaste a entender por qué Carmina Burana suena como suena. El streaming es una comodidad extraordinaria y la uso a diario. Pero no es una colección. Es un grifo.
Quién firma esto
El autor es Carmine Paolino (crmne en GitHub, paolino.me), ingeniero de Ruby, Rails e IA afincado en Alemania. Es también el autor de RubyLLM, la biblioteca que unifica el acceso a los distintos proveedores de modelos desde Ruby, y de kamal-backup, y cofundador de Freshflow.
Que alguien conocido en el mundo Ruby —lenguaje dinámico, ecosistema web, cultura de la ergonomía— saque de la nada una aplicación de escritorio en Rust con GUI en modo inmediato y un motor de audio por debajo me parece el detalle más interesante de la historia. Habla de un desarrollador que no se define por su lenguaje sino por lo que quiere que exista. Y explica cosas del proyecto: Paolino también hace música, y ese mini-reproductor con skins de Winamp no lo pone alguien que solo quería resolver un problema de rendimiento.
Mañana publico precisamente el post sobre RubyLLM, su interfaz única para todos los modelos, que es harina de otro costal y merece su propio espacio.
¿Lo instalarías?
Sí, y creo que lo haré: el .tar.gz, en mi portátil, sin prisa y sin desinstalar nada. El coste de la prueba es un binario de once megas y el de la retirada es un rm.
Ahora bien, seamos claros con para quién es esto. Es para ti si tienes Premium, usas Linux, te molesta que un reproductor de música arrastre un navegador entero, y te apetece un cliente rápido, con teclado, bandeja, MPRIS y ecualizador. Encaja especialmente bien si vienes del mundo de spotifyd o Raspotify y llevas años echando de menos una interfaz decente encima de librespot.
No es para ti si tienes cuenta gratuita —no vas a poder reproducir—, si necesitas podcasts en vídeo o lo social, si dependes de audio sin pérdida, o si tu criterio para instalar software es que lleve dos años sin sorpresas. En ese último caso, dale seis meses y vuelve a mirar.
Y si lo que te ronda por dentro es la pregunta de fondo —qué pinta tiene ser dueño de tu música otra vez—, esa no la resuelve Fastpotify, ni pretende. Esa se resuelve comprando discos. Que es, curiosamente, la tecnología más moderna que conozco para no depender de nadie.