Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
rdsys
rdsys
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

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.

  • The Tor Project
  • Anti-censorship
  • rdsysrdsys
  • Issues
  • #21

Closed
Open
Opened Oct 23, 2020 by Philipp Winter@phwMaintainer

Collapse Salmon's social graph into root nodes to preserve privacy

We may be able to build a more privacy-preserving version of Salmon which does not store a social graph on the server.

Quoting Cecylia's explanation:

Each social group in Salmon is uniquely identified by the root of the invitation tree (the person who was not invited, but joined the system on their own and then invited others). One way to avoid storing social graph data is to only store the bridges known to a social group along with the root user's identifier on the server. A user's social group root identifier will then be included in the tokens stored on the client side, so when a client requests more bridges, they present their social group's identifier. The server then only assigns them bridges known to that group already if possible. Otherwise, if a new bridge is discovered by a member of the group, that bridge is appended to the list of bridges associated with the root identifier at the server.

Let's use this ticket to build a prototype.

Assignee
Assign to
Sponsor 30 - Objective 2.3
Milestone
Sponsor 30 - Objective 2.3
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/rdsys#21