Spotify Web Player for Linux - Discontinued
9th April 2017
I personally hate to see any project go to waste, especially one that is also quite young. However, today it seems that I will be unable to continue development with Spotify Web Player for Linux. I'm not the type of person who wants or likes to give up on a project, however it doesn't also help the fact that the project is built upon a third-party. A third-party who also likes to prevent their consumers from using their own interface, hardly update interfaces for the Linux community or to implement bigger and better features. The same third-party who like to force interfaces to their consumers, most of whom dislike and are forced to either use a feature-less platform unwilling to this change or threaten to leave their premium subscription. Where either way, this third-party still seems to be unaffected by the important criticism of their business model. The latter very important to all businesses whom in this world would struggle to survive.
Presumably because many users are stuck to a model that is cheaper to continue with their dissatisfaction rather than buy music directly from the records company. A third-party who no-doubts pays less to contribute to any Artist!
Open Source is important for all of us. It helps create tools for all of us without limits that would most likely be unavailable due to greed that comes from many businesses. Tools of which many businesses would often fail or at least, come with many costs.
It's well known that Open Source software is developed by individuals or groups, typically in education or by organisations who strive towards community rather than oppression by using monetary greed that often creates more boundaries. I truly believe that support models using peoples expertise in enterprise are of more monetary gain and are more satisfying than pushing software with time limits that would otherwise, often impose possible security bugs.
This project was never determined to succeed or to last longer than it's own usefulness. However it makes me saddened when projects can no longer be maintained, especially when the projects are actively used or when the project improves upon another.
It's mostly due to the fact that the third-party has decided to remove to a more secure model by tying in their DRM and Spotify Connect protocols taking their software more towards a server-based implementation. Now I've only had approximately 2-3 hours of research when debugging to see if I could try and get the application to work again. Let me explain.
Most of the move in Spotify has been with using DRM content, more specifically Widevine and also the use in their Spotify Connect protocol. Beforehand, in the old player, the user would be able to control the player in their browser by using a socket that would use many iframes in different JS contexts (playback, playlist information, etc) connecting to a server that would authorise the requests and send responses for the client to go through, process the data, show it to the user and control playback. This would use the socket to control the state of the music by controlling the Adobe Flash instance remotely using bridges. They would then use an encrypted music file hosted on their server (rather than directly sending over bytes) that the player would play.
One thing that I found interesting is their use of their V1 API, which I last heard was going to be deprecated...
Personally I've never really been much of a fan with the future with the service and the only reason I used it is moreover to do with myself using the service ever since the service had the time limit on the accounts around 2009. Instead I should have just purchased all of my music I liked, perhaps then I wouldn't have relied on a service that doesn't listen to it's own users. One thing I have started to listen to is the radio when I'm busy or travelling which can sometimes be more useful. Other times I'll just have to rely on my decade old purchased music...
Perhaps future projects will be geared towards something directly Open Source to the Linux community rather than third-party alternative software.
- It was interesting to find that they use a C++ DRM Widevine encryption tool called edash-packager
- Looking in the requests you can see that they then buffer the music in buffer chunks using HTTP Status codes of 206
- It seems that DRM uses a kind of license to help demux a Widevine file as you can see a license file being loaded in the Network tab under DevTools
- React.js and Raven (Sentry) are used
- They expect touch users to be using the interface when most touch users will be using a tablet, most likely already with the ability to run their app natively
- All events seem to be tied using their React library
- A web socket is present but hardly used to communicate unlike before
- All information that would typically come from that socket (track information, album information)is now instead requested using the V1 API or Spotify Connect API (by XHR)
- Due to an automated stack variable, unable to use the Spotify Library, or link into the socket. (Making the XHR requests most likely unreachable - could use the API's manually but how would these work in tandem with the information we have)
- Information from these requests are therefor private, leaving little information present for use in a notification and MPRIS (only track & artist name, track progress available)
- Widevine is hard to load on Electron, requiring versions to stay persistent between Chrome and Electron versions
- No track ID prevents identification of songs using Sync API
- Cannot get album art sizes for notifications and caching due to lack of information
- No album title for notifications
- Finding own playlist and 'Add to playlist' is irritating to use