Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
briar
briar
  • Project
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 522
    • Issues 522
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 5
    • Merge Requests 5
  • 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
  • Forum client
  • Forum sharing client
  • Fundamental problems
  • Introduction client
  • Messaging client
  • Private group client
  • Private group sharing client
More Pages
×

New Wiki Page

Tip: You can specify the full path for the new file. We will automatically create any missing directories.