It's however a lot of work, with spotty documentation and questionable support. That's why for the first release I haven't really bothered with it too much and instead focused on the core functionality of streaming audio and video, and controlling the NymphCast server from the client.
(I'm the NymphCast author)
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?
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.
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.
I have intentionally made this the same as things work with ChromeCast.
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?
As they say, you already got the 'no', so why not try to get the 'yes' or 'maybe'? :)
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.
The real problem, quickly dismissed in this article, is support integrated into 1st party apps. Chromecast lets you use a streaming platform app 100% normally and then 2 clicks later it's playing on your big screen/speakers. You could implement some sort of bridge app (that you'd "share" the content to) but then you are switching between the streaming app for content discovery, and the bridge app for control. That's not the chromecast experience. The only way we can get that experience is with 1st class support built into the streaming app. Spotify/Google/soundcloud/Amazon have no reason at all to work on adding support for something new until it becomes popular, but that's obviously a chicken and egg situation. Chromecast support is already built in everywhere, but of course that's a non-starter since Google have locked everything down sufficiently to prevent implementation of a receiver. I don't know the answer to this.