1) It's legality would be equivalent to any other torrent client. 2) It'd let you enjoy your vast personal library of music in the way people seem to enjoy it (radio-like "just hit play" experience), but without the limitations imposed by most existing carriers (stops playing after an hour of inactivity, doesn't work offline, can't play songs by the same artist more than a certain number of times per hour, can't play specific songs on demand, etc).
Basically, layer 2 is a "headless" torrent client with a very formalized interface, whereas layer 1 is a fancy MP3 player that happens to spit out a file that layer 1 knows how to read. The two layers are largely decoupled, and could be independently developed. -david Daniel S. Menasche wrote: > Hi David, > > Yes, the idea of a Freedora is very interesting! > > Some questions, > > 1) how to deal with the legal issues you referred to? > > 2) what would be the advantage of the service you proposed over the > radios already available, for instance, through iTunes? > > Best regards, Daniel > > > On Tue, 2010-01-05 at 15:00 -0800, David Barrett wrote: >> Ahh, cool, I didn't realize you could select specific songs in Spotify. >> >> Regardless, I think the idea of having a P2P radio service that >> dynamically assembles a playlist based on what's locally available is a >> sound one. >> >> -david >> >> John Bäckstrand wrote: >>> Spotify does not only play "randomly", though. This confused me a bit >>> when reading the introduction here. I only play specific songs in >>> spotify, or albums, or artists.Yes, some say thats a meaningless way to >>> use a streaming service, but its not: I get to use it from any PC, I get >>> to be legal, and I get (mostly anyway...) correct metadata. >>> >>> On Thu, Dec 3, 2009 at 09:50, David Barrett <dbarr...@quinthar.com >>> <mailto:dbarr...@quinthar.com>> wrote: >>> >>> The uptake of Pandora and Spotify show that listeners really like a >>> "just hit play" experience: start with some songs you like, hit play, >>> and Good Stuff comes out the speakers. Sometimes music you know, >>> sometimes music you don't. Sometimes it plays the same track multiple >>> times in an hour, other times you hear a track once and never again. >>> It's like a radio with infinite stations. You get the picture. >>> >>> Now, the primary reason they made their service this way was for cost >>> savings: the license to do that is way cheaper (though still cripplingly >>> expensive). It wasn't a technical reason that drove their design, it >>> was a financial reason. >>> >>> However, recognizing that the result is acceptable and popular with >>> users, why not exploit this fact to address P2P's #1 shortcoming: >>> download start times? >>> >>> P2P can and should be faster and more reliable than HTTP streams. >>> However, its complexity causes it to "start" downloading slower (because >>> connection setup often involves finding peers, doing NAT penetration, >>> onionskin routing, etc). Furthermore, even though P2P can sustain very >>> high throughputs, because it's coming from multiple sources the actual >>> stream is "jittery". This means if you want to do true streaming, you >>> need large buffers -- again, delaying startup time. For these reasons, >>> P2P has typically ceded the entire "on demand" streaming experience to >>> webservers, instead focusing on downloading (where out-of-order delivery >>> can be employed to maximize throughput and swarm health). >>> >>> But by using a Pandora/Spotify-like "dynamic playlist" experience, the >>> application would alleviate the requirement for instantly playing any >>> specific song and just instead focus on instantly playing whatever's >>> available -- while going out and getting more in the background. >>> >>> I see (at least) two layers: >>> >>> 1) Player layer. All it does is look at the songs on your hard drive >>> and decide: >>> - What song should I play next? >>> - What songs would I like to play, but don't have? >>> It could do this by calling central services, or by checking a DHT, or >>> whatever. Its recommendation engine would likely be populated >>> explicitly by users clicking "thumbs up/down" on given songs, and >>> implicitly by recording which songs uses skip versus allow to pay to >>> completion. >>> >>> 2) Transport layer. All it does is look at the "what would I like to >>> play?" file output by layer 1, go download it, and dump it onto the hard >>> drive in a place layer 1 can find it. >>> >>> Layer 1 is completely legal. All it does is assemble a dynamic playlist >>> of the songs you own, on your hard drive. It works perfectly well with >>> MP3s ripped from your CDs, purchased from Amazon or iTunes, etc. >>> >>> Layer 2 is less clearly legal. It just automatically downloads whatever >>> is suggested by Layer 1 as "boy, I wish I could play these songs..." >>> There'd need to be some way to convert song titles into magnet links, >>> which could then be pulled off the standard uTorrent/Azereus DHTs. >>> >>> The result is a totally free equivalent to Pandora or Spotify. >>> >>> Why doesn't someone build this? >>> >>> -david >>> >>> >>> _______________________________________________ >>> p2p-hackers mailing list >>> p2p-hackers@lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> >>> http://lists.zooko.com/mailman/listinfo/p2p-hackers >>> >>> >>> >>> >>> -- >>> John Bäckstrand >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> p2p-hackers mailing list >>> p2p-hackers@lists.zooko.com >>> http://lists.zooko.com/mailman/listinfo/p2p-hackers >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@lists.zooko.com >> http://lists.zooko.com/mailman/listinfo/p2p-hackers > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
