Research Prototypes

A Different Approach: Small, Focused Experiments

The implementation options analysis evaluated eight different paths to building the full Connect vision. Every option scored low on feasibility — the combination of cross-platform BLE, custom sync protocols, encrypted feeds, and offline-first architecture makes a comprehensive build extremely ambitious.

Rather than attempting to build everything at once, a more practical strategy is to build several small, focused prototypes — each exploring one specific capability in isolation. These prototypes intentionally don't tick all the boxes. They exist to validate ideas, build familiarity with the underlying technologies, and produce working code that can inform the eventual full build.

Why Prototypes Over a Full Build

• Reduced scope = achievable goals. A Tor-only chat app is a weekend project. A full offline-first encrypted social platform is a year-long effort.
• AI-assisted development. With modern AI coding tools, small self-contained apps are well within reach for a solo developer or tiny team. The complexity ceiling for "vibe coding" is much lower than for architecting a full system.
• Learn by building. Reading about BLE GATT services is one thing. Shipping a prototype that actually syncs messages over Bluetooth teaches you what the documentation doesn't cover.
• Reuse what exists. Each prototype can fork an existing project, use an existing protocol, or wrap an existing library — no need to build from scratch.
• Platform constraints become acceptable. An Android-only BLE prototype is fine. An iOS-only Multipeer Connectivity prototype is fine. We're exploring, not shipping.

Prototype 1: Tor-Only Encrypted Chat

→ User story: The Journalist and the Source

Goal: Two users exchange messages over Tor hidden services. No proximity, no BLE — just anonymous, encrypted, internet-based messaging.

Why this first: Tor communication is the "opt-in online mode" described in our architecture. Building it in isolation lets us validate the encrypted relay concept without any of the complexity of proximity discovery or offline sync.

What It Does

• Each device runs a Tor hidden service (.onion address)
• Users exchange .onion addresses + public keys via QR code (in person) or manual entry
• Messages are end-to-end encrypted (Signal Protocol or NaCl box)
• Messages are sent directly between hidden services — no intermediate server
• No metadata: Tor hides IP addresses, no central server sees the social graph

Possible Starting Points

Target Platform

Android (primary). Desktop (Python path) as alternative. iOS possible with Veilid/Flutter path.

What We Learn

• How Tor hidden services perform for real-time-ish messaging (latency, reliability)
• Whether the QR-code-for-onion-address flow feels natural
• Signal Protocol integration complexity in a real app
• Whether Briar's codebase is practical to fork and simplify
• Baseline for "online mode" that the full app would eventually include

Scope Boundaries

• No proximity discovery
• No BLE or WiFi Direct
• No social feeds — just 1-to-1 chat
• No offline message queuing (both users must be online via Tor)
• No group messaging (unless trivially easy to add)

Prototype 2: Peer-to-Peer Bluetooth Messenger (Android Only)

→ User story: The Festival

Goal: Two Android phones discover each other via Bluetooth and exchange messages directly — no internet, no server, no infrastructure.

Why this matters: BLE/Bluetooth communication is the core transport for offline-first messaging. Android has fewer restrictions than iOS for Bluetooth, making it the right platform to start with. Understanding the real-world behavior of phone-to-phone Bluetooth is essential before building anything more complex on top of it.

What It Does

• Devices advertise presence via BLE beacons
• Nearby devices discover each other automatically
• On first meeting: exchange public keys (QR code scan or NFC tap)
• After key exchange: devices recognize each other via BLE and auto-connect
• Messages are encrypted (simple public-key encryption or Signal Protocol) and sent over Bluetooth
• Messages queue locally and deliver when the contact is next in range

Possible Starting Points

Target Platform

Android only. iOS BLE restrictions (no background advertising, coalesced scanning, stripped advertisement data) make it a separate, harder problem. Solve Android first.

What We Learn

• Real-world BLE range, reliability, and throughput between phones
• How BLE GATT services work for bidirectional message exchange
• Battery impact of continuous BLE advertising and scanning
• Whether store-and-forward over intermittent BLE connections actually works
• Android Bluetooth stack quirks (there are many)
• What message sizes are practical over BLE (~512 bytes per GATT write, need chunking for larger messages)

