!BuddyCast3

This version of BuddyCast adds ratings, comments, faster .torrent collecting, access to more content due to RSS subscription integration, and superior scalability.

They key problem that we will solve with !BuddyCast3 is the slow speed of peer/content discovery and limited scalability. The slow collection of .torrent files means new content takes hours to discover. The scalability problem is due to the limit of 50 hashes in a BuddyCast2 profile. This version will remove this limit. The initial version of BuddyCast was made in a very conservative manner. BuddyCast2 improved the original by only exchanging correct information of online peers. With version 3 we build further upon this operational system.

new Remote Search message

A new Bittorrent message is created to increase the number of search results. When the user issues a keyword search Tribler looks into the local megacache and issues a remote search message. Peers respond to this remote search message with the matches they find in their own megacache. The result is that as of Buddycast3 peers search 1 + 10 megacaches for matches for given keywords. This greatly enhances recall and precision.

New Buddycast message format

The new Buddycast message contains information about torrents, taste buddies, and random peers.

  • Torrent info
    • preferences: Recently downloaded torrents by the user
    • collected torrents: Recently collected torrents (include Subscribed torrents)
    • ratings: Recently rated torrents and their ratings (negative rating means this torrent was deleted)
  • Taste Buddies
    • permid
    • ip
    • port
    • similarity
  • Random Peers
    • permid
    • ip
    • port
    • similarity

Very far Future

For Buddycast8 or something we hopefully can evolve towards a simplified version of a distributed database with a generic sync protocol. The architecture blends gossip protocols with operational algorithms such as the Prophet DB sync project and add a security and resource usage model. To let the database structure evolve over the years, some form of multi-version concurrency control would be needed. With a trust-aware gossip kernel we can exchange databases updates with peers we meet, see recent experiments. This will lead to eventual consistency and spreading. To avoid complexity we carefully avoid conflict resolution by not allowing the update primitive. easy SQL in Python