crimsonvariableFF00VAR · FF00Δ

Projekt / Linux-Konfiguration

aktiv

Crimson Playback TUI

Ein terminalorientierter, barrierearmer Playback-Controller mit einem einzigen verbindlichen Browser-Gerät statt einer Übersetzung zwischen konkurrierenden Warteschlangen.

  • Rust
  • Ratatui
  • Spotify Web API
  • Web Playback SDK
  • OAuth PKCE
  • NixOS
  • Eww

Aktuelle Richtung

Crimson Playback TUI folgt auf ein nützliches, aber zunehmend fragiles Experiment: ncspot läuft in einem von Eww verwalteten Terminal-Panel und seine Auswahl wird an eine dauerhafte Browser-Playback-Engine weitergereicht.

Der Prototyp zeigte das eigentliche Problem. ncspot und der Browser verwalteten je eine eigene Warteschlange und einen eigenen Wiedergabekontext. MPRIS meldete den aktuellen Titel, aber nicht genügend Informationen über die auslösende Ansicht, um „Gefällt mir“, Playlists, Alben und Queue-Aktionen zuverlässig zu erhalten.

Das neue Design macht die unterstützten Spotify-Schnittstellen zur einzigen verbindlichen Playback-Quelle. Die Terminalanwendung rendert Bibliothek und Status direkt; ein verwalteter Browser stellt das DRM-fähige Web-Playback-Gerät bereit.

Terminal-UI → lokaler Daemon → dokumentierte Web API
                      └──────→ verwaltete Browser-Engine

Eine Anwendung

Autorisierung, Callback, Token-Erneuerung, Browserstart, Geräteregistrierung und TUI werden als eine Anwendung ausgeliefert.

Der normale Einstieg bleibt bewusst einfach:

crimson-playback

Beim ersten Start öffnet die Anwendung die Autorisierung im normalen Browser, empfängt automatisch den lokalen PKCE-Callback, startet die interne Engine, wartet auf eine frische Gerätekennung und zeigt danach die Terminaloberfläche. Der Browser bleibt technisch ein eigener Prozess, muss aber nicht mehr manuell verwaltet werden.

Die TUI darf geschlossen werden, während der Daemon die Wiedergabe weiterführt. Beim erneuten Öffnen verbindet sie sich mit derselben Sitzung, statt einen zweiten Player zu erzeugen.

Warum terminalorientiert

Das Projekt soll nicht jede Ansicht eines offiziellen Clients nachbauen. Sein eigenständiger Wert ist ein kompakter Tastatur-Workflow für einen stark angepassten Niri-Desktop:

  • vorhersehbare Navigation in festen Terminalabmessungen;
  • sichtbarer und prüfbarer Zustand statt versteckter Browserautomation;
  • lokales IPC für Eww und spätere Quickshell-Oberflächen;
  • ein zugängliches Befehlsmodell ohne zeigerlastige Bedienung;
  • eine gemeinsame Wahrheit mit Telefon und Spotify Connect.

Gerät zuerst

Das wichtigste Ergebnis der bestehenden Bridge ist der Gerätelebenszyklus. Das Web Playback SDK liefert beim Bereitschaftsereignis eine neue temporäre Gerätekennung. Der neue Daemon speichert sie nur als Laufzeitzustand, verwirft sie bei not_ready sofort und wählt niemals still ein anderes Gerät im Haushalt.

Das aktive Ziel bleibt in der Terminaloberfläche sichtbar. Ein Browserneustart erfordert eine neue Registrierung; ein TUI-Neustart nicht.

Öffentliche API-Grenze

Die Umsetzung verwendet dokumentierte Web-API- und Web-Playback-SDK-Funktionen. DOM-Scraping, private Endpunkte, undokumentierte Collection-Kontexte, Audio-Downloads und künstliche Nutzung bleiben ausgeschlossen.

Diese Grenze ist bei „Gefällt mir“ besonders wichtig. Kann die öffentliche API die Kontextbezeichnung eines offiziellen Clients nicht darstellen, zeigt die Oberfläche diese Einschränkung, statt ein Album zu erraten oder eine falsche Synchronisation zu behaupten.

Aktueller Stand

Vorhanden sind eine detaillierte Architektur, ein Gerätevertrag, ein Sicherheitsmodell, klare Richtliniengrenzen, eine Teststrategie und ein stufenweiser Umsetzungsplan. Produktionscode existiert noch nicht.

Die erste Implementierung bleibt bewusst klein: Autorisierung, ein registriertes Browsergerät, eine sichtbare Now-Playing-Ansicht, eine Albumansicht und exakte Wiedergabe im Albumkontext. Queue und Bibliotheksbreite folgen erst, wenn Telefon, TUI und Browser in diesem minimalen Zustand übereinstimmen.

Verbundene Projekte