> In fact, I have considered doing so for Netflix and Spotify, among others

I must not understand because my argument is that the support absolutely must be built into the netflix and Spotify apps themselves, that seemless integration is what makes chromecast so usable. The media discovery and control needs to be in their app, not split between two different apps. So what can you do, other than provide a library for Spotify and Netflix to then ignore?

My apologies, I thought you were talking about the server-side.

On the client side having it integrated into the 1st-party client apps would be great, yes. Right now in the SoundCloud app I implemented a basic track/album/author search function that uses the server-side app to search through the SoundCloud database.

Though barebones right now, it provides essentially the same functionality as using the SoundCloud website directly. I can imagine this approach working in a generic fashion, assuming some network-accessible API is available that provides this information.

The problem is that you end up trying to reimplement the functionality of multipe 1st-party apps. Each of these different providers has their own API with its own issues. You'll never do as good as job as the 1st party client, and that's assuming they even give you API access (tidal don't provide a public API, Spotify's API is a subset of the functionality, others impose rate limiting etc). The only scalable solution I can see is to have service providers integrate your tech. But how to get them interested?

Don't get me wrong, I think this would be a great thing to have and I'd love to get involved. For audio playback there is Mopidy (I'm a maintainer) which provides something similar but it would be so much better if there was a open chromecast-like protocol we could hook into and integrate into 1st-party apps rather than requiring the use of our clients.

Maybe you misunderstood me. I have made available a client SDK that will allow anyone to create a NymphCast client with accompanying app on the server.

I have intentionally made this the same as things work with ChromeCast.

Apologies, maybe.

I understood it that I can't use the actual soundcloud app with all its functionality that I'm used to. The same app I use when I'm playing music on my phone. I have to use your client app as that's the one which includes support for nymphcast. That's your client app where you've re-implemented some subset of the functionality I want. Soundcloud could integrate the nymphcast client sdk into their app and then I'd have the same experience I get now with chromecast, but why would they do that?

The plan is to get NymphCast into a 'good enough' state, before sending an inquiry off to various services to see whether they're interested in getting their service on NymphCast.

As they say, you already got the 'no', so why not try to get the 'yes' or 'maybe'? :)

I admire your positivity and it's inspired me to take another look at where I left my (audio only) attempts. I sincerely hope you prove me wrong with getting streaming providers onboard.

For what my failed experience is worth, try getting some internal contacts at these companies. The public, and even "developer", contact channels for Spotify, Soundcloud, Tidal and TuneIn are a dead-end. At least, that has been my frustrating experience. Presumably if you throw them money they take you more seriously.

Yeah, there does have to be something in for them, even if it's just positive PR which they can cash in for more subscriptions or such.