BigBrother Specs 
Big Brother can't watch you!
Table of Contents
Abstract
BigBrother defines a family of protocols that when combined create a decentralized peer-to-peer messaging stack. BigBrother should enable various messaging types, in order to be called a messaging stack.
The family of protocols SHOULD be flexible enough to allow various use case implementations not limited to that being defined by the entire family. The BigBrother protocol itself defines mainly the way the family of protocols interact with one another allowing for customizability on each layer.
Motivation
TODO: TALK ABOUT SHORTCOMINGS OF WHISPER
Terms
| Term | Definition |
|---|---|
| Stack | Defines the entire family of protocols, how they interact and what goals are achieved. |
| Protocol | Defines a single layer in the stack along with its endpoints used for communication with various other protocols in the stack. |
Design Goals
- Anonymity -
sender/receiverMUST remain anonymous. - Unlinkability - It should not be identifiable which parties are talking to eachother.
- Scalable - @TODO
- Incentivized - @TODO
- Decentralized - @TODO
- Resistant - @TODO
- Inclusive - Protocols within the stack should be designed to work on resource restricted devices, this allows for a higher participation making the entire BigBrother protocol more usable and reliable.
System Design / Architecture
The protocols summarized by BigBrother all follow a standard of architectural design principles with the goal of keeping each component noncomplicated. We architect a stack where each protocol interacts holistically, without the desire to create unnecessary complexity. Each protocol included in the stack should be simplistic enough to allow for multiple implementations creating client diversity, allowing us to ensure that the entire stack is unambiguous1.
SOLID
Throughout the design of the stack we follow the SOLID design principles, redefining them slightly so they make sense in the context of protocols.
- Single Responsibility principle: Each protocol in the family should only have a single responsibility.
- Open/closed principle: @TODO
- Liskov substitution principle: @TODO
- Interface segregation principle: @TODO
- Dependency inversion principle: @TODO
Stack
The below table shows the intended layers of the network from the highest to the lowest.
| Layer / Protocol | Purpose | Example |
|---|---|---|
| Sync Clients | End user functionality | 1:1, group chat, tribute, ... |
| Data Sync | Syncing data/state | Bramble Sync Protocol (ish) |
| Secure Transport | Confidentiality, PFS, etc | Double Ratchet |
| Transport Privacy | Metadata protection | Mixnet? |
| P2P Overlay | Overlay routing, NAT traversal | libp2p? |
Phases
Inspired by the ETH 2.0 implementation process, we have decided to roll out BigBrother in multiple phases. The phases can mostly be linked to various layers in the stack. Some of these phases are sometimes more loosely coupled than ETH 2.0 components meaning they can be done in parallel as only the communication API is relevant.
Phase 0 - XKEYSCORE (Data Sync)
Phase 1 - BULLRUN (Transport Privacy Layer)
- Mixnet
- PSS
- Bluetooth local network
- Sneakernet
Phase 2 - STONEGHOST (P2P Overlay)
Phase 3 - CREDIBLE (Secure Transport)
- Message Layer Security (MLS)