The contest page on the official website isn’t quite as verbose as one would have hoped, though, and the link to the rules points to a missing webpage. Some more intel is however available in a blog post on Michael Robertson’s blog. Yes, Michael MP3.Com/Linspire Robertson, who is also Michael MP3Tunes Robertson, obviously.

The deal: you have until November 5th, 2007, to submit an interface to MP3Tunes in one of the ten predefined categories (Desktop Player, Game Console, WebUI, PDA, etc). The winner in each category will receive a cosy $1000. I haven’t determined whether it’s a public vote, a closed jury, or some other semi-random algorithm involving car-driving girafes.

I haven’t yet checked what the API offers, either, but I sure wonder whether we could hack something together with XMMS2. If it could be hooked into the daemon, and apart from the obvious ever satisfying benefit of being neat and fun, it might allow using any of our interfaces (AKA clients) to play music from MP3Tunes.

From what I see, MP3Tunes isn’t much more than an online storage for music files, that you either upload or retrieve from wherever on the web. (Let’s leave the obvious legal issues to Michael’s lawyers, shall we?) This means that you have a whole medialib on their server, apparently indexed and searchable and, naturally, playable. If I’m not mistaken, the “streaming” seems to be nothing more than retrieving the music file (original or transcoded to mp3) over HTTP, which XMMS2 already supports.

In the current scheme, our medialib assumes to contain all the media and their metadata, so unless this is extended to support distributed media libraries (hello, Summer of Code 2008?), it means we would have to sync the remote MP3Tunes medialib to the local XMMS2 medialib. Sounds a bit tedious and expensive and ugly, so suggestions are welcome with better solutions!

These are the few implementation considerations I can think of off the top of my head, but overall it doesn’t sound so complicated, unless we want the support to be very smart (async, allow upload/download media, etc).

Of course, the whole contest looks like a call for devs to code cool interfaces to a money-making online service (mostly) for free, more than anything else, but let’s just consider the idea for a minute and whether it could justify spending some energy on writing one or several polished clients (which I think most of us agree we need).

And transparently sharing music through a (currently) free, password protected, remote service can’t be such a useless idea, can it?