Thank you, @brian. And a real thank you for putting the thread back up yourself. I didn’t expect that kind of openness, and it’s appreciated.
Your technical warning is the part I want to take seriously, because it’s also the part I’m least sure about. Talking to the Core correctly clearly involves obligations that aren’t visible from the outside — cleaning up what you open, ending subscriptions, closing the loop on callbacks — and those are easy to get quietly wrong when you’re working backwards from captured traffic. You’re right not to assume an AI pieced all of that together correctly. If there’s ever a hint you’d be willing to share about how a well-behaved client is supposed to clean up after itself, I’d document it carefully. Regardless, I’ll add a blunt warning to the repo: unsupported, liable to break on any update, and getting it wrong can burden the Core you’re running it against.
Related to that (since you’ve said you won’t stand in the way), I’m flipping the repository to public now so others can read it and check the work.
I do want to be straight about why any of this exists, though. The hours people sink into working around the edges of the official API aren’t really a gripe — they’re a sign of how much we like what you’ve built and how much we live inside it. Laurent’s list says it better than I can: playlists, queue control, real search. There’s clearly a group here that cares enough to take apart a binary protocol just to get a little closer to the product, and that seems like energy worth having on your side.
So I’m not asking you to throw the doors open; I get why the supported surface is small and deliberately so. I’m just wondering whether there’s room to grow it over time toward the things people keep bumping into. If there were ever an appetite for that, I’d bet a fair few folks on this forum would pitch in, carefully and however you’d want it done.
Either way — thanks for the generosity here. It genuinely made my week.