Interest in discussing extension points for Musicat?

[kelchm]

Hi -- I've been following Musicat for a while, and I wanted to reach out because this project really hits a very specific nerve for me in the best way.

Local-first music libraries and hardware players are something I used to obsess over years ago, and Musicat is the first media player project in a long time that has genuinely felt exciting to me again -- both in terms of the stack and the overall design.

I’ve got a lot of ideas in this space, but I also want to be careful not to show up like I’m trying to impose a whole roadmap on a project that’s clearly very personal and thoughtfully built. A couple of the areas I keep coming back to are device sync for hardware players and richer integration points for things like Last.fm / scrobbling.

Part of why I'm reaching out is that I've also been experimenting on the device side a bit -- including some early work with mtp-rs and a very rough Zune sync-related tech demo, so this isn't just abstract interest on my end.

What I'm really trying to understand is whether you'd have any interest in collaborating on a more plugin-oriented / extensible architecture for Musicat, and, if so, where you'd want to start.

Either way, I'd be happy to start small and work within the direction you already have in mind.

[basharovV]

Hi! First of all, thanks for the nice words, I'm really glad this project clicked with you!

Secondly - I immediately got excited that you're interested in hardware-sync! I don't use an MTP device (although I do have an old Android phone lying around), but I occasionally copy my Musicat library onto my 5.5g iPod running Rockbox, so a sync feature would be really neat, and it's something that I had in the back of my mind as well.

Let's definitely start small, because user-made "extensions" (a la Foobar components) will be hard to achieve properly given the architecture and nature of the app, pre-1.0 development and all. It's an interesting space though (and I briefly looked at how to run external libraries at runtime with abi_stable, so it's definitely possible).

In the meantime, if we focus on an abstract architecture for device-sync that allows for implementing various device protocols, that's already a good start. For example - having a DeviceManager struct:

pub struct DeviceManager {
    pub devices: Vec<Box<dyn SyncableDevice>>,
}
impl DeviceManager {
    pub fn scan_all(&self) -> Vec<Box<dyn SyncableDevice>> {
        // 1. Scan for MTP Devices
        // 2. Scan for Mass Storage (Rockbox / iPod)
        // 3. Add to devices
    }
}

that holds generic SyncableDevice traits (which could be an MTP device, an iPod, etc, each with their own specific implementation). If you would like to have a go at the MTP side, I'd be willing to try the iPod sync.

[kelchm]

Thanks for the thoughtful response! The SyncableDevice trait approach makes a lot of sense -- I'm happy to take the MTP side of things. I've already got some early work with mtp-rs and have been poking at Zune-specific protocol details, so that's a natural fit.

Before jumping straight to the device trait though, I want to flag something I kept running into as I thought about what an implementation actually needs. It's not specific to MTP -- it's a more general thing that I think is worth getting right early.

Right now, track identity in musicat is source-specific. A local scan produces id: MD5(filepath). A Beets import produces id: "beets-{db_id}". The same song, from two different sources, has no shared identity -- which is why the Beets integration has to be a hard switch rather than coexisting with the local library. There's no deduplication layer.

Device sync hits the same wall from a different angle. A device isn't a source of tracks -- it's a sync target. You push tracks to it from the library, and (ideally) pull play data back. But to do either, you need to answer "which library track does this device track correspond to?" -- and the device doesn't share your file paths or database IDs. You're matching on metadata.

The common thread across both problems is a source-independent track identity -- something I've been thinking of as a CanonicalTrack. The idea is that this becomes the primary entity in musicat's data model, with three distinct relationships hanging off it:

                CanonicalTrack
                ┌──────────────────────────┐
                │ id: Uuid                 │
                │ artist / title / album   │
                │ mb_recording_id          │
                │                          │
                │ is_favourite, tags, ...  │  ← user data lives here
                └─────────────┬────────────┘
                              │
            ┌─────────────────┼─────────────────┐
            │                 │                 │
    Track Sources         Sync Targets      Play Events
(where it exists)    (where it's copied)  (where it's played)
            │                 │                 │
 ┌──────────┴──┐     ┌────────┴───────┐    ┌────┴──────────┐
 │ Local       │     │ Zune           │    │ local playback│
 │ path: ...   │     │ handle: 0x003F │    │ device: Zune  │
 │ Beets       │     │ Rockbox iPod   │    │ Last.fm       │
 │ beets_id: 42│     │ path: /Music/..│    │ ListenBrainz  │
 └─────────────┘     └────────────────┘    └───────────────┘

Track sources are where a track is discovered -- your local filesystem, a Beets database, maybe eventually a streaming source like Subsonic. Multiple sources can point to the same canonical track; that's how Beets and local coexist instead of being mutually exclusive.

Sync targets are devices you push tracks to -- this is where the SyncableDevice trait lives. When you sync a track to a Zune, MTP assigns it an object handle (e.g. 0x003F). You store that mapping -- canonical_id → device handle, so you don't need to re-match metadata. After that, the link is established, and both directions (sync out, read play data back) work through the stored handle.

Play events record when and where a track was played -- local playback, device readback, a scrobbling service. play_count becomes a derived value rather than a bare integer, which is what would eventually make bidirectional Last.fm/ListenBrainz sync possible.

Concretely, I'd see the work playing out as:

1. CanonicalTrack + matching/normalization logic -- small, self-contained, immediately testable. The first consumer is device sync, but it retroactively gives the Beets integration a path toward coexisting with the local library rather than replacing it.
2. SyncableDevice trait + Zune implementation -- built on top of canonical matching. Push tracks, sync playlists, detect what's already on the device via stored canonical-to-device-handle mappings.
3. Play data readback -- both Rockbox (.scrobbler.log) and Zune (play counts via MTP) track what you've listened to. Once canonical identity exists, pulling that data back and attributing it to the right track becomes straightforward.

Thoughts on the CanonicalTrack concept -- do you think that's something worth exploring further prior to device sync, or does it feel premature? I'm happy to start there or jump straight to the MTP implementation and let the abstraction emerge from the concrete work if you think that makes more sense.

[basharovV]

Hi again! Finally got round to replying to this, hope it's still more or less fresh in your mind!

I have been thinking about this abstraction and it makes perfect sense to me. When I first started this project I didn't have all these features in mind, but now the plug-and-play architecture is much needed and is an opportunity to get back at the fundamentals. I welcome all contributions, but this one is the biggest one so far and definitely needs discussion.

Question: Did I understand correctly that CanonicalTrack would be the persisted db model, but the 3 relationships would only be resolved on-demand at runtime? (eg. Track Sources would be resolved when playing track, opening track info). Or did you intend for everything to be part of the database model?

Finally, this brings me to one critical dependency that I think should be tackled first - the database itself, which as you may know, lives in IndexedDB and handled by the WebView. Although it's quite performant, it should really be a simple SQLite database handled on the Rust side. Especially considering that browsers may "evict data" (source) to free up system resources.

Let me know what you think!