Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 579
    • Issues 579
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Wiki
  • Fundamental Problems

Fundamental Problems

Last edited by akwizgran Jul 18, 2018
Page history
  1. Privacy-connectivity tradeoff

    • We don't want to reveal that we're part of the network
    • But we can only communicate with those who know
  2. Privacy-efficiency tradeoff

    • We don't want to reveal what data we're sending and receiving
    • But sending everything to everyone doesn't scale
  3. Security-connectivity tradeoff

    • A device can use more of the network's resources than it contributes
    • We can use stable identities to manage resource allocation
    • But this limits us to exchanging data with known identities
  4. Side-effects

    • Members of a group may receive messages in different orders
    • We can use rules to resolve conflicts and ensure eventual consistency
    • But processing a message can have side-effects that can't be reordered or undone
  5. Consensus manipulation

    • Members of a group may receive messages in different orders
    • We can use rules to resolve conflicts and ensure eventual consistency
    • But the rules can be abused to manipulate the outcome

Problem 4 is one of the things that makes multi-device support difficult - although @grote's master/slave idea could sidestep the problem.

We ran into problem 5 when working on private groups, and it's also affecting Matrix's room consensus algorithm at the moment.

At a very generic level, problems 4 and 5 can be solved with some kind of consensus mechanism in which a quorum of group members agree on an ordering of the messages. One of the key questions a mechanism like this needs to answer is who gets to be part of the quorum. If we can come up with a solution to this that's reusable across clients, it would be a very useful building block for Bramble-based systems.

Clone repository
  • A Quick Overview of the Protocol Stack
  • BDF
  • BQP
  • BSP
  • BTP
  • Blog Client
  • Blog Sharing Client
  • Client API Notes
  • Design options for multi block messages
  • Development schedule for private message deletion
  • FAQ
  • Forum Client
  • Forum Sharing Client
  • Fundamental Problems
  • Introduction Client
More Pages