Reference Implementations

Connect's architecture is a deliberate synthesis. Rather than starting from scratch, it adopts proven primitives from three existing systems — Briar, Secure Scuttlebutt (SSB), and SimpleX Chat — and extends them where no prior art exists. This page maps each Connect subsystem to its reference project, specifies what is taken directly, what is adapted, and what gap forced entirely new design.

The headline finding: no single existing project satisfies all seven Connect principles. The synthesis is necessary, not a preference. Briar provides physical-first trust and offline transport. SSB provides the append-only feed data model. SimpleX proves that identity-less messaging is viable in production. Everything else — per-audience encryption, MLS group encryption, post-quantum key exchange, passive BLE discovery — is novel to Connect.

The Seven Principles and Their Sources

Trust Establishment — Reference: Briar

Briar's QR-enforced in-person contact exchange is the closest existing implementation of physical-first trust. The mechanism is simple: both users open the app simultaneously, one displays a QR code, the other scans it, and a mutual key exchange is stored locally with no server record.

What Connect takes:

• The core principle: contact establishment requires mutual physical presence and deliberate action.
• The QR fallback: Briar's Bramble QR Exchange is the direct reference for Connect's QR flow.
• The fingerprint comparison pattern: both parties verbally compare a short displayed string to rule out relay attacks (DeltaChat's SecureJoin is the secondary reference here).

What Connect adapts:

• Adds NFC tap as the primary flow (Android P2P, faster than QR, stronger relay resistance at ~4 cm range). QR becomes the universal fallback, especially for iOS.
• Adds an ML-KEM-768 post-quantum key to the exchange payload. Briar uses only classical Diffie-Hellman.
• Removes the "both active simultaneously" requirement — NFC tap is near-instantaneous, making simultaneous intent implicit.

What Briar does not provide:

• Passive BLE discovery after trust is established. Briar has no mechanism for "silently recognise a contact when they are nearby". Connect adds rotating BLE beacons derived from shared contact keys.
• An iOS path. Briar has explicitly no iOS support; all iOS trust establishment in Connect is designed from scratch.

Offline Transport — Reference: Briar / Bramble

Bramble (Briar's transport layer) is the most directly reusable reference in Connect's design. It provides:

What Connect takes:

• The multi-transport abstraction principle — decouple the application layer from the physical transport so BLE, WiFi Direct, and Tor are interchangeable at the sync layer.
• The delay-tolerant sync model — messages queue locally; delivery happens opportunistically at the next physical proximity.
• The Tor online mode — each device exposes a .onion address known only to its direct contacts.

What Connect does not take:

• The Briar Java/Kotlin codebase. The JVM-only stack and GPLv3 licence make forking impractical for a cross-platform React Native app. Bramble is used as a design reference, not copied source. See Implementation Options for the build-path analysis.

What Briar does not provide (new in Connect):

• Passive BLE discovery via rotating unlinkable beacons.
• NFC as a key-exchange transport.
• WiFi Direct bulk escalation (an explicit BLE → WiFi Direct upgrade for larger transfers).

Social Feed Data Model — Reference: SSB

SSB's append-only hash-chained feed is the direct ancestor of Connect's encrypted feed. The structural similarity is deliberate:

SSB feed entry:
{
  author: "@<public_key>.ed25519",
  sequence: n,
  previous: "<hash of entry n-1>",
  content: { type: "post", text: "..." },   // PLAINTEXT
  signature: "<ed25519 sig>"
}

Connect envelope:
{
  version: 1,
  feed_id: "<SHA-256(identity_key.pub)>",
  sequence: n,
  previous: "<SHA-256(prev_envelope)>",
  type: "post",
  audience: "contacts",
  content_enc: "<AEAD-encrypted content>",  // ENCRYPTED
  signature: "<ed25519 sig>"
}

What Connect takes from SSB:

• Append-only hash-chained log — tamper-evident, self-authenticating, no coordination required to append.
• Ed25519 signatures on every entry — authorship proof without a certificate authority.
• Extensible content types — SSB's open content.type field maps directly to Connect's type field.
• feed_id as a stable pseudonym — SSB's @pubkey.ed25519 maps to Connect's base64url(SHA-256(identity_key.pub)), stable across rotations because it hashes the original key.

Where Connect departs from SSB:

The single most important departure: Connect's content is never plaintext to relaying nodes. A relay or any intermediate BLE peer sees only ciphertext. This closes SSB's largest privacy failure — that pub servers and gossip peers can read all feed content. See Feed Format Spec for the full wire specification.

Metadata Protection — Reference: SimpleX Chat

SimpleX Chat proves that identity-less messaging is achievable in production. Its queue model is the reference for Connect's 1-to-1 metadata protection:

SimpleX contact model:
  Alice → queue Q_A→B (known only to Alice and Bob) → Bob
  Bob   → queue Q_B→A (known only to Bob and Alice) → Alice
  Server sees: opaque queue IDs. No user accounts. No link between the two queues.

What Connect takes from SimpleX:

• The per-contact anonymous queue concept — applied to the NFC tap. The tap exchanges not just a long-term keypair but also ephemeral queue descriptors for each direction. The relay never sees Alice or Bob — only opaque queue IDs.
• The queue rotation principle — queue addresses rotate without requiring a new in-person meeting. This prevents long-term tracking even of queue IDs.
• The existence proof: SimpleX ships on Android and iOS, has been audited by Trail of Bits (2022), and demonstrates that a no-global-ID design works at scale.

What Connect adapts:

• SimpleX is internet-dependent. Connect takes the model but maps queue descriptors onto the NFC payload and delivers them via BLE or WiFi Direct in offline mode. In online mode, Tor hidden services replace SimpleX's relay servers.
• The hybrid identity model is Connect's key compromise: SimpleX has no persistent identity at all, which is incompatible with a social feed where posts need a stable signing key. Connect uses SimpleX-style queues for 1-to-1 messaging and a separate long-lived Ed25519 keypair for feed signing.

What SimpleX does not provide:

• Any offline or BLE transport.
• Social feed or group messaging.
• Physical-first trust enforcement — SimpleX supports in-person invitation via QR but does not enforce it.

Group Encryption — Reference: MLS (RFC 9420)

None of Briar, SSB, or SimpleX provides a satisfactory group encryption primitive for Connect's use case. Briar has no groups. SSB has no private groups in the base protocol. SimpleX groups use a star topology (one owner re-encrypts to each member) with no forward secrecy.

Connect uses MLS (RFC 9420), the IETF standard, for all group messaging:

• O(log n) member add/remove via TreeKEM ratchet tree.
• Forward secrecy via epoch progression.
• Post-compromise security via DH at commit.
• Any member can commit proposals — maps to Connect's leaderless, serverless model.

The "adding a member requires an existing member's commit" MLS rule maps naturally to physical-first trust: joining a group requires an existing member who physically knows the new person. See Encryption & Privacy for the full cryptographic model.

Post-Quantum Key Exchange — Reference: Signal Protocol (PQXDH)

Signal's PQXDH (post-quantum X3DH) is the direct reference: it combines X25519 classical DH with ML-KEM-768 (Kyber) in a hybrid construction that is secure as long as either primitive holds. Connect adopts this exactly, mapping the bootstrap from Signal's server-mediated prekey bundle to Connect's in-person NFC/QR exchange — which is more secure because there is no server-side MITM window at bootstrap.

Signal's October 2025 "Triple Ratchet" (SPQR), which adds a post-quantum ratchet on top of the Double Ratchet, is tracked as a future upgrade path.

What No Existing Project Provides

These Connect design elements have no reference implementation — they are genuinely new:

For a full comparison matrix of all eight evaluated protocols, see Existing Protocols.

Open Questions

• Is the hybrid identity model (SimpleX queues for 1-to-1 messaging + Ed25519 keypair for feeds) the right long-term architecture, or does it create a seam where queue and feed identities can be correlated by a shared contact?
• Can Bramble Synchronisation be extracted as a standalone library and mapped onto BLE GATT without rewriting the Java-native transport bindings?
• Is p2panda a better SSB heir for the feed layer? Its CRDT + bamboo log + MLS design may satisfy Connect's per-audience encryption requirement without additional adaptation.
• Should Connect contribute upstream to SSB, Briar, or SimpleX with the novel primitives (passive BLE discovery, per-audience encryption, NFC bootstrap) rather than building a separate application?
• Is there a path to Nostr event format compatibility for Connect's feed entries, enabling interoperability with the broader Nostr ecosystem when online, without compromising offline-first or E2E encryption?