Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #7520

Closed (moved)
Open
Opened Nov 20, 2012 by Aaron Gibson@aagbsn

Design a social bridge distributor

The sixth strategy outlined at https://svn.torproject.org/svn/projects/design-paper/blocking.html#tth_sEc7.4 describes a social bridge distribution strategy:

The sixth strategy ties in the social network design with public bridges and a reputation system.
We pick some seeds — trusted people in blocked areas — and give them each a few dozen bridge addresses and a few delegation tokens.

Some other services use a similar system to try and restrict the set of users using an invite system. One example is private bittorrent trackers.

In an email, I described such a system:

Here's a simple concept for how this model might be applied to bridge
distribution:

The basic idea is:
1. Create a handful of tokens that can be exchanged for an account
that may request a bridge.
2. Periodically give accounts some tokens to hand out to ther friends.

Most (all?) of the private trackers employ a ratio system - and you
lose your account if you don't maintain a ratio above a certain
threshold. That is, they try to separate users by behavior, and drop
the ones whose behavior is undesirable.

In the context of bridges, we want to be able to separate users into
two groups: users who use bridges, and users who block them.

1. Each time a user is given a bridge, note the bridges given to that user.
2. Each time a bridge is blocked, increment a per-user counter for
every user given that bridge.
2a. Shuffle the affected users so that the same users are not given
the same bridges twice. If using a hashring, a key consisting of the
user-id+counter might be sufficient.
3. Periodically, rank users by this counter, and drop the worst N
percent of users.
4. Periodically, allocate new account tokens in proportion to
available bridges to random users in the 100-N percent.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#7520