Trustabit: A finer-grained trust and ranking system --------- 0.10 - Tue Feb 17 04:12:21 UTC 2004 The Goal -------- Existing trust and friend networks have a flaw: they are too coarsely grained. You either trust a person or you do not. You either are or are not friends with a person. In contrast, Trustabit lets you specify that you trust a person in specific areas. For example, you can trust my views on Science Fiction Books without trusting my views on U.S. Politics. Further, you control your own data. You control whether it's publicly available or which friends see it. You control whether you pass on recommendations from your friends. How it Works ------------ Trustabit has two major components, ratings and friends. A rating is a statement about a thing, putting it in a category and type and giving it a numeric score from one to five and a description. For example, a positive review of "The Princess Bride" might have a category of "Movies", a type of "Fantasy", a description of "A fairy tale with pirates, torture, murder, giants, revenge, and true love", and a score of five. Suppose Alice publishes this rating on her site, at http://example.com/~alice/ratings.yml, in YAML form, as that's what Trustabit expects right now. The file will contain: --- #YAML:1.0 category: Fantasy description: William Goldman's satirical classic name: The Princess Bride rating: 5 type: Movies For Bob to process this file, he must mark Alice as a friend. A friend has a name (Alice), a link (http://example.com/~alice/ratings.yml), and a default trust level (a number from one to five). Bob should fetch Alice's ratings.yml file and process it with his software. Bob's trust level for Alice determines the rating he sees for "The Princess Bride". If Bob trusts Alice completely, he will give her a trust level of 5 and will see the rating of the movie as 5. If he trusts her less, he will see less of a score for the movie. Of course, if Alice rated the movie at a 4 and Bob trusts her at a 5, the score will remain at 4. Scores never inflate, but they do deflate. Bob can also choose to pass these ratings on to his friends. If he collects and publishes ratings from all of his friends at http://example.com/~bob/friend_ratings.yml, Charlie can receive ratings filtered through Bob (and Charlie's rating of Bob). Finer-Grained Trust ------------------- Of course, Charlie might not trust Bob's taste in Movies at all, while trusting his taste in Thai Restaurants completely. Charlie can be more specific about his trust by setting trust categories. Charlie's friend file for Bob will then resemble this YAML data: --- #YAML:1.0 id: 200 link: http://example.com/~bob/tab.yml name: Bob trust_categories: Movies: 0 Restaurants: Thai: 5 trust_level: 4 That is, Charlie generally trusts Bob at a level 4 out of 5 possible. He does not trust his taste in the Movies at all and will never see any ratings from Charlie that have that category. He will trust any rating in the Restaurants category and the Thai type completely, though. Everything else will use the default trust level of 4. Categories ---------- There's no central list of categories. You're in charge. You can create category mappings for your friends. If, for example, Charlie uses Science Fiction as the category and Books as the type but Dale prefers the other way around, Dale can alias that category to Books/Science Fiction instead. Aliases associate types with top-level categories and a tuple of new category and new list with the types. That is, if Dale keeps track of Charlie with an author_id of 100, his alias file would resemble: --- #YAML:1.0 category: Books: Science Fiction: - Science Fiction - Books id: 100 Friend of a Friend Ratings -------------------------- Where multiple friends both rate a thing, Trustabit uses an average of the effective rating. That is, if Charlie receives a rating of the movie at a 4 from Alice (while she rated it a 5, he trusts her at a 4) and from Dale, who rated the movie at a 2 and whom he trusts as a 5, Charlie will pass on the rating with a score of 3, as it received two points from Dale and four from Alice. The current scheme uses a simple mathematical average with two digits of precision. The point is not to be scientifically accurate, simply to be more interesting than other schemes. Limitations ----------- The current system has no mechanism for merging descriptions of things. The current software does not allow creating or editing trust categories, though they're reasonably easy to add. The current software provides no means by which to add or edit aliases. Neither does it report new ratings. Arguably, it should do all these things. The current system uses YAML files, which is very convenient and text-editable. This is not so much a limitation as a design decision. Of course, nothing forces you to use this software nor to use YAML files in your own implementations. It's a nice serialization and exchange format, however. Files in the Distribution ------------------------- Run Build.PL to install the software. You'll need Module::Build to install. Alternately, copy the files into your preferred directory. Install YAML. You'll not be able to avoid this. To run the tests, install Test::Simple, Test::MockObject, and Test::Exception. The .cgi files in the examples/ subdirectory allow you to add friends and ratings. You'll have to modify both files to add a path to the directory where Testabit should store its data files. You'll also have to create this directory hierarchy: .testabit/ aliases/ friends/ incoming_ratings/ The .pl files in the examples/ subdirectory allow you to fetch ratings from your friends, if they have web-accessible links and to process incoming ratings and publish them to friend_ratings.yml. Again, you'll have to modify both files to add a path to the storage directory. Random Ideas ------------ This is more a proof of concept than anything. In particular, it provides no nice editing interface to ratings and friends, though I don't mind editing YAML files or creating Perl data structures and serializing them. (That's why I didn't use XML.) I don't mind if you reimplement the software in another language or with another approach, though I do think the idea of serializing this data to YAML files is pretty handy. I've tried to stay away from enforcing policy. I do very much like the simplicity here though and prefer not to get too formal. I also very much think that decentralization is the way to go here. Calculating the flow of ratings across a graph of users tripped me up for a long time until I swapped the problem around and made everyone else do it. Hey, there's code here that does it. There's not so much documentation in the modules itself. I thought it more important to write this README than to give you API level documentation right now. It's coming. Copyright --------- This code -- this particular expression of the idea -- is copyright (c) chromatic, 2004. I offer it to you under the same terms as Perl 5.8.3, dual-licensed under the Artistic License and the GNU GPL, per your preference. There's no warranty of course. I claim no copyright over the idea itself, but do ask that you give me credit for asking an interesting question and offering an interesting answer. Contact ------- Drop me a line at chromatic at wgz dot org if this is interesting. I may or may not set up a mailing list or a web page.