NiGHTSFTP: Yes, filtering by trusted keys is exactly the way to address the problem I mentioned (malicious ratings). And sharing key databases with others you trust is also a good idea. PGP lets you do stuff like this (with key rings) and the Advogato trust network offers another approach to the same idea (see YotamAviv's earlier post about one-of-us.org).

Using a p2p storage system to store keys and ratings (more generally, certificates) also works well, since it avoids the need for a centralized or hierarchical storage system like DNS. In fact, my research is looking at just such a system.

One challenge with storing ratings as files on Gnutella is that Gnutella lookups are notoriously unreliable. That is, unless a piece of content is very popular, there's a good chance you won't find it. Therefore, it might be hard to find the ratings from people you trust, even if they exist.

How much effort would need to be made to make a system like this a reality (In LimeWire, that is)?
-=-

Would anything need to be added to "The Gnutella Protocol". Yeah, I'd suppose so.

Lets cover the basics.

* Keys sign the file.

Could this be done by appending a file itself?

...Possibly.

But that would change the SHA-1 hash after every append, defeating hashing (bad). Unless. We could add/change the ID3 tag (that might not change the hash, I should check on that..) ... But you can modify tags (facilitating the removal of keys).

There has to be something I missed. Where would signatures go?

Obviously not a central database! LOL!

* Clients want to search for the file by signer.

That means that Ultrapeers would probably need to hold this additional data, am I right?

* People want to add "Trusted Users". Thats done locally.

* People want to share trusted user database. Locally.

-=- Searching for Content
"That is, unless a piece of content is very popular, there's a good chance you won't find it." Damn freenet... err... gnutella. :P

Didnt the implementation of supernodes increase the possibility of finding files for all users?


-=- Off Topic
Has anyone else noticed that bitrates arent always displayed for MP3's in Limewire, when searching?

-=-
Also.. what about signing to prove you were the one who ripped the file? (I would like to show that "I did this", I don't care much about the RIAA. It should be an option, as far as I know). Can a key carry an "original" tag if nobody else has signed it yet. I suppose so...



(edited for: spelling, clarity)

My suggestion was to make signatures separate files. The description line for a signature file is something like SHA1(signed content)+" signed by "+SHA1(public key of signer), and the content of the signature file is the signature itself. One could generalize this to support certificates that rate files or bind names to keys.

The problem with this is that individual signatures (or certificates) are pretty unpopular items, so they might be hard to find using Gnutella. One way to fix it is to "piggyback" signature files on content files, so that they move around together. Unfortunately, if there are many signatures for a given content file, this is not practical.

Another solution is to observe that each individual only cares about singatures by the people they trust. Therefore, each person should store their own signature files (certificates). People who trust one another can also store each other's certificates. This way, a group of mutually-trusting individuals can efficiently find each another's certificates.
You can't really prove that you ripped the file and someone else didn't -- at least not without a full-blown digital rights management system (which is exactly what the RIAA wants to control the dissemination of digital music). However, you can certainly create the digital statement "I did this". Trouble is, someone else could create the same statement. The fix to this is to sign your statement with a key that other people know only belongs to you. This is the general problem that PKIs try to solve.

The basic idea is to publish your public key under a well-known name (like your email address). Your friends also sign certificates saying "Yeah, this email address is bound to that key". Other people who need to find your key look for one of these name-binding certificates signed by someone they trust (this is basically how PGP's web of trust works, though I omitted some details). You could imagine richer "digital identity systems" that bind stuff like your real name, social security number, and even digital picture to your public key. These certificates would be signed by well-known government or corporate entities, and so could be used in various secure digital applications.

Are we offtopic enough yet?

How bout not even having signature files traversing the network? What about using my sharing of database idea.. but then.

SHA-1 Hashes are unique, right? So I couldnt, say, make a movie file or text file with the same hash without extreme difficulty.

Now. What bout making a database like...

|File------------------------|Signer----------|Hash------|Rating----|
|A Perfect Circle- Judith.mp3 | "6YH%%s36t^" | "Ya^h361G^@dsa" | 9
|Deftones- Magdalena.mp3 | "Ag24#61gD!c" | "243(6YHW)51d6" | 8
etc, etc, etc

Okay.

Im burnt. Maybe you can fill in what I am trying to explain. That is, not needing those little files, but using a database, with a trust system.


Umm... not till the topic turns to porn or warez!

You don't really need the signer at all. Here's what you do instead:

You can create a website like sharereactor, where people who are registered can submit new files. You set up system to let users rate the files (and calculate a rating for the user who posted them), so after a while you will have trusted users that will post files that you will trust.

Taliban:

Ratings web sites work great when the content being rated is legal (i.e. not copyrighted). The one-of-us.org site mentioned above combines content rating with a trust network. However, if users want to rate copyrighted material (like rips of music or video), a ratings website could be seen as supporting the violation of those copyrights, and thus might be shut down. Storing ratings in a decentralized system like Gnutella might be more prudent.

NiGHTSFTP:

A single database has the same problem as a single website: it's a central point of failure. Suppose we instead store copies of the ratings database on Gnutella: this helps it resist attack, but now it's unclear how to propagate updates to the database.

Perhaps what we want is a way to push the little individual ratings files around the network, and each client can grab and save the ones it cares about. So, instead of a centralized ratings database, everyone has their own local database that contains only those ratings it wants (e.g. those signed by people you trust or ratings for a particular file).

What I was thinking was, have a simple addition to the client that involves the use of trading local databases via trading them with people you know. i.e. keep a large database of files that are rated high/low, and allow the database to be sent to friends via email attachments, or what have you.

Then, "merge trusted database" function that would add to your own, creating a larger one.

The only problem with that, that I can see, is that over time the database could grow quite large, and would slow down searching, or whatever else because of its size (slowness to search the local database?).

But, how could the little signature files be propogated without flooding the network with junk?

Grr, that last post was mine. I wasnt logged in.

Storing ratings in Gnutella will be very insecure.

Taliban: In what way? Digital signatures protect the integrity of individual ratings, and if each user maintains a list of public keys that they trust, they can filter out ratings they don't care about. The main problem with storing ratings on Gnutella is that individual ones might be hard to find.

NiGHTSFTP: Searching a local database can be made pretty fast, as long as you filter out the junk. But you're right about propagating the little rating files all over the network -- that might be bad for bandwidth. A compromise solution might be to use a protocol that "syncs" two users databases. There are efficient protocols for this that use hash trees.