Music subsystem: confirming the architecture before I resubmit

[chrispmonkey]

Following your review of #5 — you were right that it was too big and badly abstracted. I'm closing it and redoing the work as small, single-purpose PRs. Before I build, I want to confirm the shape so I'm not guessing.

From your comments, the target sounds like:

1. A Tidal-shaped mock API built into humane-system-hook — the redirect + a local endpoint the Pin's own Tidal client talks to.
2. An async provider-integration seam in the server, so provider code stays out of api.rs, rig_backend.rs, and services/aibus/*.
3. Each music source as its own provider APK (likely its own repo), plugged in behind that seam.

Two things I want to get right:

• Mopidy scope: I took your point that Mopidy should be a shared interface rather than one provider stacked on hand-built ones, so I looked at what it can actually cover. It unifies Spotify, Tidal (EbbLabs/mopidy-tidal, HiFi FLAC), YouTube Music (natumbri/mopidy-youtube via ytmusicapi — the older mopidy-ytmusic is archived), SoundCloud, Bandcamp, etc. as server-streamed backends. Two gaps matter here: there's no Apple Music backend and there can't be one (no raw stream; MusicKit/FairPlay is device-native only), and Mopidy's server-side GStreamer audio bypasses the device-native playback we use for Apple and Tidal. The native music UI is preserved either way (everything is served through the shim), but because Mopidy audio is a constant server-side stream rather than a real track, in-track seeking doesn't work and pause/resume can drift — whereas the device-native paths keep full transport. So I'm leaning toward: Apple stays device-native (MusicKit); the long-tail / server-streamed sources go through Mopidy; and Tidal is offered both ways — device-native via the shim (the pure Ai Pin experience) and via Mopidy for server-streamed FLAC — since the Pin supports Tidal natively already. Does that split match your intent, or did you picture it differently?
• Provider boundary: should providers live behind a Rust trait in-process for now, or do you want the APK/IPC boundary from the start?

If that matches what you had in mind, I'll open the first PR as just the Tidal mock (no providers), then layer the seam and one provider per PR from there. Happy to adjust the split.

[agg23]

I mentioned Mopidy as a way to build support once for a number of music platforms. As you say, it seems like that is less simple because of the architecture, so it's probably not worth pursuing.

The userbase is so small that I would recommend building only one music provider implementation. Apple Music requires a key, and Tidal is not very popular at all. I don't use any streaming services, but I imagine Spotify and YouTube Music are by far the most popular, especially since both of them can be "freely" accessed.

---

As for design, ideally it would be:

1. A hook to replicate the Humane + Tidal API
2. A routing/config layer in the server
3. Some plugin architecture for the individual music providers

I'm not sure the best way to do the plugin architecture. Technically the server can run outside of Android, so we probably shouldn't use Binder (and that would be difficult anyway). Possibly design a dylib loading structure with fixed API (idk what crates work best for this).