PIRATE

Peer-to-peer Impromptu Reputation-based Automated Tune Exchange

an allicaMet Fan Club project

Design Document

Joannie Humphreys and Joshua Madden
CIS 650: Peer-to-Peer Networks
12 June 2001

Overview

In the recent past, two separate trends have become widespread: the increasing use and power of wearable computers (wearables), and the ad-hoc exchange of digital copies of music tracks (songs). The purpose of PIRATE is to provide a technology that will use wearables to facilitate the distribution of song descriptions, allow users to find the particular songs in which they are interested, and ensure that the owners of the copyrights for these songs are paid for them.

PIRATE achieves these ends by using wearables to form an ad-hoc peer-to-peer network, which typically functions without users' intervention. Users of PIRATE may specify songs, or genres of songs, in which they are interested (``wishlists''). Users may also provide a database of songs for which they have descriptions and other data (artist, title, liner notes, sample clips, etc.). When a wearable running PIRATE encounters another such wearable, the two copies of PIRATE exchange their wishlists. Each copy of PIRATE then checks to see whether any songs in its opposite number's wishlist match song descriptions in its own database; matches may be sent back to the originator of the query. The user may periodically check her wearable to see what new song descriptions have been found. If the user decides to purchase a song on the basis of its description, then PIRATE interprets the song description to find the song's location, and arranges for payment.

Use Cases

The use cases below comprise the ways in which the current version of PIRATE may be used. In these use cases, we will use the following terms:

• distributor: a PIRATE user who provides another with a song description, or is capable of doing so
• recipient: a PIRATE user who receives a song description from a distributor
• copyright holder: the owner of the legal rights to a song.

All PIRATE users are potentially both distributors and recipients.

1. A new user of PIRATE creates an account on the PIRATE central server.
2. Two PIRATE users encounter one another and their copies of PIRATE exchange interests via wishlists and genrelists; one (the distributor) provides the other (the recipient) with one or more encoded song descriptions that match interests.
3. A distributor finds a song description on the Web; this includes a link to an encoded version of this song description. The distributor clicks on this link, which opens a PIRATE plug-in that loads the encoded description into the distributor's PIRATE database.
4. A PIRATE user decides to buy a song for which she has a description in her database. She notifies her copy of PIRATE of her decision, and it makes a connection to the PIRATE central server. PIRATE arranges for the copyright holder (and optionally the distributors) to be paid from the user's account on the PIRATE central server, and transfers the song to the user.
5. A PIRATE user edits her wish list and genre list to update her advertised interests.
6. A PIRATE user deposits money into his account on the PIRATE central server.
7. A PIRATE user withdraws money from her account on the PIRATE central server.
8. A user logs into the PIRATE central server to check his account status.

System Design

PIRATE consists of two separate but related programs, since we do not assume that wearables are capable of connecting to the Internet. One program (the PIRATE peer) resides on the wearable, and consists of tools to edit the wishlist and song description databases, and the communications engine (which automatically negotiates with any copies of PIRATE that it encounters on the ad-hoc peer-to-peer network). The other program (the PIRATE client) resides on machines which are capable of connecting to the Internet, and consists of versions of the wearable's database editing tools and a client program which connects to the PIRATE central server when a user indicates that he is interested in purchasing a song for which he has a description in his database. (This program should eventually be capable of functioning as a plug-in to a web browser as in use case 3, above.) To increase portability and privacy, the wishlist and song description databases reside on the wearable; this allows the user to access their account from any public-access terminal that has a copy of the PIRATE client.

At the moment, we have implemented only the PIRATE peer, but have completed much of the conceptual design for the PIRATE client and central PIRATE server. This document will discuss the design of all three, but focuses on the peer.

User Interface

The PIRATE peer consists of a single window with three modes, which are selected by the buttons at the bottom of the window:

• Communication Log (default): This mode shows the messages that have been sent and received by this peer. It is primarily diagnostic and will not be a prominent feature of the finished product.
• Wish List: This mode allows the user to view the current contents of the wishlist, and add new items to it (using the ``Add Song to Wishlist'' button available in this mode) and allow the user to sort the wishlist in various ways and to remove items from it. Future versions will also allow the user to view and edit the list of genres.

  

• Song Information Database: This mode allows the user to view the song descriptions that they have available (both for songs that they own and for songs for which they only have descriptions), and to initiate the purchase of a selected song. The basic song data is listed in a table, while detailed information about the currently selected song is displayed below. The "View Reviews" button allows the user to enter the "Song Reviews" submode.

  

  • Song Reviews: This submode allows the user to view all reviews of the song currently selected when the "View Reviews" button is clicked. Each review has an author, a rating, and an optional written comment. The "Get Reviewer Profile" button causes the program to enter the "User Profile" submode.

    

  • User Profile: This submode allows the user to view all reviews made by the PIRATE user whose review was selected when the "Get Reviewer Profile" button was clicked. The profile will in future contain additional information on the indicated PIRATE user. The "View All Reviews For Song" button causes the program to enter the "Song Reviews" mode for the currently selected song.

    

