[JDEV] Jabster Proposal

[Eliot Landrum]

Proposal for Jabster

Introduction
I would like to propose a completely open source replacement for the Napster
(http://www.napster.com) MP3 trading system using Jabber.

Background
I just recently got the Gnome Napster client (it is a clone) and was very
impressed with the amount of MP3's that were available. In case you are not
familiar with Napster, it is a client/server system that gives users access to
all of the other users MP3 files. The Windows clients also have fancy features
like a chat client (similar to IRC), and a watch list. The entire Napster
system is completely closed source and thus makes Linux implementations a bit
crude. I've heard a few people say that Napster is not that wonderful of a
system in the first place. Nevertheless, Napster helps MP3 users find songs
that they want quickly and easily with minimal fuss. That is something that I
really like. 

If there was a open source implementation of a Napster-like system, how should
it be done? Would the designer be required to start from the ground-up and
create a whole communication scheme? The idea occurred to me that Jabber could
be easily used to create a complete Napster-like system - only better. The
possibilities of this implementation are numerous! In fact, my brain was going
quite insane with all of the neat things that could be done with this. So here
is my proposal for a complete Jabber-based replacement for the proprietary and
closed-source Napster system.

Server
The only way I have been able to put this together is for there to be a main
server (with backup servers possible of course). I cannot see that the system
would gain much by having a distributed server system and unless done properly
would be slow. Please correct me if I am wrong. This is my idea of how it might
work: The normal Jabber server would pass off requests to the Jabster server
which would in turn process data or help clients negotiate transfers. Like
Napster, no MP3's would actually be stored on the server: just information
about their whereabouts. This information should be stored in an SQL database
and be properly separated into information like file name, file size, bit rate,
frequency, length, connection speed (of user), and ping response. If possible,
it would be good to include information from the ID3 tag about the artist and
song title. At any rate, here is a sample scenario:

- Client sends server request to search for all songs matching artist == "Dave
Matthews".
- Server gathers list of results, checks to see which of the hosts that have
the requested songs are online, pings them and sends list back to client.
- User selects the song and host that they would like, the client tells the
server what the selection is.
- The server tells the sender that it should get ready to send the file and it
tells the receiver that it should prepare to receive the file. Client
negotiation should begin. It would be good to be able to mask (for anonymity)
both ends of this connection, but that may not be possible.

A Napster transport might also be a good idea at first so that users can easily
move to the new system without losing any functionality.

The list of available MP3's should be periodically cleaned out in some manner
or another. The clients will refresh the list on every connect. 

Client
The client's main function is to present the user with a search and
download/uploading interface. Ithink that Napster's chat function is completely
unnecessary as there are plenty of other chat resources. I do like Napster's
"Hot List" function though. Anyway, the client provides a seamless interface to
the server for searching and transfer as well as announcing presence to the
server. When the client logs into the server with a user name / password, it
will upload a current list of the songs that are available to the system from
the user and tells the server that it is online and available to be downloaded
from. The list of available songs should probably be listed using XML tags for
each type of entry. Each MP3 can be scanned with an ID3 tool for all of the
relevant information. The client should be able to handle multiple transfers at
once. I can't really think of much else that the client would be responsible
for. 

---

There is a lot of room for advancement and improvement for this implementation.
I hope that you can see how exciting and useful this would be. Please give me
feedback and help me code this thing! This is an excellent way that we can use
Jabber beyond simple instant messaging and is a needed application. The most
exciting thing about it is that users need not even know that Jabber is running
the show! All they know is that it works and that it works good.

Comments please.

-- 
Eliot Landrum
eliot at landrum.cx