Scope Boundaries

• Android only — no iOS
• Bluetooth only — no WiFi Direct, no internet
• 1-to-1 only — no groups, no mesh relay
• No social feeds — just text messages
• No post-quantum crypto — simple Ed25519/X25519 is fine
• Range limited to Bluetooth (~10-30m indoors)

Prototype 3: Proximity Discovery & Key Exchange

→ User story: The First Meeting

Goal: Two phones detect each other's presence via BLE and perform a secure key exchange through NFC tap or QR code scan — establishing a cryptographic contact relationship.

Why this matters: The "physical-first trust" model is the foundation of everything. This prototype validates the most critical user interaction: meeting someone in person and becoming contacts.

What It Does

• Device broadcasts an unlinkable BLE beacon ("someone is nearby")
• UI shows "1 person nearby" — no identity revealed
• Users decide to connect → NFC tap or QR code scan
• Devices exchange Ed25519 public keys + X25519 DH keys
• X3DH key agreement derives a shared secret
• Contact is stored locally with the shared secret
• Next time devices are in BLE range, they mutually authenticate using stored keys

Possible Starting Points

Target Platform

Android (NFC P2P works fully). QR code path works on both platforms.

What We Learn

• Whether NFC tap for key exchange feels intuitive
• How fast the full flow is (tap → key agreement → contact stored)
• BLE beacon rotation and unlinkability in practice
• Whether mutual authentication over BLE after prior key exchange works reliably
• The "someone is nearby" UX — is it useful or creepy?

Scope Boundaries

• No messaging — just contact establishment and re-discovery
• No internet connectivity
• No feed or social features
• Minimal UI — focus on the cryptographic flow

Prototype 4: Encrypted Append-Only Feed (Local First)

→ User story: The Community Garden Feed

Goal: A local-first app where users create signed, encrypted social posts stored in an append-only log — with feed replication when two devices connect.

Why this matters: The social feed is what makes Connect more than a messenger. This prototype validates the data model without worrying about transport.

What It Does

• User creates posts (text) that are appended to a signed, hash-linked log
• Posts are encrypted to specific audiences (individual contacts or groups)
• When two devices connect (could be USB, WiFi, or simulated), feeds are replicated
• Conflict-free: append-only logs don't have merge conflicts
• Feeds can be selectively shared — you choose which contacts see which posts

Possible Starting Points

Target Platform

Desktop or Android. The feed model is transport-independent — start wherever is easiest.

What We Learn

• How the append-only log data model works in practice
• Per-audience encryption complexity (encrypting the same post for different key sets)
• Feed replication efficiency — how much data needs to transfer for a sync?
• Whether p2panda is practical to work with at its current maturity level
• Storage growth patterns — how fast do feeds get large?

Scope Boundaries