Payment

The PIRATE payment scheme is straightforward: if a PIRATE user decides to buy a copy of a song, they are connected to the PIRATE central server, which sends payments as dictated by the policy for that copyright holder and song. There are a number of requirements which we wanted PIRATE's payment policies to satisfy:

• minimal required user attention: The user should not have to monitor PIRATE's collection of song descriptions. The only tasks that should require the user's attention are changing the wishlist, reviewing collected song descriptions, and purchasing songs from that collection.
• no payment required for songs not purchased: The user should not be required to pay for recommendations of songs that they don't purchase.
• guaranteed payment for songs purchased The copyright holder should always be paid for any songs that they own. (Recommenders may also be paid, depending on the policy set by the copyright holder.)
• secure payments: Payment information should always pass through secure network links.

These requirements helped to shape our design architecture. The ``minimal required attention'' and ``no payment required...'' requirements led us to the conclusion that copies of PIRATE should exchange song descriptions (recommendations) rather than the songs themselves. (The fact that exchanging songs would greatly increase the required bandwidth also influenced this decision.) The ``guaranteed payment...'' and ``secure payments'' requirements suggested that PIRATE should provide a central server that would be responsible both for providing links to the actual songs (so that users could not acquire the songs without passing through the server) and for mediating payments.

Within the restrictions imposed by these requirements, copyright holders may create individualized payment policies. The payment to the copyright holder is specified in the song description. All distributors in the chain between the original distributor and the purchaser of a song are reported to the central server, so the policy may state that some, none, or all of these distributors should be paid a specified amount (or even different amounts). The policy may also optionally state that the purchaser of the song (rather than the copyright holder) is responsible for covering the payments, if any, to the distributor(s).

We looked into letting users set their own fees for song distribution, but this creates two potential problems: one is that users might set higher prices for songs than the artists would prefer, and the other is that if users must be able to both read and write a given piece of a song description, our security is compromised (more detail is available in the section on security).

PIRATE users each must have an account on the PIRATE central server, into which they may deposit money, and which holds any money that they may have earned by distributing song descriptions). This money is the only money that a user may use to purchase songs (as a promotion, we would recommend that each new user be rewarded with $5 or so). There are a few reasons for this restriction:

• all payments among users can proceed locally on the PIRATE server and do not need to pass through any other network (increased security)
• all payments can be guaranteed--if a user does not have enough money to pay for a song, they can't buy it, so users cannot go into debt (increases trust, decreases financial risk to user of security breach)
• payments outside the system (to users or copyright holders) may be batch processed, thus decreasing the amount of external network traffic and administrative overhead

Security and Authentication

The integrity of the PIRATE payment system depends on being able to make guarantees about the authenticity of various pieces of information. In order to accomplish this goal, we plan to use RSA encryption (or some other one-way encoding) in two different ways.

We assume that all song descriptions are originally provided by trusted authorities, who presumably have some contractual relationship with the copyright holders of the songs. These authorities encode each song description with three classes of information: information which the user should be able to read at any time but must not be able to modify (artist, title, copyright holder ID, etc.); information which the user should be able to add to but must not be able to read (distributor list); and information which the user should be able to neither read nor write (song location).

Key	Encrypter	Decrypter	Purpose
User Signature	unique PIRATE Peer	PIRATE Server	verify user identity
Song Info Validation	Copyright Holder/Record Company	PIRATE Server & Pirate Peers	verifies that song info is as copyright holder intended and that payment info is correct
Event Record Key	PIRATE Peers	PIRATE Server	records transaction information in unmodifiable manner
Product Key	Copyright Holder	PIRATE Peerlet	keeps pickup location/instructions hidden until user pays for PIRATE Server to "unwrap" it

(Red keys need to be private, whereas blue keys can be publicly known.)

The first class of information is the user's signature, which is used to verify their identity.

The second class of information is encrypted by the trusted authority, using a ``public'' key that is in fact kept private, while the ``private'' key is encoded into PIRATE (and thus is available to anyone). This means that anyone can decode the information and read it, but no one except the trusted authority can encode this information so that the ``private'' key can decode it. This provides authentication for this information.

The third class of information (the distributor list) must be added to by each new distributor as they pass on a song description to a new recipient. If distributors could read this list, then they could add or remove other distributors from it (the server will remove cycles of distributors or redundant distributors from a list before authorizing payment, so there is no point in a distributor adding himself to the list multiple times). However, in fact each distributor only needs to append her ID to the end of the existing list, and then encrypt the result using a public key supplied by the PIRATE server. The server can then extract the list of distributors by decrypting the encrypted list and removing its ``tail'' until the list is completely unravelled.

The fourth class of information (the song location) is encrypted, via public key, by the trusted authority. (If this information were not encrypted, then anyone could get copies of the song from the repository without going through the PIRATE system and, therefore, without paying for them.) It is decrypted by the PIRATE server.

