sendspin-cli's `sendspin serve` is the "Sendspin Party" mode: give it a file path or URL, it serves to clients on the LAN. Internally, sendspin-cli's serve mode uses ffmpeg to demux/decode arbitrary inputs. Also bundles a web UI for browsing shared files.
sendspin-go's current state
`cmd/sendspin-server` accepts local files (MP3, FLAC, WAV), HTTP URLs (direct MP3), and HLS streams (via ffmpeg). So partial parity already — we ALREADY shell out to ffmpeg for HLS via `internal/server.NewFFmpegSource`.
What's missing for full parity
- A web UI — bundled static assets, routes, file browser, "now playing" controls. Medium effort.
- The "party mode" UX — fast startup, auto-pick outputs, user-friendly error messages.
- Playlist/queue support (sendspin-cli loops a single file).
Product question
Do we want a web UI at all? It adds a static-asset-bundling story to the Go binary, which is non-trivial. Could punt to a separate `sendspin-serve` binary or skip the web UI entirely and say "this is daemon-focused, not a Party app."
Filing to track; needs a product decision before any code.
sendspin-cli's `sendspin serve` is the "Sendspin Party" mode: give it a file path or URL, it serves to clients on the LAN. Internally, sendspin-cli's serve mode uses ffmpeg to demux/decode arbitrary inputs. Also bundles a web UI for browsing shared files.
sendspin-go's current state
`cmd/sendspin-server` accepts local files (MP3, FLAC, WAV), HTTP URLs (direct MP3), and HLS streams (via ffmpeg). So partial parity already — we ALREADY shell out to ffmpeg for HLS via `internal/server.NewFFmpegSource`.
What's missing for full parity
Product question
Do we want a web UI at all? It adds a static-asset-bundling story to the Go binary, which is non-trivial. Could punt to a separate `sendspin-serve` binary or skip the web UI entirely and say "this is daemon-focused, not a Party app."
Filing to track; needs a product decision before any code.