oauthclientbridge VS libspotify-archive

The way auth tokens are setup for Mopidy-Spotify *you* hold the encryption key for the blob with the OAuth data, and the intermediate server just has an id and the encrypted data. Note that the id is not a Spotify OAuth client-id but an internal one. This is done so we don't have to ship Mopidy-Spotify with the client-secret for the App registration (this was pre PKCE auth).

I.e. I would be highly surprised if our OAuth integration was the source for this issue, but I'm obviously biased as the author of https://github.com/adamcik/oauthclientbridge

As for libspotify, there you had to put in a (device) password and username, so if something scraped that config I guess all bets are off...

The integration of Spotify, the great daddy of audio streamers with third-party apps has been difficult over the years. Years ago, in their beginning they liberated libspotify, coded in for integration with different clients. Integration with major audio players like Foobar, Clementine and MusicBee were working, but in 2015 the company decided to drop the new development on the library and decided to shut down the integration last June. The new feature called Spotify Connect that allows multiple device to act as remote controller for the device that its playing in real time made new possibilities. But the wheel was inventend with LibReSpot, a library written in Rust. More libraries ported from the original in Rust appeared later in Go and Java. This last one is special, since it allows to be controlled by HTTP requests and interacts with a potential client through WebSockets. So a good player is possible to be built through a GUI library, and so I picked the most user friendly GUI framework, PySimpleGUI, that wraps multiple and more complex GUI frameworks like Tkinter and PyQT providing easyness of development.

Others have been suggesting Libspotify still works for legacy embedded device reasons... https://github.com/mopidy/libspotify-archive seems to have Android and iOS builds.