Data Structures

The primary data structures of note are the SongID, SongDatabase, and BST classes. SongID is a class which encapsulates the unique identifer (artist, album, and song title) for a song. Song is a subclass of SongID, and includes other song description data such as the song's liner notes, genre, year of publication, and so forth. BST is an implementation of a binary search tree, which arranges its objects according to the schema defined by an object of type java.util.Comparator; this Comparator may be changed out as necessary (if the user wishes to order the songs by artist rather than album, for example); this is an example of the ``Bridge'' design pattern. SongIDDatabase is a collection of objects of type SongID implemented as a BST object (using the ``Delegation'' and ``Facade'' design patterns). Another extension of SongID includes the SongProfile class, which comprises an individual user review of a song. SongIDDatabase is similarly extended into two analagous classes: SongDatabase and SongProfileDatabase, which permit searching based on additional points of interest that SongID does not store (such as genre information or numerical ratings).

Algorithms

Most of the algorithms used in this project to this point have been those related to the database implementation, e.g., binary search tree insert, search, delete, and traversal algorithms. These algorithms have been modified to operate on the basic wildcard (``*''), so that if ``*'' is passed in as a search specification for an album name, then the search will return matches with any album name. There are also algorithms that operate on a higher level of abstraction than the basic BST operations, which do things such as return all of the songs which match the search parameters (as opposed to simply returning the first match encountered). This is useful for returning responses to wishlists which use wildcards.

Communications Protocol

While PIRATE is currently a prototype which runs on networked workstations, the eventual intent is that PIRATE should run on wearables which are capable of short-range wireless communication. This key feature allows copies of PIRATE to communicate among themselves without requiring human intervention (which is required, for example, by the directed IR transmissions used by the most popular extant palmtop computers).

The PIRATE protocol is called HAT (``Honor Among Thieves''), and consists of the following messages:

• QUERY: sends a RequestPackage which encapsulates a SongDatabase (the wishlist) and a GenreDatabase (at this time, a new QUERY message is sent to another peer on every 50th encounter with that peer; this will be changed based on empirical testing)
• SONGLIST: returns a ResponsePackage containing matches to a local database search on the queries received in a RequestPackage. In a given SONGLIST response package, no duplicate songs wil be sent.

The simplicity of the protocol is optimized for encounters which may last only a few seconds (which may often be the case for wearables with a short transmission/reception range). At a later date, when we incorporate a model of reputation, we will expand the protocol slightly to allow for separate identity transmission and other messages relating to reputation (see the section on Future Work for more detail).

Future Work

Algorithms and Data Structures

While our current algorithms and data structures are adequate to our modest needs, in the future it may be desirable to implement algorithms for searching the PIRATE databases that are more efficient (many current operations require an amount of time proportional to the size of the database) and more sophisticated. In particular, we would like to incorporate the following enhancements:

• more sophisticated use of wildcards (partial substitution, e.g., ``Met*'', possibly regular expressions)
• check for close matches to allow for misspellings

Reputation

Reputation is a subtle and complicated subject in full generality. We are in the process of attempting to characterize a basic notion of reputation for PIRATE users in terms of the potential causes (what factors might influence reputation, and in what way?) and effects (how might reputation information inform the decisions of PIRATE or its users).

Current possible candidates for influences on reputation fall into two broad categories: quality of songs recommended, and status as an unauthorized/malicious user. The first category might have either positive or negative effects (users might be more or less inclined to buy songs recommended by a given user); the second category would probably simply shut down trading with a given user until further notice, upon evidence of malicious use.

Security

At the moment, we have no provision for verifying or authenticating the identity of other PIRATE users. We also have no way of directly verifying that another user is using an authorized version of the PIRATE software (as opposed to a pirated version which may have modifications designed to subvert the system).

As we incorporate reputation information into PIRATE's operations and protocols, the ability to authenticate the identity of a PIRATE user will be crucial: if you can't confirm who you're talking to, you don't really know their reputation. One proposal for such authentication has been to use RSA encryption for this purpose as well: if user A has a known public key, then A may demonstrate her identity by decrypting a message encrypted by this public key. The problem with this scheme is that users must have these keys stored on their wearables in order to be able to make use of them ``on the fly''; this might create problems of storage capacity, and definitely creates a difficult question of how to deal with someone whose identity is currently unconfirmable.

Payments

One of the advantages of electronic payment systems is that they can be used to reduce administrative overhead (for example, the time required to write or deposit checks). With that in mind, it might be useful for copyright holders (or distributors) to be able to specify entities other than (or in addition to) themselves to be the recipients of payments to which they are entitled. Thus, a copyright holder which acts on behalf of an artist might cause payments to that artist to be automatically sent directly to them. An interesting side effect of this scheme is that it would make it easy--almost trivial--for part of the proceeds from the sales of a song to be donated to an organization of the copyright holder's choice (as for a benefit album).