Back in April we reported on the release of Napster.fm by Ryan Lester, a service which used YouTube to serve up streaming music right in the users’ web browser. Ryan released his software under the GPLv3 on GitHub, and thanks in no small part to the notoriety of the Napster name, the service rapidly gained popularity.
In these last two months, Ryan’s project has gone through a few changes, not least of which a name change to Peer.fm at the request of current Napster owner Rhapsody. We were recently able to work our way into Ryan’s busy schedule to ask a few questions about the past, present, and future, of this interesting and somewhat controversial service.
Ryan Lester
The Powerbase: Ryan, thanks for taking the time to talk with us. To start off, can you tell our readers a little bit about yourself and your background?
Ryan: Sure Tom, and thanks for your interest in Peer.fm!
I’m a software engineer by trade, currently taking some time off from Carnegie Mellon to work at SpaceX. I can’t really talk about SpaceX without violating the International Traffic in Arms Regulations, but it’s pretty dope.
I started programming at 15, in the summer of 2007, when my friend Josh (current roommate/co-worker) convinced me to start learning Python with him – though by that time I had already become decently proficient in Bash, which in retrospect I’d more accurately consider to be my first language. From there, I started taking CS classes at school later that year and experimenting on personal projects.
The Powerbase: When did you first become interested in Linux and open source?
Ryan: I first picked up Linux as my daily driver back when I was 14, starting with Ubuntu Edgy. I’d already been using some open source software like Firefox, though, and had been at least vaguely interested in learning more about Linux/FOSS for a while.
Peer.fm
The Powerbase: You’ve recently gone live with Peer.fm (previously, Napster.fm), and it’s already generated quite a bit of buzz. What makes Peer.fm different from the options that are already out there? Why should people be excited about it?
Ryan:
- It has some cool social features that aren’t all present in its competitors: real-time syncing, real-time view of music played by all other users (“Discovery”), browsing of friends’ libraries (“Hot List”), sharing tracks (“Transfer”), IRC-like chat (“Chat”)
- Completely free (as in beer and freedom)
- Available everywhere on Earth (cf. Spotify’s geographic availability)
- Automatically translated into users’ native languages
The Powerbase: Rhapsody requested you change the name of the service, since they own the rights to the original Napster. How was the exchange between you and Rhapsody? Was this your first cease and desist notice?
Ryan: The dispute with Rhapsody isn’t fully resolved at the moment, so I can’t comment on that, but this wasn’t my first cease and desist; I received one from the Wikimedia Foundation last year as well after buying wikpeidia.org (note the misspelling) and hosting fictional articles about some friends at the domain as a joke.
Also, while I wasn’t technically the one to receive the cease and desist in this case, I did leak Chrono Trigger: Crimson Echoes a couple years ago.
The Powerbase: Do you regret originally naming the project after Napster? Or do you think it helped get Peer.fm the attention it need to get started?
Ryan: Definitely don’t regret it at all; I don’t think there’s any way it would have grabbed the same level of initial attention without the Napster association.
YouTube Backend
The Powerbase: Peer.fm gets its music from YouTube, which frees it up from the responsibility of hosting potentially illegal tracks. But on the other hand, being beholden to YouTube and its content could be a problem in the long run. Do you worry about a future where Google might actively fight the use of Peer.fm?
Ryan: I’ve actually fairly recently received an email from YouTube’s legal department requesting that I display the source video somewhere in my UI (with which I have complied). Other than that, I’m not worried about further interference.
The source YouTube video is now embedded in Peer.fm
What could be a potential problem, though, as you mentioned in your original article, is copyright-holders seeing the existence of Peer.fm as greater incentive to actively pursue the removal of infringing works from YouTube.
Open Source Protection
The Powerbase: Putting Peer.fm up on GitHub and licensing it as GPLv3 gives it built-in protection from anyone who might try and shut it down; it will never be possible to completely remove it from the Internet. Do you think this sort of protection through open source could have saved the original Napster?
Ryan: Possibly, though not to the same degree as I believe it could Peer.fm in the hypothetical event of a shutdown. While Napster did use P2P as a means of providing music to users, Napster’s infrastructure as described by Jordan Mendelson (Chief Architect of Napster) relied on some fairly complex server-side gymnastics and a pretty hefty centralized data store. If Napster were to have outlived its legal troubles through open source, it would have involved a third party putting in the work to replicate their backend deployment (ideally with a copy of their database, though starting from scratch would have been a viable option) and achieving a modicum of success under non-infringing branding while avoiding the same fate Napster met.
By the time Napster shut down in July of 2001, an armada of roughly interchangeable products had already launched (KaZaA, LimeWire, Morpheus, BearShare, etc.). I’m not sure of the degree to which its competitors of the time shared Napster’s social features, but even assuming they had nothing comparable, it’s not certain that those features would have been sufficient to give a reincarnated Napster the edge against KaZaA and LimeWire without its former momentum or brand appeal – and even if they were, its competitors could have chosen to take advantage of the open source code and negate that edge.
The devil is in the details, and Peer.fm has a number of significant factors in favor of its resilience against potential shutdown:
- Peer.fm itself is 100% client-side, which radically simplifies the process of standing up an identical clone; anyone can pull the code from GitHub and either run it locally or host it publicly with no extra effort (aside from changing the name/logo).
- Peer.fm’s data/content is entirely managed and stored by completely separate and perfectly legitimate services (Firebase, Discogs, YouTube). Because of this, even if Peer.fm were sued into oblivion or acquired and I were to end up in prison or working for a company that had no intention of letting the service continue to exist, any Peer.fm clone would suffer no loss of data or interoperability.
- Peer.fm’s music collection isn’t subject to the same sort of chicken-and-egg problem a reincarnated Napster (or any new P2P network) would face; whereas a P2P network depends on its users to provide its content, Peer.fm could provide the same music whether it had one user or one million users.
Just to clarify, though, this is all really a moot point as far as Peer.fm is concerned, since (unlike Napster) Peer.fm isn’t directly facilitating illegal activity.
The Powerbase: In a similar vein, Peer.fm’s open nature means you’ll never be able to truly rid the project of its original name; people can continue to distribute it as Napster.fm if they chose. Do you think this might become a problem? Do you believe Rhapsody understands the intricacies of the situation?
Ryan: Well, I could see it being a minor annoyance for Rhapsody, but I don’t consider it a problem for me at all. As far as whether Rhapsody fully understands the situation, I think so (I’ve seen no reason to believe otherwise); it shouldn’t be an issue for their legal department to send similar notices to the one I received when/if they become aware of infringing Peer.fm clones.
The Powerbase: GitHub currently shows Peer.fm having 27 forks. Have you been surprised by the reaction to the release of the source code so far?
Ryan: Well, I never expected Peer.fm to receive the initial attention that it did in the first place, so in that sense I certainly didn’t expect the reaction that the source code release received. As far as the reaction to the source code given the reaction to the product as a precondition, I haven’t been particularly surprised, though I do like that people have been taking advantage of the GitHub Issues system a little more than I’d expected.
The Powerbase: You mention on the Peer.fm site that you’re looking for contributors. Has Peer.fm’s recent popularity surge sent some developers your way yet?
Ryan: I received two pull requests with fixes for minor styling issues. Otherwise, nope.
The Future
The Powerbase: Do you think the days of storing music on our local devices is behind us? Do you see streaming as the future of digital music?
Ryan: No, I wouldn’t say so at all; at a minimum, as solid state storage capacities continue to increase (to the point at which local storage can be universally assumed to be cheaper than bandwidth), I think we should start to see aggressive local caching à la Spotify Offline Mode become the default.
Besides, even once Internet access begins to approach ubiquity on Earth, I’m not sure the Martian colonists will appreciate interplanetary latency in their Peer.fm playlists :).
The Powerbase: Any particular areas where you’d like to improve Peer.fm, or where outside help would be most appreciated?
Ryan:
- Real-time syncing between users is a little glitchy at times
- Notifications of new chat messages and scrolling to bottom of chat windows when new messages are received
- Occasionally, when loading Peer.fm, an unintended line break will appear between the play button and the track slider; a refresh usually makes this go away, but it’s mildly annoying that I haven’t found a workaround yet (it seems like a timing issue in the Google Closure slider class)
- Probably other minor issues
The Powerbase: What can we expect from Peer.fm in the near future? Any new features or improvements you have in mind?
Ryan: I’ve admittedly barely had time to touch the code since the end of April, but when I do pick back up where I left off, I plan to focus on the following:
- iTunes import
- Last.fm scrobbling
- Multiple playlists (as opposed to one library per account)
- Sharing of playlists (i.e. Hot List extended to support multiple playlists rather than just one library per user)
- Live streaming of U.S. phone calls through the PRISM REST API
- Mobile support
Thanks to Ryan Lester from taking time away from literal rocket science to speak with us. Good luck to Ryan and the whole team at SpaceX.