• No proximity discovery — connect devices manually or over local network
• No BLE transport
• No real-time messaging — this is a "social feed," not a chat
• No groups (unless using p2panda-encryption's MLS, in which case groups come naturally)

Alternative Approach: Local Portable Servers

All the prototypes above assume phone-to-phone communication — devices talking directly via BLE or Tor. But there's another model worth exploring: what if a small portable server handles the hard parts?

Instead of making phones discover each other and negotiate connections, a dedicated local device (Raspberry Pi , old phone, mini PC) acts as a local relay — phones connect to it via WiFi or Bluetooth, and it handles message storage, forwarding, and sync. No internet required. The server is physical, portable, and owned by the community or individual using it.

This sidesteps some of the hardest problems in peer-to-peer mobile development:

• No phone-to-phone BLE quirks (Android stack bugs, iOS background restrictions)
• WiFi gives real bandwidth (not BLE's ~1 Mbps theoretical)
• The server can run "real" software (Linux, Rust, Go) — no mobile platform constraints
• Store-and-forward is trivial when you have a device that's always on
• Multiple users can sync through the same server without needing to be near each other simultaneously

How It Works

┌──────────┐     WiFi      ┌──────────────────┐     WiFi      ┌──────────┐
│  Phone A │ ◄───────────► │  Local Server    │ ◄───────────► │  Phone B │
│          │   (hotspot    │  (Raspberry Pi)  │   (or BLE)    │          │
└──────────┘    or LAN)    │                  │               └──────────┘
                           │  - Message store │
                           │  - Feed sync     │
                           │  - E2E encrypted │
                           │    (can't read   │
                           │     messages)    │
                           └──────────────────┘

The server creates a WiFi hotspot (or joins an existing local network). Phones connect and sync. Messages are end-to-end encrypted — the server stores and forwards ciphertext it cannot read. It's like a local Signal server, but physical, portable, and offline.

Existing Projects That Do This

Briar Mailbox — Briar already built exactly this concept. A Raspberry Pi runs a "mailbox" service: your phone pairs with it, and when you're away, contacts can leave encrypted messages at your mailbox. When you reconnect, messages download. It uses Tor for internet connectivity but could work purely locally.

SSB Room Servers — In Secure Scuttlebutt, "rooms" are lightweight servers that help peers find each other and relay data. They don't store feeds permanently — they just facilitate connections. A room running on a local Raspberry Pi could serve a small community.

PirateBox / LibraryBox — Open-source projects that turn a Raspberry Pi + WiFi dongle into a local file-sharing server. No internet — just a WiFi hotspot serving files. The concept is proven: people connect, upload, download. Extend this model to encrypted messaging.

Meshtastic + Companion Server — Meshtastic uses LoRa radios for long-range mesh, but the companion app architecture (phone → Bluetooth → device → radio) is the same pattern. Replace the LoRa radio with a WiFi relay server.

Kiwix / Kolibri — Offline education servers on Raspberry Pi, used in areas without internet. They demonstrate that "carry a server in your backpack" is a viable deployment model in the real world.

Prototype 5: Local WiFi Relay Server

→ User story: The Community Space

Goal: A Raspberry Pi creates a WiFi hotspot and runs a message relay. Phones connect via WiFi, send/receive E2E encrypted messages through the server.

What It Does:

• Pi boots up, creates a WiFi network (no internet backhaul)
• Users connect their phone to the Pi's WiFi
• Phone app registers with the server using a public key
• Messages are encrypted on the phone, sent to the server, stored until the recipient connects
• Server is a dumb relay — it sees ciphertext and recipient public key hashes, nothing else
• Optional: server also hosts encrypted social feeds for replication

Possible Starting Points:

Target Platform: Raspberry Pi 4/5, Orange Pi, or any Linux SBC. Phone app: Android (primary), iOS (WiFi connectivity has no platform restrictions).

What We Learn:

• Whether the "carry a server" model is practical (battery life, boot time, reliability)
• WiFi hotspot range and capacity (how many phones can connect?)
• Message latency and throughput compared to BLE
• Whether users accept connecting to a local WiFi network as a UX pattern
• How this compares to pure P2P in terms of development complexity (spoiler: much simpler)

Scope Boundaries:

• No phone-to-phone communication — all traffic goes through the server
• No BLE — WiFi only
• No internet — the server is purely local
• Server must not be able to read message content (E2E encryption is mandatory)

Prototype 6: BLE Dead Drop

→ User story: The Dead Drop

Goal: A small BLE device (Pi Zero , ESP32 , or old Android phone) acts as a Bluetooth message drop-box. Phones connect via BLE to leave and pick up encrypted messages.

What It Does:

• Relay device advertises a BLE service
• Phones discover the relay, connect, and deposit/retrieve encrypted messages
• The relay stores messages until the recipient picks them up
• Works like a physical dead drop — asynchronous, no need for both parties to be present

Why This Is Interesting:

• An ESP32 costs ~$5 and runs on a battery for hours
• Can be left in a fixed location (café, community space, campus) as a persistent relay
• Avoids phone-to-phone BLE entirely — phones only need to talk to the relay
• Multiple relays in different locations create a delay-tolerant network without internet

Possible Starting Points:

What We Learn:

• BLE throughput and reliability for store-and-forward (relay is always available, unlike phone-to-phone)
• Whether fixed-location relay devices are a viable deployment model
• Power consumption and battery life for relay hardware
• Message capacity per relay device (storage limits on ESP32 vs Pi)

When Local Servers Make More Sense Than P2P

The local server model and P2P model aren't mutually exclusive. A complete system might use BLE for discovery and key exchange (Prototype 3), a local server for message relay and feed sync (Prototype 5/6), and Tor for optional internet reach (Prototype 1).

Prototype 7: LoRa Radio Mesh

→ User story: The Valley

Goal: A small group of users exchange short encrypted messages over a LoRa radio mesh — kilometre-scale range, no cellular, no WiFi, no internet, no infrastructure.

Why this matters: BLE covers tens of metres. A WiFi relay server extends coverage to a building. LoRa extends it to kilometres — the same ISM-band radio technology behind asset trackers and agricultural sensors, repurposed as a long-range message carrier. For rural areas without reliable cellular, for large outdoor events where BLE mesh tops out at a few hundred metres, or as a last-resort transport when all normal communication infrastructure fails, LoRa occupies a unique niche. Meshtastic — an open-source, GPL-3-licensed firmware project with ~7,300 GitHub stars — has already built a functional LoRa mesh stack with Android and iOS apps. (Source: github.com/meshtastic/firmware) This prototype evaluates whether the project's cryptographic envelope and data model can operate within LoRa's severe bandwidth constraints, and what that means for message length and feed design.

What It Does

• Each user carries a LoRa radio module (a small device the size of a thick credit card) connected to their phone over Bluetooth
• The phone app sends a message to the device over BLE; the device transmits it as a LoRa radio signal into the ISM band (868 MHz EU, 915 MHz US)
• Nearby devices relay the packet across a flooded mesh, up to a configurable hop limit (typically 3–7 hops)
• Receiving devices decrypt the payload and deliver it to the paired phone over BLE
• Messages are stored locally and delivered with best-effort, delay-tolerant semantics — LoRa does not guarantee delivery latency

Possible Starting Points

(Source: meshtastic.org; reticulum.network; github.com/sudomesh/disaster-radio; github.com/jgromes/RadioLib)

Target Platform

Radio hardware: Heltec WiFi LoRa 32 V3 (~$19, ESP32-S3, SX1262) as the primary development board — widely available, Meshtastic-supported. LilyGO T-Echo (~$45, nRF52840, SX1262, e-paper display, 850 mAh battery) as a production-form-factor reference. The RAK WisBlock Meshtastic Starter Kit (~$25–60) offers a modular platform for experiments with GPS and sensor add-ons.

Frequency band: 868 MHz (EU) or 915 MHz (US/CA). Hardware and firmware must match the local ISM band — the correct regional variant must be ordered.

Phone: Android primary (Meshtastic Android app; Reticulum via Termux). iOS secondary — the Meshtastic iOS app supports the same BLE-to-LoRa bridge model with no iOS-specific platform restrictions on the phone-to-device BLE link.

What We Learn

• Real-world LoRa range per hop in representative terrain: urban street-level (1–2 km expected), suburban (3–5 km), elevated hill position (10+ km in community tests) (Source: Meshtastic range-test docs meshtastic.org/docs/overview/range-tests/)
• Whether the project's crypto envelope fits within a LoRa frame: LoRa PHY supports ~255 bytes; Meshtastic and Reticulum both add framing headers, leaving roughly 200–237 bytes for application payload. The project's per-message envelope (sender public key, nonce, authentication tag) can consume 70–100 bytes of that budget, leaving 100–150 bytes for message text — short texts only, no feeds or media (Source: Semtech LoRa packet-size guide lora-developers.semtech.com)
• EU duty-cycle impact: on most 868 MHz sub-bands the duty cycle is capped at 1% (ETSI EN 300 220). An SF12 packet takes 2–5 seconds on-air; at 1% duty cycle a transmitting node must wait roughly 200–500 seconds before retransmitting on that sub-band — severely constraining ACK-based retry strategies. The 869.4–869.65 MHz sub-band allows 10% duty cycle at higher power; Meshtastic's EU preset targets this slot (Source: ETSI EN 300 220-2 V3.3.1 March 2025)
• Mesh scalability ceiling: Meshtastic's flood-routing algorithm degrades noticeably at ~50–100 active nodes per channel and delivers fewer than one in ten messages at 1,000+ nodes — flood routing causes O(n) retransmissions and air-time saturation (Source: Meshtastic mesh algorithm docs; github.com/meshtastic/firmware issue #9936)
• How chunking a longer message across multiple LoRa frames behaves under duty-cycle gaps between successive frames
• How the Meshtastic BLE protobuf API compares in complexity to the raw Android BLE work in Prototypes 2 and 6

Scope Boundaries

• No standalone spec page yet — a full technical spec (equivalent to the Prototype 1–6 spec pages) is a separate follow-on once the evaluation is complete
• No custom firmware — use Meshtastic or Reticulum as-is for the initial evaluation; do not write a custom mesh MAC layer
• No social feeds or large payloads — short text messages only; LoRa's ~200-byte practical frame budget makes anything beyond short messages a chunking exercise
• No post-quantum crypto — PQ keys (ML-KEM-768 public key is 1,184 bytes) cannot fit in a single LoRa frame
• No key revocation — this is a transport experiment, not a full identity system
• EU regulatory compliance (duty-cycle caps, EIRP limits) is the responsibility of hardware configuration; application code must not disable firmware-level airtime limiting

LoRa's Fundamental Privacy Limitation

LoRa is a broadcast medium. Every transmission is received by every radio within range tuned to the correct frequency, spreading factor, and bandwidth — there is no link-layer addressing or directionality. Without application-layer encryption, all traffic is readable by any LoRa receiver. This is physics, not a software limitation.

Meshtastic's AES-256-CTR channel encryption provides confidentiality for observers who do not know the channel PSK, but the packet header — including the sender's node ID and hop count — is transmitted in cleartext to enable relay. Even with Meshtastic's per-contact DM encryption (X25519 + AES-CCM, v2.5+), the header still exposes the sender's node ID, enabling traffic analysis. (Source: Meshtastic encryption docs meshtastic.org/docs/overview/encryption/)

Crypto envelope compatibility: Meshtastic's channel PSK model (AES-256-CTR, shared key) is fundamentally incompatible with the project's per-contact Ed25519/X25519/XChaCha20-Poly1305 envelope — the PSK is symmetric and shared across all channel members, so any node with the channel key can decrypt all channel traffic. Meshtastic's DM model (X25519 + AES-CCM, v2.5+) is structurally closer — per-contact asymmetric encryption — but differs in cipher suite, has no perfect forward secrecy, lacks Ed25519 message signing, and provides no sender anonymity at the packet-header level. Reticulum's design (Ed25519 + X25519 + HKDF + AES-256-CBC + HMAC-SHA256) is more philosophically aligned — it provides initiator anonymity by default — but uses AES-256-CBC rather than XChaCha20-Poly1305. The cleanest short-term integration path: run the project's full crypto envelope as the application payload inside Meshtastic's or Reticulum's transport layer, accepting that the radio frame header still leaks some metadata. This is structurally the same constraint as in Prototype 2 (BLE), where BLE advertisement headers are also visible to passive scanners.

❓ Uncertain: Whether Meshtastic firmware enforces EU duty-cycle caps automatically, or relies on the operator to select compliant presets. The firmware has airtime-limiting parameters; full automated enforcement behaviour was not confirmed in documentation reviewed.

❓ Uncertain: A small number of countries restrict end-to-end encryption by law. Whether such restrictions apply specifically to ISM-band LoRa devices is unclear; no primary source confirmed country-level prohibitions for LoRa ISM encryption. Flag for legal review before deploying in restricted jurisdictions.

Additional Libraries & Frameworks to Evaluate

Beyond the specific projects mentioned in each prototype above, several other libraries, protocols, and frameworks are worth evaluating. These were identified through research conducted in April 2026 and represent the broader ecosystem of tools that could accelerate prototype development or replace custom components.

P2P Networking Stacks

Iroh (n0-computer)

iroh.computer | GitHub — 8.1k stars

Rust-based modular P2P networking stack. Dial peers by public key instead of IP address. Handles NAT traversal, hole-punching, and relay fallback automatically over QUIC. Ships with three built-in protocols:

• iroh-blobs — content-addressed data transfer
• iroh-gossip — pub/sub overlay (suitable for social feeds)
• iroh-docs — eventually-consistent key-value store using the Willow protocol

Why it matters for us: Iroh is designed explicitly for mobile use. Its pluggable transport architecture means a BLE transport could be added without modifying the core. The gossip protocol is a natural fit for social feed propagation. Funded company with active development approaching v1.0.

Limitation: No built-in BLE transport yet — you'd write a custom one. Internet relay servers are part of the fallback design, so it's not purely offline out of the box.

Hyperswarm / Holepunch / Keet

keet.io | docs.pears.com

Hypercore-based P2P networking stack. Hyperswarm provides DHT-based peer discovery and hole-punching. Keet is the flagship mobile P2P messaging app built on it — a real, shipping product on iOS and Android app stores with 150%+ download growth in Q1 2026. Pear Runtime enables building zero-infrastructure P2P apps.

Why it matters for us: Keet proves mobile P2P messaging works at scale. Append-only logs (Hypercore) are a natural fit for social feeds. The Pear Runtime is a full platform for P2P app development.

Limitation: JavaScript-based (not Rust/native). Requires internet for initial DHT discovery — not offline-first. No BLE transport. Backed by Tether/Bitfinex.

Yggdrasil Network

yggdrasil-network.github.io | GitHub — 4.9k stars

Go-based encrypted IPv6 overlay network with self-healing mesh routing. Each node gets a cryptographic identity and stable IPv6 address. Mobile support exists for Android and iOS.

Potential use: Could serve as an encrypted transport layer for "online mode" (similar to Tor in Prototype 1, but lighter weight). Not suitable for offline/BLE use.

BLE Mesh & Offline Messaging SDKs

Bridgefy SDK

bridgefy.me

The most mature commercial BLE mesh networking SDK. Supports Bluetooth + WiFi Direct on both iOS and Android, with React Native and Flutter wrappers. 12.5M+ users. Two modes: private messaging and public broadcasting. E2E encryption. Used during real protests and natural disasters.

Why it matters: Validates that BLE mesh works at scale on both platforms. Closest commercial analog to what we need for the transport layer.

Critical limitation: Proprietary and closed-source. Licensing costs unclear. Dependency risk makes it unsuitable as a foundation, but valuable as a reference and proof that the concept works.

Zemzeme

zemzeme.app | GitHub

Private serverless messenger with three transport layers: offline Bluetooth mesh (~30m/hop, auto-relay), P2P via libp2p+ICE, and Nostr relay. Fork of BitChat extended with libp2p. Noise Protocol encryption. No registration, no phone number. 35+ languages.

Why it matters: Almost exactly the multi-transport model we envision — BLE mesh + internet P2P + relay fallback, all in one app. Open source (Kotlin).

Limitation: Android only. Very young project (v1.0.2). No iOS version.

Berkanan SDK

GitHub

Open-source BLE mesh messaging SDK for iOS. Discovers nearby apps, sends small messages (~70m range per hop), auto-relays for multi-hop. Uses CoreBluetooth directly.

Why it matters: Demonstrates that app-layer BLE mesh is achievable on iOS using CoreBluetooth — helpful reference for Prototype 2's eventual iOS port.

Limitation: iOS only. Activity has slowed.

Ditto (Commercial Reference)

ditto.live

Commercial edge sync platform with automatic BLE + P2P WiFi + LAN mesh networking and CRDT-based conflict resolution. Raised $82M Series B in March 2025 at $462M valuation.

Why it matters: This is the commercial gold standard for what we're trying to build. Proves that BLE + WiFi + LAN mesh with CRDTs and encryption works at scale in production. Valuable as architecture reference even though it's proprietary.

Platform APIs: Apple Wi-Fi Aware (iOS 26+)

Apple Developer Docs

New as of WWDC 2025. Enables direct device-to-device P2P communication on iOS without internet or access point. High throughput, low latency, encrypted at the WiFi layer. Co-exists with existing WiFi connections. Required by EU Digital Markets Act.

Why this is a game-changer: Previously, iOS proximity communication was limited to BLE (slow, background-restricted) or Multipeer Connectivity (opaque, hard to control). Wi-Fi Aware gives third-party apps AirDrop-like capabilities with far higher throughput than BLE. This could become the primary iOS proximity transport, making Prototype 2's iOS challenges much more tractable.

Limitation: iOS 26+ only — not yet widely deployed. Requires physical pairing flow (PIN entry).

CRDT / Local-First Data Frameworks

These are alternatives or complements to p2panda for the data layer (Prototype 4):

Loro

loro.dev | GitHub — 5.5k stars

High-performance CRDT library in Rust with JavaScript (WASM) and Swift bindings. JSON data model with rich text support. Memory and CPU optimized.

Why it matters: Rust + Swift bindings make it mobile-friendly. JSON CRDTs are natural for social feed posts. Could be the data layer for Prototype 4 instead of (or alongside) p2panda.

Automerge + Keyhive/Beelay

automerge.org | Keyhive GitHub — 196 stars

Automerge is a mature Rust CRDT library. Keyhive (from Ink & Switch, the leading local-first research lab) adds local-first access control with convergent capabilities, E2E encryption, and post-compromise security. Beelay is the co-designed sync protocol that syncs encrypted payloads a server cannot decrypt.

Why it matters: Keyhive solves a critical gap — how to do access control and E2E encryption with CRDTs in a local-first context. Convergent capabilities work without coordination, perfect for intermittent connectivity.

Limitation: Keyhive is research-stage, not production-ready.

Jazz (CoJSON)

jazz.tools | GitHub — 2.5k stars

Distributed database with CoJSON (collaborative JSON using CRDTs). Built-in user identities, permissions, roles, and sync. CoStream enables per-participant value streams — specifically designed for social features. React Native support.

Limitation: Relies on cloud infrastructure ("Global Mesh") for sync, not purely P2P.

cr-sqlite

GitHub

SQLite extension adding CRDT-based multi-writer replication. Since SQLite is the universal mobile database, CRDT-enabling it means any app using SQLite gets conflict-free sync. Very pragmatic approach for Prototype 4.

Encrypted Messaging Projects to Study

SimpleX Chat

simplex.chat | GitHub — 10.8k stars

First messaging network operating without user identifiers of any kind — not even random numbers. Uses pairwise anonymous unidirectional message queues on different servers to prevent correlation.

Why it matters: The "no user identifiers" model is philosophically aligned with our anonymity-by-default principle. The pairwise queue design is worth studying for metadata protection. Contact exchange via one-time links could be adapted for NFC/QR proximity exchange.

Limitation: Requires relay servers (self-hostable). Not offline-first. Haskell codebase.

Cwtch (Open Privacy)

docs.cwtch.im

Decentralized, metadata-resistant multi-party messaging over Tor v3 onion services. Groups use untrusted servers where the operator has no access to metadata.

Why it matters: Goes beyond encryption to protect metadata — the untrusted server model for groups is clever and relevant to our Prototype 5 (local server) design.

Quiet

tryquiet.org | GitHub

P2P alternative to Slack/Discord. Syncs directly between team devices over Tor using IPFS + OrbitDB CRDTs. No server. Channels for organizing. React Native mobile app on both platforms.

Why it matters: Demonstrates a full P2P social/team app with channels running on React Native mobile. Educational codebase.

Protocols & Specifications

Willow Protocol / Earthstar

willowprotocol.org | GitHub

Willow is a meta-protocol for distributed apps with deterministic sync, E2E encryption, total deletion (prefix pruning), and Meadowcap access control. Earthstar is a specific instantiation. New features include automatic local network peer discovery via DNS-SD and a sideloading protocol for USB sneakernet sync.

Why it matters: Willow's design philosophy aligns closely with ours — it reconciles P2P with social realities, supports deletion (critical for any social app), and has sustainable data structures. The sneakernet sideloading protocol is directly relevant to our local server model. Iroh implements Willow for its sync layer.

OpenMLS

openmls.tech | GitHub — 909 stars

Rust implementation of MLS (Messaging Layer Security, RFC 9420). Scalable E2E encrypted group messaging. New: openmls_dart wrapper for Flutter (Feb 2026).

Why it matters: MLS is the emerging standard for scalable group encryption, better than Signal Protocol for groups. The Flutter wrapper means direct use in a cross-platform mobile app. Relevant to Prototype 4's per-audience encryption.

PPPPP (SSB Successor)

An in-development successor to Secure Scuttlebutt, designed specifically for "social networks where only people who know each other participate." This is exactly our vision.

Limitation: Lead developer (staltz) stepped away mid-2024. Development status uncertain. Worth studying the design documents even if the implementation stalls.

Comparative Assessment for Prototypes

How the Prototypes Relate

Each prototype isolates one layer of the full architecture:

Full Architecture          Prototype Coverage
─────────────────          ──────────────────

┌───────────────┐
│  Social Feed  │ ◄──────── Prototype 4 (encrypted feeds)
├───────────────┤
│   Messaging   │ ◄──────── Prototype 1 (Tor) + Prototype 2 (BLE)
├───────────────┤
│  Key Exchange │ ◄──────── Prototype 3 (NFC/QR + BLE discovery)
├───────────────┤
│   Transport   │ ◄──────── Prototype 1 (Tor) + Prototype 2 (Bluetooth)
│               │           Prototype 5 (WiFi relay) + Prototype 6 (BLE relay)
│               │           Prototype 7 (LoRa — km-range)
└───────────────┘

No single prototype covers the full stack, but together they validate every major component. The eventual full build can draw on working code and real-world lessons from each prototype.

Suggested Order

1. Prototype 1 (Tor chat) — quickest to get working, most existing code to build on
2. Prototype 5 (WiFi relay server) — second easiest, standard server dev, validates the local server model
3. Prototype 3 (Key exchange) — core UX interaction, essential to validate early
4. Prototype 2 (BLE messenger) — the hardest transport problem, benefits from key exchange learnings
5. Prototype 4 (Feed model) — can be built in parallel, independent of transport
6. Prototype 6 (BLE relay) — builds on BLE learnings from Prototype 2, tests relay hardware
7. Prototype 7 (LoRa mesh) — evaluate after BLE relay; extends the relay concept to km-scale; minimal start is Meshtastic off-the-shelf

What Comes After

Once the prototypes exist, the path forward becomes clearer:

• Combine Prototypes 2 + 3: BLE discovery with proper key exchange → authenticated proximity messaging
• Add Prototype 4's feed model on top of any transport → proximity-based social feed
• Add Prototype 1's Tor layer as opt-in online mode → messages can reach contacts who aren't nearby
• Prototype 5 as community infrastructure: Local servers at gathering places, events, or community spaces provide reliable async messaging without internet
• Prototype 6 as mesh building block: Multiple BLE relay devices in an area create a delay-tolerant network
• Prototype 7 as long-range transport: LoRa extends message delivery to km-scale for rural and large outdoor scenarios where BLE and WiFi fall short — a last-resort transport layer when all other options are unavailable
• Address iOS: WiFi relay (Prototype 5) works on iOS with zero platform restrictions — this may be the easiest path to cross-platform

The prototypes de-risk the full build by proving each piece independently before integration.