Monday 15 October 2018

Blindspot support for Spotify is prematurely coming to an end

What is Blindspot?

Several years ago, in the heady days of *checks* July 2013, I posted the first commit to a project which would go on to be A giant part of my out-of-work development life.

Taken from the Blindspot homepage:

Blindspot is an accessible Windowless Windows desktop app, focusing on providing access to the Spotify service to blind or partially-sighted screen reader users.

Basically imagine a small tasktray icon that allows you, with the use of shortcut keys only, to flick through your Spotify playlists, artists’ albums, etc, and choosing your next track to play, all without losing context from the screen you’re looking at. For a sighted person it MAY be useful (I have never found out). For a screen reader user, this is really useful, speaking from personal experience. Being able to change what music you’re jamming to whilst still keeping your place in whatever you’re working on or playing… definitely an undervalued comodity.

Sounds cool, why are you not supporting it anymore?

In a strange way, I’d like it to just be a lack of willing on my part to support this, because I know willingness can come and go and this thing can be fixed. That, and it’s open source, so even if I was unwilling, someone else may be willing to take on this project (more on that in a later post).

The problem, however, comes from upstream. Yes, Spotify, that’s you.

I was trying to track down some elusive trouble I’d been having with some playlists not showing up in Blindspot, really strange stuff, no obvious cause, no debug information, nothing to cling on to. They were just showing up with blank IDs and empty names, at nest, I seem to recall a rather vague message being output in the logging, but I can’t seem to find the history of it to confirm this.

My browser history pretty much does show me trawling through all examples in the Libspotify developer documentation and then onto some open source examples, such as the ones written for the Jamcast plugin, the original authors of the Libspotify.NET project.

I then stumbled across this issue in the mopidy project, which confirmed to my horror, that the Libspotify API is indeed depricated with no suitable replacement. Depricated doesn’t mean turned off though, they’re sort of refusing to maintain it. In essence, letting it kill itself through neglect. People seem to make less of a fuss that way I find so companies are preferring this to big stories about shutting down APIs, see the Verge’s story about the Twitter API changes when they completely changed third party access earlier this year. So Spotify aren’t exactly pulling the plug on third party access, they’re more sort of noticing that sparks are coming out of the wiring and refusing to call in the engineer, and offering double A batteries as a replacement.

Don’t get me wrong, there is a web API that handles the replacement. Fine if what you want to do is look at your playlists. Which, I’m sure someone out there somewhere would find invaluable, but if you’re trying to use it to play music, you are S.O.L.

Further reading:

How do you handle something like this?

In all honesty, not very well. I created an issue on the GitHub repo to track the progress on this, also tying it to the original mopidy issue that alerted me to the danger. I then launched into a fair amount of ranging research, including looking at rewriting the app in Electron and somehow seeing if I could use the JavaScript playback APIs to see if I could work around this, but it didn’t seem promising. But really, aside from rewriting the whole client for Linux only using Rust using some rather unofficial workarounds, I can’t really see how this situation is currently salveageable.

At the time back in April, there were moderate issues with the API, but nothing that meant the application was useless. Some playlists weren’t showing up inexplicably, which meant I couldn’t fix them, even though some of the playlists that weren’t showing up were my own, annoyingly. I opted not to really go too loud about this being the case with the application, as I was still using it, and I was under the impression that others were too. And I figured that if anyone was having a real issue with it, they’d go to the GitHub issues page and may see that the top issue was something that I’d marked as really really serious (I used the flag possibly fatal, which may be a slight bit of hyperbole).

However, recently, I’ve received a few e-mails and a Facebook message (from one of the people who helped me with the idea no less) asking about trouble they’re having with the application. And I now have to accept that the application that was happily limping along in spite of speradic neglect from its owner and acute neglect from its upstream dependency has now toppled over, waving its legs in the air uselessly.

I can’t see these problems getting better by themselves, and I’m not sure Spotify is likely to back down on this position. The Libspotify API is indeed an old solution, replacing it with web based equivalents is the right technical way to go. But omitting crucial functionality with only a vague promise of other services to replace it that are way overdue is not good enough to build an application on.

If you feel sufficiently strong enough about this to want to put fingers to keyboard and register your irritation at this less-than-friendly approach from Spotify towards a project that really only saught to work around their own shoddy accessibility, please feel free to direct it at @SpotifyCares. This all rather throws that name into sharp relief as an oxy-moron, Spotify Cares. Like business ethics. Perhaps that’s a little petulant of me, but I’m sure you can cut me some slack for irritation suffered.

So, is it dead?

Well, not entirely. I’m kicking around ideas for ways to revive the project. My first consideration is perhaps opening up the application to other providers, if they offer a more friendly solution for developers to build third party applications. Unlike Twitter, Spotify has considerable competition in its space that is worth investigating. Unfortunately, its competition aren’t known for their open ecosystems. Apple, Amazon, etc.

I’ve also considered splitting off the buffers UI code and the code that registers it as a windowless application into 1 or 2 separate projects for re-use as NuGet packages, probably even through .NET Standard. I’m not sure if I’d be able to work in the screen reader support, but I may be able to just have it able to pass on a delegate for upstream systems to handle. I gather this is something that may be of interest.

In conclusion

I can’t see a future for Blindspot and Spotify as of right now. I will of course keep an eye on their new APIs and see if they offer up anything that could be possibly useful as a replacement for Libspotify. Were that to happen, I’d be happy to attempt a rewrite. Its worth mentioning that when it was all working as it was supposed to, this was an app I was using myself on a daily basis for my own enjoyment. As far as an insentive to do software development goes, this is a strong one.

I intend to write a follow up post, detailing the story of this project, how it started, how it grew and what the whole saga (sorry Candy Crush, its a legit word and I’m taking it back) taught me. I think it may be quite cathartic for me and also may teach others in short some of the lessons I learnt the easy way, and the not so easy way.

For now though, in case the other post is a long time in coming, I would like to thank the various people who helped make Blindspot what it was in its inception, in supporting me and providing valuable feedback. And most particularly to the users who took the time to get in touch. It made it all the more worthwhile. And thank you for your patience in waiting for an official response from me. I just wish I could do more.

No comments:

Post a Comment

As always, feel free to leave a comment.