Proposed Architecture Synthesis

How It All Fits Together

                    ┌─────────────┐
                    │  PHYSICAL   │
                    │  MEETING    │
                    └──────┬──────┘
                           │
                    NFC tap / QR scan
                    (exchange keys)
                           │
                    ┌──────▼──────┐
                    │   CONTACT   │
                    │ ESTABLISHED │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
       ┌──────▼──────┐ ┌──▼───┐ ┌──────▼──────┐
       │  BLE sync   │ │ WiFi │ │ Tor relay   │
       │  (nearby)   │ │Direct│ │ (opt-in)    │
       │  ~30m       │ │~100m │ │ global      │
       └──────┬──────┘ └──┬───┘ └──────┬──────┘
              │            │            │
              └────────────┼────────────┘
                           │
                    ┌──────▼──────┐
                    │  Encrypted  │
                    │  Message    │
                    │  Sync       │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │  Local-only │
                    │  Append     │
                    │  Feed Store │
                    └─────────────┘

User Journey

1. First meeting — Trust establishment

• Alice and Bob meet in person
• They tap phones (NFC) or scan QR codes
• Devices exchange: Ed25519 public key, X25519 DH key, ML-KEM public key, optional display name
• Both devices perform X3DH key agreement → shared secret established
• Both devices store the contact locally — nowhere else
• Total time: 2–5 seconds

2. Still nearby — Initial sync

• Devices discover each other via BLE (using rotating, unlinkable beacons)
• Mutual authentication over BLE using stored keys
• Double Ratchet session initialized
• Exchange any pending messages or feed updates
• All data encrypted end-to-end before leaving the device

3. Later encounters — Proximity sync

• Whenever Alice and Bob are within BLE range (~30m), devices auto-detect and sync
• New messages delivered, feed updates replicated
• No internet required — works in airplane mode, underground, in areas with no coverage
• Sync is opportunistic and automatic — no user action needed

4. Online mode (opt-in)

• If both Alice and Bob choose to enable online mode:
  • Each device creates a Tor hidden service (.onion address)
  • The .onion address is shared (encrypted) with contacts
  • Messages can be sent/received over Tor — no IP addresses revealed
  • A lightweight relay (similar to SSB "room") can optionally assist with NAT traversal
  • The relay cannot read messages (E2E encrypted) or identify users (Tor)

5. Meeting new people

• When Alice is in a public space, her device advertises an unlinkable BLE beacon
• Bob's device detects the beacon — UI shows "1 person nearby" (no identity)
• If Alice and Bob want to connect, they perform the NFC tap / QR exchange
• Only then are identities revealed to each other
• No directory, no search, no "people you may know" — only physical presence

Data Model (SSB-Inspired, Privacy-Enhanced)

Each user has:
  ├── Identity keypair (Ed25519) — never leaves device
  ├── Contact list — encrypted, local-only
  │     ├── Contact A: { public_key, shared_secret, display_name, last_sync }
  │     ├── Contact B: { ... }
  │     └── ...
  ├── Personal feed (append-only log)
  │     ├── Message 1: { type: "post", content: "...", sig: "..." }
  │     ├── Message 2: { type: "profile_update", name: "...", sig: "..." }
  │     └── Each message links to previous (hash chain)
  └── Received feeds (replicated from contacts)
        ├── Contact A's feed (encrypted, only readable by intended recipients)
        └── Contact B's feed (...)

Key differences from SSB:
  - Feeds are ENCRYPTED before replication (SSB feeds are plaintext)
  - No friends-of-friends replication by default (SSB does 2-3 hops)
  - Replication only happens with direct contacts unless explicitly shared
  - Feed entries can be encrypted to specific audiences (e.g., "close friends" group via MLS)

Comparison Matrix

Open Questions & Risks

Technical:

• iOS background BLE: Apple restricts background Bluetooth advertising. This may limit passive discovery on iOS when the app is not in foreground. Potential mitigations: notification-based wake-up, using Apple's BackgroundTasks framework, or accepting reduced discovery on iOS. See iOS BLE Deep Dive for a full per-version analysis and workarounds.
• BLE range vs. privacy: 30m BLE range means devices might detect each other through walls. Is this too far for "physical proximity"? May need signal-strength thresholds (RSSI filtering) to limit effective range
• Feed storage growth: Append-only feeds grow indefinitely. Need a pruning strategy (e.g., compact after N messages, archive old entries) without breaking the hash chain
• Key revocation: If a device is lost/stolen, how do contacts learn the key is compromised? In offline-only mode, revocation can only spread through physical encounters

UX:

• Discoverability: With no search / directory, growing your network requires physical meetings. This is a feature, not a bug — but it may limit adoption
• Sync latency: In offline-only mode, messages only arrive when contacts are nearby. This is a fundamentally different UX from instant messaging — users need to understand and accept this
• Onboarding: No account creation, no server, no phone number — but also no recovery if device is lost. Backup strategy (encrypted local backup? secret sharing among trusted contacts?) is critical

Legal / Social:

• Lawful intercept: A system where no entity can read messages will face legal pressure in many jurisdictions. The structural argument ("we cannot, not will not") is the strongest defense
• Content moderation: Without centralized content visibility, moderation must be local (per-user block/mute) or community-based (trust networks). No global moderation is possible by design

Next Steps

Evaluate existing projects to build on (preferred path)

1. Evaluate Berty / Wesh Network — the closest existing project. Wesh (berty/weshnet) supports BLE, WiFi Direct, and NFC as a reusable library. Assess: Can we build our social layer on top of Wesh? Can we contribute proximity features upstream?
2. Evaluate Briar — mature, battle-tested (GPLv3). Assess: Can its Bramble transport layer be reused? Can social feed features be contributed upstream?
3. Evaluate p2panda — designed for local-first community networks. Assess: Does its data model fit our encrypted feed needs?
4. Reach out to communities — introduce ourselves, understand their roadmaps, find where our goals align

See the Implementation Options page for a full feasibility analysis of Berty/Wesh, Briar, p2panda, and other build paths.

If building a new layer or standalone app

5. Prototype the trust establishment flow — NFC tap + QR fallback exchanging Ed25519 keys. Validate on Android (NFC P2P) and iOS (Core NFC reader mode + QR)
6. Prototype BLE discovery — rotating beacons, RSSI filtering, mutual authentication after connection
7. Design the encrypted feed format — extend SSB's message format with per-audience encryption using MLS
8. Build a proof-of-concept — two Android devices: NFC tap → BLE discovery → encrypted message exchange