Existing Protocols & Systems
Briar
Briar is the closest existing system to this vision. It is an open-source, peer-to-peer encrypted messenger designed for activists, journalists, and anyone who needs secure communication — including when the internet is down.
Architecture:
- Fully peer-to-peer — no central servers
- Uses the Bramble protocol suite, purpose-built for delay-tolerant networks
- Bramble includes sub-protocols for: handshake, QR code exchange, rendezvous, synchronization, and transport
Transport layers (multi-transport by design):
- Bluetooth — offline P2P within ~10m range
- WiFi — direct device-to-device over local network
- Tor — when internet is available, all traffic routed through Tor hidden services (no IP exposure)
- Removable storage — can sync via SD cards or USB drives for extreme airgap scenarios
Contact exchange:
- Contacts are added by scanning QR codes in person — enforcing physical meeting
- No contact discovery server, no phone number / email lookup
- Each contact relationship is a unique cryptographic channel
Privacy assessment for our use case:
| Property | Briar | Notes |
|---|---|---|
| Physical-first trust | Yes | QR code scanning in person |
| Proximity discovery | Partial | QR requires intent, no passive BLE discovery |
| Offline-only viable | Yes | Bluetooth + WiFi + removable media |
| No single surveillance point | Yes | No servers, E2E encrypted, Tor for online |
| Structural privacy | Yes | Architecture makes surveillance infeasible |
| Anonymity by default | Mostly | No PII required, but Tor metadata is imperfect |
Strengths: Battle-tested, open source, already handles the multi-transport problem. Excellent security model.
Gaps for our vision: No passive proximity discovery (you must deliberately scan a QR code). No NFC support. Limited to Android (no iOS due to background Bluetooth restrictions). No append-only social feed (it's a messenger, not a social network).
For a full feasibility assessment of building on Briar's Bramble transport, see Implementation Options.
Secure Scuttlebutt (SSB)
scuttlebutt.nz · Protocol Guide
SSB is a decentralized social network protocol built on cryptographically signed, append-only message feeds. It was designed for off-grid and community use.
Core concepts:
- Each user has an Ed25519 keypair as their identity — no registration, no server
- Each user maintains an append-only log (feed) of signed messages
- Messages are JSON objects, signed and linked to the previous message (hash chain)
- Feeds are immutable — you cannot edit or delete past messages (only append new ones)
Replication — Gossip Protocol:
- When two peers connect, they exchange feeds they're interested in
- Peers replicate feeds of their friends and friends-of-friends (configurable hop count)
- This is "gossiping" — data spreads organically through the social graph
- No single peer needs to hold all data — the network is partitioned by social proximity
Infrastructure (optional):
- Pubs — publicly-addressable SSB peers that relay data. Like mailboxes: they receive and forward feeds. They are not servers — they follow the same protocol as any peer
- Rooms — lightweight relay servers that help peers find each other without storing feeds. Less centralized than pubs
Privacy assessment for our use case:
| Property | SSB | Notes |
|---|---|---|
| Physical-first trust | No | Pubs allow remote following. Could be restricted |
| Proximity discovery | No | Designed for internet gossip, not proximity |
| Offline-only viable | Partial | Gossip works over LAN, but designed for internet |
| No single surveillance point | Mostly | Pubs see connection metadata. Gossip leaks social graph to friends-of-friends |
| Structural privacy | Partial | Feed content is public to anyone who replicates it (not E2E encrypted by default) |
| Anonymity by default | Yes | Keypair identity, no PII required |
Strengths: Elegant append-only data model. Gossip replication is perfect for delay-tolerant networks. Proven at scale (thousands of users). Social network features (posts, likes, follows) built into the protocol.
Gaps for our vision: Feeds are not encrypted by default — anyone who replicates your feed can read it. The gossip model leaks social graph information (who follows whom). Not designed for proximity discovery. Private messages exist but are bolted on (encrypted to specific recipients using libsodium box). No built-in proximity discovery.
Key takeaway: SSB's append-only feed model and gossip replication are excellent building blocks, but the protocol needs significant modification to meet structural privacy and anonymity requirements. Specifically: feeds should be encrypted, gossip should be restricted to direct contacts only (no friends-of-friends without consent), and replication should work over short-range transports.
SSB's data model is compared with our proposed format in the Feed Format Spec.
SimpleX Chat
SimpleX Chat is the most structurally novel messaging system in this survey. Its core innovation: no user identifiers of any kind. Unlike every other messenger (including Signal, which requires a phone number, and Briar, which assigns you a keypair identity), SimpleX has no concept of a global user ID.
Architecture:
- Instead of user IDs, SimpleX uses simplex queues — one-way anonymous message queues hosted on relay servers
- Each contact relationship uses a pair of queues (one in each direction), known only to those two parties
- To receive messages, you create a queue and share its address with a specific person — the server does not know who owns the queue or who sends to it
- Queues are ephemeral and can be rotated without breaking the relationship
Privacy properties:
- No user profile on any server — servers see queue IDs only, which are rotated regularly
- No global identity — even a compromised server reveals nothing about who you are or who your contacts are
- No metadata accumulation — each contact relationship is isolated; knowing one queue tells you nothing about others
- Double Ratchet encryption for message content (same as Signal)
- Transport: Currently internet-based (relay servers), not offline/proximity-capable
Privacy assessment for our use case:
| Property | SimpleX | Notes |
|---|---|---|
| Physical-first trust | No | Invitations shared via links/QR, can be done in person |
| Proximity discovery | No | No offline/BLE transport |
| Offline-only viable | No | Requires relay server connectivity |
| No single surveillance point | Mostly | No global IDs; server sees only opaque queue IDs |
| Structural privacy | Strong | Queue model prevents social graph reconstruction |
| Anonymity by default | Excellent | No user IDs anywhere in the protocol |
Strengths: The queue-based no-ID model is the strongest structural privacy design found in any production messenger. Available on Android and iOS with active development. Open source (AGPLv3).
Gaps for our vision: Requires internet relay servers — not offline-capable. No BLE or proximity transport. However, the queue-based identity model is directly applicable as inspiration: our NFC tap could establish a contact-specific pair of ephemeral queues rather than exchanging long-term public keys.
Key insight for our design: SimpleX proves that identity-less messaging is achievable in production software. We should evaluate adopting the queue-based contact model over persistent keypair identity for our 1-to-1 messaging layer.
Session
Session is a decentralized messenger built on the Oxen network (a privacy cryptocurrency project). It requires no phone number, email, or any account — identity is a single Ed25519 keypair, and the Session ID (public key) is the only identifier needed.
Architecture:
- Onion routing via the Oxen Service Node Network (similar concept to Tor, but operated by incentivized nodes)
- No central servers — the Service Node network stores and forwards encrypted messages
- Session Protocol: Fork of the Signal Protocol, adapted for a decentralized store-and-forward network
- Groups: Closed groups (up to 100) and open groups (community servers)
Privacy assessment for our use case:
| Property | Session | Notes |
|---|---|---|
| Physical-first trust | No | Session IDs can be shared remotely |
| Proximity discovery | No | No offline/BLE capability |
| Offline-only viable | No | Requires Oxen Service Node Network |
| No single surveillance point | Mostly | Onion routing hides sender/recipient from nodes |
| Structural privacy | Good | No phone number linkage; onion routing for metadata |
| Anonymity by default | Strong | No registration, just a keypair |
Strengths: No phone number required. Onion routing protects metadata. Available on Android, iOS, desktop. Decentralized storage via Service Nodes. Open source (GPLv3).
Gaps for our vision: Network-dependent (Oxen Service Node network must be available). No offline/proximity mode. The cryptocurrency dependency creates alignment and sustainability questions for a non-profit project. Closed groups have known limitations with forward secrecy.
Matrix Protocol / Element
matrix.org · spec · Element client
Matrix is an open, decentralized communication standard — not an app, but a protocol with a rich ecosystem. It provides federated messaging, VoIP, and file sharing over a network of independently-operated home servers.
Architecture:
- Federated — every user is on a home server (like email); servers replicate room state between them
- Rooms — the core data structure: append-only event graph with cryptographic history linking
- E2E encryption: Megolm (Double Ratchet variant for groups) + Olm (Signal Protocol equivalent for 1-to-1)
- Bridges: Matrix can bridge to virtually any other messaging system (Slack, Discord, IRC, Signal, etc.)
- Decentralized moderation: No single entity controls the network
Privacy assessment for our use case:
| Property | Matrix | Notes |
|---|---|---|
| Physical-first trust | No | Federation is internet-based |
| Proximity discovery | No | No offline/BLE mode |
| Offline-only viable | No | Federated server model requires internet |
| No single surveillance point | Partial | Home server sees encrypted metadata; room history is replicated across servers |
| Structural privacy | Moderate | Server federation leaks room membership and message graph to participating servers |
| Anonymity by default | No | Requires a homeserver account (@user:server.tld format) |
Strengths: The most mature open communication protocol. Excellent room event model (append-only, cryptographically linked) is directly relevant to our feed design. The m.room.encrypted event type and Megolm key ratchet are well-audited. Strong cross-platform clients (Element, Cinny, FluffyChat).
Gaps for our vision: Requires internet and home servers. Federation model leaks social graph to server operators. Account model requires server registration. However, the room event graph — a persistent, append-only, DAG-structured history with cryptographic linking — is the closest existing production implementation to what we need for social feeds.
Key insight for our design: Matrix's room model and Megolm group encryption are worth studying closely as a reference for our encrypted social feed architecture. The event graph structure (each event references its parents, forming a DAG that handles concurrent edits correctly) directly solves the problem of feed replication over unreliable transports.
DeltaChat
DeltaChat is a messenger that uses email as its transport layer. Users chat through their email provider; messages are sent as specially formatted emails with Autocrypt end-to-end encryption. No new infrastructure required — it works on top of the existing email network.
Architecture:
- Sends/receives email using standard IMAP/SMTP protocols
- Autocrypt: E2E encryption key exchange embedded in email headers (opportunistic, auto-negotiated)
- SecureJoin: QR-code-based in-person key verification for strong encryption guarantees
- Webxdc apps: Mini web apps that run inside chats, syncing state between participants via email
Privacy assessment for our use case:
| Property | DeltaChat | Notes |
|---|---|---|
| Physical-first trust | Optional | SecureJoin enables in-person QR verification |
| Proximity discovery | No | Email-based, internet required |
| Offline-only viable | No | Requires email server connectivity |
| No single surveillance point | No | Email servers see metadata (sender, recipient, timestamps) |
| Structural privacy | Poor | Email providers have full metadata visibility |
| Anonymity by default | No | Tied to email address |
Strengths: Zero new infrastructure (uses existing email). Works with any email provider. SecureJoin QR verification is a production implementation of in-person trust establishment. Webxdc apps are an interesting local-first mini-app model.
Gaps for our vision: Email is fundamentally unsuitable for structural privacy — providers can see all metadata. Internet-dependent. However, DeltaChat's SecureJoin protocol (IETF draft: countermitm.net/SecureJoin) is a well-specified in-person key verification protocol that we should study when designing our NFC/QR trust establishment flow.
Nostr Protocol
Nostr (Notes and Other Stuff Transmitted by Relays) is a minimalist, censorship-resistant social protocol. It uses cryptographic keypairs as identity and relay servers as simple event stores — no accounts, no verification, just sign-and-publish.
Architecture:
- Users have an Ed25519 keypair as their identity (public key = "npub" address)
- Events are signed JSON objects with a kind (number), content, and tags
- Relays are simple servers that store and forward events — no relay needs to be trusted
- Users connect to multiple relays; losing one relay does not lose data
- Kinds: Kind 1 = short note, Kind 4 = DM (NIP-04, now superseded by NIP-44), Kind 30023 = long-form article, etc.
Privacy assessment for our use case:
| Property | Nostr | Notes |
|---|---|---|
| Physical-first trust | No | Keypairs can be created/shared remotely |
| Proximity discovery | No | No offline/BLE transport |
| Offline-only viable | No | Requires relay connectivity |
| No single surveillance point | Mostly | Events replicated across many relays |
| Structural privacy | Weak | Social graph (follows) is public by default |
| Anonymity by default | Partial | Keypair identity; but follows/interactions are public |
Strengths: Extremely simple protocol (easy to implement). Censorship-resistant (multiple relays, no central authority). Growing ecosystem (Damus, Iris, Primal, Amethyst clients). Nostr's event model — signed, typed, content-addressable events — is directly relevant to our social feed design.
Gaps for our vision: Social graph is public by default. No offline mode. Relay metadata leaks are significant. DMs have had weak encryption historically (NIP-04 is deprecated, NIP-44 is the current standard but adoption is uneven).
Key insight for our design: Nostr's event kinds model (extensible typed events, each signed by author keypair) is a cleaner social graph abstraction than SSB's monolithic feed. We should evaluate using a Nostr-compatible event format for our feed entries — this would allow future interoperability with the Nostr ecosystem without being dependent on Nostr relays.
Other Notable Systems
Airdrop / Nearby Share — Proprietary proximity file sharing. Uses BLE for discovery, WiFi Direct for transfer. Proves the UX is viable but not open protocol and not designed for ongoing social relationships.
FireChat — Used mesh networking (Multipeer Connectivity on iOS) for protest communication. Showed that ad-hoc mesh social apps can reach massive adoption during crises. However, messages were not encrypted and the network was vulnerable to surveillance.
Bridgefy — Similar to FireChat but with encryption added. SDK for Bluetooth mesh messaging. Closed source. Has had security vulnerabilities discovered.
Meshtastic — Open-source LoRa mesh networking. Very long range (km) but extremely low bandwidth. Interesting for presence/discovery but not practical for rich social features.
Berty — Peer-to-peer messaging using BLE and mDNS for local discovery, IPFS for relay. Closest to combining SSB-like concepts with proximity. Still in development. Uses the Wesh protocol (formerly OrbitDB-based).
Tox — Fully peer-to-peer encrypted messaging with no servers. Uses a DHT for peer discovery. Strong privacy model but requires internet for DHT; no offline/BLE mode. Worth studying for its DHT-based contact discovery design.
Status — Ethereum-based messaging with Web3 wallet integration. Uses Waku (a fork of Whisper) for P2P messaging over a decentralized network. Interesting for its economic identity model (ENS names) but internet-dependent and blockchain overhead is high.
GrapheneOS — Not a messaging protocol, but the recommended mobile OS for our target users. Security and privacy-hardened Android for Pixel devices. Eliminates Google Play Services surveillance. All our Android prototypes should be tested on GrapheneOS first. CalyxOS is a more user-friendly alternative with microG (a de-Googled Play Services replacement).
Protocol Comparison Matrix
| Protocol | Identity model | Offline capable | Physical-first | Metadata privacy | iOS support | Open source |
|---|---|---|---|---|---|---|
| Briar | Keypair (permanent) | Yes (BLE/WiFi) | Yes (QR required) | Strong (no servers) | No | Yes (GPLv3) |
| SSB | Keypair (permanent) | Partial (LAN) | No | Weak (public feeds) | Limited | Yes |
| SimpleX | No identity (queues) | No | Optional (in-person invite) | Excellent | Yes | Yes (AGPL) |
| Session | Keypair (public key = ID) | No | No | Good (onion routing) | Yes | Yes (GPL) |
| Matrix | Server account | No | No | Moderate (federated) | Yes | Yes |
| DeltaChat | Email address | No | Optional (SecureJoin) | Poor (email metadata) | Yes | Yes |
| Nostr | Keypair (permanent) | No | No | Weak (public graph) | Yes | Yes |
| Berty | Keypair | Partial (BLE/mDNS) | Optional (QR) | Moderate | Yes | Yes |
| BitChat | Ephemeral (BLE mesh) | Yes (BLE mesh) | No (any device nearby) | Good (no accounts) | Beta | Yes (MIT) |
Takeaway for our design: SimpleX's no-ID queue model + Briar's physical-first QR trust + Nostr's typed event format + p2panda's offline-first CRDT sync + BLE proximity transport = the combination that satisfies all our criteria. No single project delivers this; the synthesis is the contribution.
Updates (2025–2026)
p2panda — Rapid Maturation Toward Offline-First Sync
p2panda shipped two major releases in early 2025 that directly affect its suitability as a sync layer for proximity apps.
v0.2.0 "Anti-Fragile" (January 2025) (release post) reworked networking resilience: the bidirectional log-sync protocol was redesigned so both peers exchange log heights and data in a single session (previously this required two sequential round-trips), gossip overlays now self-heal after extended connectivity loss by resetting live-mode state on reconnection, and the mDNS discovery service dynamically rebinds its socket when interfaces appear — a critical fix for BLE/WiFi toggling on mobile.
v0.3.0 "Event Streams and Persistence" (March 2025) (release post) added SQLite-backed persistence (previously all state was in-memory), a Network Events API for subscribing to sync session lifecycle and peer-discovery events, and a bootstrap mode so peers can join with only a relay URL and a bootstrap node public key — removing the requirement for prior knowledge of the network.
Group encryption (February 2025) (design post) detailed the forthcoming p2panda-encryption crate (audited by Radically Open Security with NLNet funding). Rather than adopting MLS, the team applies the Double Ratchet for per-message forward secrecy and the DCGKA-derived 2SM protocol for group key agreement, achieving O(n) key-rotation complexity. Group membership is managed as a CRDT DAG — directly compatible with offline, concurrent writes. This makes p2panda the only evaluated project with a local-first group encryption design that does not require an always-online key delivery server.
Relevance: These three releases together — resilient mDNS, offline persistence, and CRDT-based group encryption — make p2panda the strongest candidate for the sync and social-feed layer of our design. The comparison matrix entry should be updated to reflect production-ready SQLite persistence and the imminent group-encryption crate.
Nostr — MLS Group Encryption Merged (NIP-EE, August 2025)
A NIP-EE pull request adding IETF MLS-based end-to-end group encryption was merged into the NIPs repository on 27 August 2025. Users are identified within MLS groups by their 32-byte Nostr public key; KeyPackage events published to relays enable asynchronous group additions; message events use ephemeral keypairs plus NIP-44 encryption with secrets derived from MLS's exporter mechanism, so relays cannot correlate group participants. ⚠ Contradicts existing content: the statement "DMs have had weak encryption historically" now applies only to 1-to-1 DMs; group messaging on Nostr has a path to strong forward secrecy via NIP-EE.
Session — Migration to Session Network (May 2025)
Session completed its migration from the Oxen Network to the standalone Session Network at the Landing Hardfork on 21 May 2025 (migration guide). The routing and onion-relay infrastructure is unchanged from a user perspective, but node operation now uses SESH tokens (an Ethereum-compatible token) instead of OXEN coin, with a 25,000 SESH full-stake requirement. The existing concern about cryptocurrency dependency remains, now compounded by Ethereum-layer token mechanics. The practical messaging protocol (onion routing, no phone number, keypair identity) is unaffected.
BitChat — BLE Mesh + Nostr Hybrid (July 2025)
BitChat, released in July 2025, combines a BLE mesh transport (Noise Protocol encryption, up to 7 hops) with Nostr as an internet fallback layer (NIP-17 gift-wrapped DMs, geohash-based local channels). Identity is fully ephemeral — no accounts, no phone numbers, no persistent keys. The app saw rapid real-world adoption during protests in Madagascar and Nepal in September 2025. BitChat validates that the BLE-mesh + Nostr relay architecture is buildable and that users adopt ephemeral identity in crisis scenarios. Unlike our design, BitChat does not require physical meeting to establish contact — any nearby device joins automatically — so it trades physical-first trust for open mesh accessibility. An impersonation vulnerability was publicly disclosed in 2025; no formal audit has been published.
SimpleX Chat — v6.x Series (2025)
SimpleX continued rapid iteration through 2025, with v6.4 and v6.5-beta (GitHub releases) adding public channels backed by user-run chat relays, ~30% memory reduction, welcome-message flows, and improved group spam protection via member-profile visibility controls. The core queue-based no-ID protocol is unchanged. The repository reached approximately 10,900 GitHub stars by April 2026. The existing page analysis remains accurate.
Briar — Continued Active Development
Briar maintained a steady release cadence through 2025–2026, reaching v1.5.17 (March 2026) and Briar Desktop v0.6.5-beta (February 2026). No protocol-level changes to the Bramble transport or contact-establishment flow were identified. The existing analysis remains accurate. The iOS gap persists — Apple's background BLE restrictions are a platform constraint, not a Briar decision.