Sybil-resistant channels crowdsourcing system (VSIDS)

[ichorid]

The channels crowdsourcing system is based on a concept of a change request (CR) to a channel. Each CR must be confirmed by the channel's owner. This is really easy to achieve in a centralised system with fixed identities, high availability, and no risk of a Sybil attack.

Problem statement

Design a system for suggesting atomic changes (CRs) to a Tribler Channel, that will be:

• resistant to spam and Sybil attacks (i.e. whitewashing, collusion, etc.)
• resistant to node churn (low node downtime)

The Solution

Reuse the existing VSIDS-based Channels rating system. Rank CRs inside a channel the same way we rank channels, ask users if they "recommend" 👍 a CR analogous to how they subscribe ✔️ to a channel.

Long description

Each CR is an atomic change to a particular Channel entity, such as adding or renaming a torrent or a channel folder. There are three kinds of participants in the system:

• Channel owner (CO)
• Suggestion author (SA)
• Channel subscriber (CS)

The system works as follows:

1. SA subscribes to a channel (C) created by CO. SA then creates a CR and stores it into the local Channels database.
2. CS's GigaChannelCommunity(GC) walks randomly to another peer. On introduction, GC asks the introduced peer: "do you have any recommended PRs into channel C". Then, CS pulls the CR into CS's local database.
3. CS opens Tribler and sees that there is a new CR. CS "likes" 👍 or "dislikes" 👎 the CR.
4. If CS 👎 the CR, CR is immediately deleted from the database and its hash is added to a blacklist.
5. If CS 👍 the CR, CR becomes "recommended" in the local database.
6. If CR is already known to CS, and is not on a blacklist, it is bumped ⬆️ according to VSIDS heuristic local to the channel.

This way, CO gets to know about CR eventually. If CO keeps their Tribler instance running long enough, they will get a good picture of what CRs are supported in the community of the channel, and which are not. If CO likes the CR, they will accept it and as soon as the channel is updated for all subscribers, CR entries will get deleted/merged in CS databases. If CR is rejected, it will die out eventually.
In this system, CS-es will work as both a crowdsourced spam filter, change voters and intermediary CR storage. As a result, it is in everyone's best interest to keep their Tribler instances walking as long as possible: COs get more stats, CS-es get updates, influence and engagement, while SA's keep pushing their CRs to the community.

Note the system is very gentle on everyone's attention span: no one have to work through tons of queued up 💩 to get to the relevant stuff. Instead, there is a constant, community-curated feed of suggested changes sorted by relevance.

Implementation

The system will reuse the existing components: MetadataStore, VSIDS, RQC. On the Core side, it will require minimal changes, such as support for per-channel VSIDS ratings. On the GUI side, it will require adding a sorted feed of proposed changes and the CR interface such as described in #6208

[synctext]

This alters the core of Tribler, so we need to think very carefully. I don't want to rush this in any way. Sorry for this formal bureaucratic procedural reaction. What is the design motivation behind the cardinal feature of making the tag space private permissioned property? Did you read the years of available prior work, before designing this architecture, if so how does it related to the prior art?

[ichorid]

It alters the core of Tribler.

It will not alter anything. Tribler is already collecting VSIDS stats by passively observing channels other people suggest, and storing the stats locally. The change will just extend the same local mechanism to collect stats about the incoming CR suggestions. So, no changes to protocols, core principles, etc. 🤷

What is the design motivation behind the cardinal feature of making the tag space private permissioned property?

The tag space is not going to be private property. If you search my comment for the word "tag", I'm not mentioning it at all. The issue is about adapting the rating system we already use (VSIDS) to discern between popular and unpopular CRs. That's it. No mention about tags. (The tags issue is the different one.)

Did you read the years of available prior work, before designing this architecture,

Yes, I've read all the papers you suggested when I joined the team. I thoroughly read every paper you suggest. I take it seriously. Also, we are constantly discussing the Sybil problem with @grimadas , he is suggesting papers, and I read those too.

The primary problem with every decentralized rating system I've read about is that such systems become more susceptible to Sybil attacks the more transitivity there is. The VSIDS-based system that is already working in Tribler for two years sidesteps this problem by allowing no transitivity at all . In fact, VSIDS is just a way of calculating temporal PageRank

if so how does it related to the prior art?

It already works in Tribler. For years.

p.s.
also, VSIDS is technically prior art, but from a different problem field 😉