Offline/Decentralized Messaging: Implementation Options

An in-depth analysis of implementation paths for a proximity-based social app requiring physical-first trust, offline-first transport, structural privacy, and cross-platform support (Android + iOS).

Last updated: April 2026

Option 1: Briar / Bramble Transport

briarproject.org | GitLab | GitHub Mirror

Current State of the Codebase

Briar is written in Java/Kotlin, licensed GPLv3. The project maintains active development with release 1.5.17 (February 2026) being the most recent, primarily containing Tor upgrades. The codebase is well-organized into discrete modules:

• bramble-api -- interface definitions for the entire Bramble protocol suite
• bramble-core -- core implementations (crypto, DB via H2, transport, sync)
• bramble-android -- Android-specific transport bindings (Bluetooth, WiFi)
• briar-core -- Briar application logic (messaging, forums, blogs) built on Bramble
• briar-android -- Android UI layer

The Bramble protocol suite encompasses five sub-protocols: Handshake, QR Code, Rendezvous, Synchronization, and Transport. These are tightly coupled but logically separated behind API interfaces using dependency injection (Dagger).

Modularity Assessment

Bramble is architecturally modular but practically difficult to extract. The API layer (bramble-api) cleanly defines interfaces for transport, contact management, key agreement, and synchronization. However:

• The transport layer assumes the full Bramble security model (its own key agreement, not pluggable)
• Database layer (H2) is deeply integrated into the sync protocol
• Android-specific BLE/WiFi code lives in bramble-android and uses Android's BluetoothAdapter directly -- not portable to iOS
• No WebAssembly or cross-compilation target exists
• Dagger dependency injection is wired throughout, making selective extraction non-trivial

To extract Bramble transport, you would need to fork the repository and strip out the briar-* layers, then reimplement the Android transport bindings for your target platform. This is a substantial effort estimated at 4-6 months of dedicated work.

What It Would Take to Add Key Features

Passive BLE discovery: Briar currently requires deliberate QR code scanning to establish contacts. Adding passive BLE beaconing would require: (1) new advertising/scanning service in bramble-android, (2) a new "stranger presence" protocol not currently in Bramble's model, (3) changes to the contact model to support unauthenticated proximity awareness. Estimate: 2-3 months.

Social feeds: Briar has forums and blogs internally, but they use a proprietary sync model. Building SSB-style append-only feeds would mean either extending Briar's existing blog system (which is close but not general-purpose) or building a new module on top of Bramble sync. Estimate: 3-4 months.

iOS support: This is the critical blocker. Briar has explicitly stated they have no plans for iOS. The entire codebase is JVM-based (Java/Kotlin). Porting would require either: (a) rewriting Bramble in a cross-platform language (Rust, C++), or (b) using Kotlin Multiplatform (KMP) -- which the Briar team has not pursued. iOS background BLE restrictions add a further fundamental constraint that Briar's always-on Bluetooth model does not account for. Estimate: 12-18 months for a credible iOS port.

Community Health

• Small but dedicated team (3-5 core contributors)
• Development pace is steady but slow (~monthly releases, mostly maintenance)
• Contribution process runs through their GitLab instance with merge requests
• The team is focused on their own roadmap (desktop client, mailbox feature); external feature contributions may not align
• GPLv3 licensing means any derivative work must also be GPL -- this constrains distribution models

Feasibility Score: 2/5

Time-to-Prototype: 6-8 months

Even getting two devices exchanging keys requires forking and understanding the full Bramble stack. The JVM-only constraint makes cross-platform work extremely difficult.

iOS Viability: Very Poor

No iOS port exists or is planned. The JVM dependency and always-on Bluetooth model are fundamentally incompatible with iOS constraints. This is a dealbreaker for our requirements.

Community Alignment: Low-Moderate

Briar's goals (secure messaging for activists) partially overlap with ours, but their explicit rejection of iOS and lack of interest in social feed features means our contributions would likely not be welcomed upstream.

Key Risks

• Forking a GPLv3 project creates ongoing maintenance burden
• No path to iOS without a complete rewrite
• Small team may not be responsive to external contribution needs
• Bramble protocols are not implemented by any other project, creating vendor lock-in

Minimal Implementation Plan

1. Fork Briar repository, study Bramble API interfaces (2 weeks)
2. Strip briar-* layers, isolate bramble-core + bramble-android (4 weeks)
3. Build minimal BLE discovery + key exchange on Android (4 weeks)
4. Attempt Kotlin Multiplatform extraction for iOS (8-12 weeks)
5. Hit iOS background BLE wall, reassess entire approach

Option 2: Berty / Wesh Network

berty.tech | GitHub | Wesh Network

Current State of weshnet

Weshnet is written in Go with gomobile bindings for Android and iOS. The repository shows active development (last updated March 2026) along with supporting libraries go-orbit-db and go-ipfs-log. The library provides:

• Account and device management (multi-device support)
• Contact exchange via QR/deep link
• 1-to-1 and multi-member group messaging
• Direct transports: Android Nearby, Apple Multipeer Connectivity, BLE for cross-platform
• IPFS-based relay for internet connectivity

The Wesh Protocol API is defined via Protocol Buffers with gRPC, making it language-agnostic in theory. Documentation is available at buf.build/berty-technologies/weshnet.

BLE on iOS via Wesh

Berty uses a three-layer transport strategy:

For same-platform communication, Berty leverages platform-native frameworks (Multipeer Connectivity on iOS, Nearby on Android) which can use WiFi Direct for high-bandwidth transfer. For cross-platform (iOS-to-Android), only BLE is available, which is significantly slower and bandwidth-limited.

Known iOS BLE issues: iOS background BLE scanning is restricted -- apps must specify service UUIDs (no wildcard scans), duplicate discoveries are coalesced, and advertising data is stripped in background mode. Berty has worked around many of these constraints, but background discovery reliability remains imperfect. The weshnet-expo React Native library is marked as work-in-progress and has open issues including Android build failures.

IPFS Dependency

IPFS is deeply integrated into weshnet's architecture. It serves as:

• The relay mechanism for internet-based communication
• The rendezvous point system (using TOTP + public key for address generation)
• The data replication layer (via OrbitDB / IPFS log)

Making IPFS optional would require significant refactoring. The ipfsutil package is tightly coupled throughout the codebase. For a purely offline app, the IPFS layer would be dormant but still compiled into the binary, adding to binary size (~15-30MB overhead from Go + IPFS).

Community Health & Funding

Berty Technologies is a French non-profit NGO. Their funding model relies on grants and donations. The weshnet-expo React Native integration is still in early stages. Community engagement appears moderate -- the project has open issues and accepts contributions, but the core team drives the roadmap. Specific funding amounts and 2025-2026 roadmap details are not publicly available, which introduces uncertainty about long-term sustainability.

Feasibility Score: 3/5

Time-to-Prototype: 3-4 months

Weshnet provides a more complete starting point. Using the Go library via gomobile bindings, two devices could exchange keys and messages relatively quickly. The gRPC API is well-defined.

iOS Viability: Moderate

Berty is the only project in this analysis with production iOS BLE code. It works but with limitations: background discovery is unreliable, cross-platform BLE is slow, and the gomobile binary is large. This is the best existing iOS option but not without significant caveats.

See iOS BLE Deep Dive for the full technical constraints and workarounds.

Community Alignment: Moderate-Good

Berty's goals (censorship-resistant communication) align well with ours. The Wesh protocol is designed to be reusable. However, their focus is on messaging, not social feeds, and the IPFS dependency may conflict with our offline-first priorities.

Key Risks

• NGO funding model creates sustainability uncertainty
• IPFS dependency adds complexity and binary size for offline-first use case
• gomobile bindings create debugging and performance challenges
• weshnet-expo (React Native integration) is immature
• Go + gomobile on iOS has known memory and battery issues

Minimal Implementation Plan

1. Set up weshnet development environment, build for Android + iOS via gomobile (1 week)
2. Create minimal React Native bridge or native app using weshnet gRPC API (2 weeks)
3. Implement contact exchange via QR code using weshnet's built-in protocol (1 week)
4. Test BLE discovery and message exchange between Android and iOS devices (2 weeks)
5. Evaluate performance, battery impact, and background reliability on iOS (2 weeks)
6. If viable, build social feed layer on top of weshnet groups (4-6 weeks)

Option 3: Custom Implementation (BLE + Signal Protocol + Custom Sync)

Architecture

┌───────────────────────────────────────────┐
│           React Native App                │
│  ┌─────────────┐  ┌────────────────────┐  │
│  │  UI Layer   │  │  Feed/Social Layer │  │
│  └──────┬──────┘  └────────┬───────────┘  │
│         │                  │              │
│  ┌──────▼──────────────────▼───────────┐  │
│  │      Message Layer (sync engine)    │  │
│  │  - Gossip protocol                  │  │
│  │  - Conflict resolution              │  │
│  │  - Queue management                 │  │
│  └──────────────┬──────────────────────┘  │
│  ┌──────────────▼──────────────────────┐  │
│  │      Crypto Layer                   │  │
│  │  - Signal Protocol (X3DH + Double   │  │
│  │    Ratchet) via libsignal-ts        │  │
│  │  - MLS for groups                   │  │
│  └──────────────┬──────────────────────┘  │
│  ┌──────────────▼──────────────────────┐  │
│  │      Transport Abstraction          │  │
│  ├──────────┬──────────┬───────────────┤  │
│  │   BLE    │  WiFi    │  Tor          │  │
│  │  (plx)   │  Direct  │  (opt-in)    │  │
│  └──────────┴──────────┴───────────────┘  │
└───────────────────────────────────────────┘

Component Analysis

BLE Layer: react-native-ble-plx (v3.3.0) is the most mature React Native BLE library. It supports advertising, scanning, GATT services, and works on both iOS and Android. However, it is a BLE Central client only -- peripheral advertising requires additional native modules. Alternatively, the Offline Protocol Mesh SDK offers a higher-level abstraction with BLE + WiFi Direct + Internet transport switching, cluster-based architecture, and a Rust core with MLS encryption built in.

Encryption: Two viable paths exist:

• @privacyresearch/libsignal-protocol-typescript -- pure TypeScript implementation of Signal Protocol, works with Expo/React Native without native build complexity
• @signalapp/libsignal-client -- official Rust-based implementation with native bindings, more performant but harder to integrate with React Native

WiFi Direct: react-native-wifi-p2p exists but is Android-only. iOS has no public WiFi Direct API -- Apple restricts this to Multipeer Connectivity (which is not cross-platform). This means WiFi Direct escalation only works Android-to-Android.

Sync Protocol: Must be built from scratch. Requires:

• Message queuing for store-and-forward
• Conflict-free state merge (CRDTs or vector clocks)
• Efficient delta sync over low-bandwidth BLE
• Feed replication logic (append-only log gossip)

Effort Estimate

Feasibility Score: 2/5

Time-to-Prototype: 8-12 weeks

Getting two devices to exchange keys over BLE with Signal Protocol encryption is achievable in this timeframe. The sync protocol and social features add significantly more time.

iOS Viability: Moderate

React Native BLE libraries work on iOS, but background BLE is constrained by Apple's CoreBluetooth restrictions: no wildcard background scanning, coalesced discovery events, stripped advertising data in background. These are the same fundamental constraints every project faces. Custom implementation gives maximum control over workarounds but requires deep iOS BLE expertise.

Community Alignment: N/A (custom build)

No upstream community to contribute to. You own the full stack but also the full maintenance burden.

Key Risks

• Building a reliable sync protocol is extremely difficult -- this is the primary risk
• BLE cross-platform interop is notoriously buggy (especially Android's BLE stack)
• Maintaining native BLE code for two platforms is ongoing effort
• No battle-testing of crypto integration -- security audit required
• WiFi Direct unavailable on iOS limits bandwidth for cross-platform scenarios
• Total scope is large for a small team

Minimal Implementation Plan

1. Set up React Native project with react-native-ble-plx (1 week)
2. Implement BLE advertising and scanning on Android (2 weeks)
3. Implement BLE advertising and scanning on iOS, handle background mode (3 weeks)
4. Integrate @privacyresearch/libsignal-protocol-typescript for key exchange (2 weeks)
5. Build QR code contact exchange flow (1 week)
6. Implement basic message send/receive over BLE GATT (2 weeks)
7. Design and build store-and-forward sync protocol (6-10 weeks)
8. Add append-only feed data model (4 weeks)

Option 4: p2panda (as Data Layer)

p2panda.org | GitHub

Architecture Overview

p2panda is a Rust-based toolkit for building local-first, peer-to-peer applications. It is designed as a modular set of crates rather than a monolithic framework:

• p2panda-core -- extensible data types for the p2panda protocol
• p2panda-store -- database interfaces and implementations
• p2panda-net -- broadcast-based networking abstraction (transport-agnostic)
• p2panda-sync -- efficient set reconciliation for data sync
• p2panda-encryption -- MLS-based group encryption (released early 2025)
• p2panda-blobs -- binary large object handling

All crates are at v0.1.0, indicating early-stage releases.

As a Feed/Data Storage Layer

p2panda's data model is built on cryptographically signed, append-only operations -- very close to what we need for social feeds. Key characteristics:

• Append-only logs with hash-linked entries (similar to SSB)
• CRDT-based conflict resolution for concurrent edits
• Transport-agnostic: p2panda-net is described as a broadcast abstraction independent of the underlying transport, supporting everything from Internet Protocol to LoRa and BLE
• Group encryption: p2panda-encryption uses MLS (Messaging Layer Security) for group key negotiation, with two modes -- Data Encryption (long-term symmetric key) and Message Encryption (per-message ratchet with forward secrecy)
• Access control: Work on a convergent, offline-first access control CRDT was published in August 2025

Combined with Separate Transport Layer

p2panda could serve as the data/feed layer while a separate BLE transport handles proximity communication:

┌────────────────────────────────┐
│  App Layer (React Native)      │
├────────────────────────────────┤
│  p2panda-core + p2panda-store  │
│  (feed model, encryption,      │
│   sync reconciliation)         │
├────────────────────────────────┤
│  Custom BLE Transport          │
│  OR Wesh BLE layer             │
│  OR Offline Protocol Mesh SDK  │
└────────────────────────────────┘

The challenge is integration: p2panda is Rust-native with WebAssembly bindings. Using it from React Native requires either:

• Rust FFI bridge (e.g., uniffi or react-native-rust-bridge)
• WebAssembly execution in a JS context (possible but with performance overhead)
• Native modules wrapping the Rust library per platform

Production Maturity

p2panda is not production-ready. All crates are v0.1.0. The encryption crate was pending a security audit by Radically Open Security as of early 2025 (audit status unknown). The team is small (funded by NLNet and UK Innovate grants). However, the architecture is thoughtful and the Rust foundation provides strong guarantees.

Feasibility Score: 3/5 (as data layer combined with another transport)

Time-to-Prototype: 4-6 months

Using p2panda purely as a data layer requires building the transport separately. The Rust-to-React-Native bridge adds integration overhead.

iOS Viability: Good (for data layer)

As a data layer, p2panda compiles to native code via Rust, which runs well on iOS. The iOS constraints are purely at the BLE transport level, which p2panda intentionally does not own.

Community Alignment: Good

p2panda is explicitly designed for local-first, community-oriented applications. Their data model aligns closely with our encrypted feed needs. The modular crate design invites composition. The team is small but thoughtful and receptive to collaboration.

Key Risks

• v0.1.0 APIs will change -- early adoption risk
• Small team, grant-dependent funding
• Rust-to-React-Native integration is non-trivial
• No production deployments to reference
• Security audit status for encryption crate is unclear

Minimal Implementation Plan

1. Evaluate p2panda crates in isolated Rust environment (1 week)
2. Build Rust FFI bridge for React Native using uniffi (2-3 weeks)
3. Implement basic feed creation and signing using p2panda-core (1 week)
4. Implement local storage using p2panda-store (1 week)
5. Build minimal BLE transport separately (4-6 weeks, see Option 3)
6. Wire p2panda-sync over BLE transport for feed replication (2-3 weeks)
7. Integrate p2panda-encryption for group/audience encryption (2-3 weeks)

Option 5: Reticulum / LXMF

reticulum.network | GitHub

Overview

Reticulum is a Python-based cryptography-first networking stack for building mesh networks over any transport (LoRa, packet radio, WiFi, serial, I2P, TCP/IP). LXMF (Lightweight Extensible Message Format) is a delay-tolerant message transfer protocol built on top of Reticulum. Sideband is an LXMF messaging client.

Key Strengths

• Truly transport-agnostic -- works over LoRa, BLE (via RNode firmware), WiFi, serial, anything
• Strong community momentum -- Sideband saw use in real-world protest scenarios
• Interoperable ecosystem: Sideband, Nomad Network, and MeshChat all communicate via LXMF
• Fully open source with an active solo maintainer (markqvist)

iOS Status

Sideband iOS is in beta via Apple TestFlight. BLE support on iOS uses custom RNode firmware, not direct phone-to-phone BLE. This is a significant limitation: Reticulum's BLE model assumes external hardware (LoRa radios, RNodes) rather than smartphone BLE chips directly.

Assessment for Our Use Case

Feasibility Score: 1/5

Time-to-Prototype: N/A for our use case

Reticulum's architecture fundamentally targets hardware-mediated mesh networking (LoRa radios, packet radio), not smartphone-to-smartphone BLE. Adapting it would mean rewriting the transport layer, at which point you've lost the benefit of building on Reticulum.

iOS Viability: Poor

Requires external hardware. No direct phone-to-phone BLE on iOS.

Community Alignment: Low

Different target audience (ham radio operators, hardware mesh enthusiasts). Our smartphone-first, proximity social use case does not align.

Key Risks

• Fundamental architectural mismatch (hardware-first vs. smartphone-first)
• Python runtime on mobile adds significant overhead
• Solo maintainer risk

Option 6: Veilid

veilid.com | GitLab

Overview

Veilid is a Rust-based peer-to-peer application framework released by the Cult of the Dead Cow at DEF CON 31 (August 2023). It provides an encrypted, anonymous routing network similar to Tor but designed for application development. VeilidChat is a proof-of-concept messaging app built with Flutter + Veilid core.

Architecture

• Rust core (veilid-core) with FFI bindings to Flutter (veilid-flutter), Python, and WASM
• Nodes discover each other via a DHT-based private routing table
• Communication is authenticated, end-to-end encrypted (XChaCha20-Poly1305, Curve25519, BLAKE3)
• Supports UDP and TCP transport
• Platform support: Linux, macOS, Windows, Android, iOS, Web

Assessment for Our Use Case

Strengths: Rust core is cross-platform and high-performance. Flutter integration is proven (VeilidChat exists on Android). Strong cryptographic foundation. Privacy-focused design aligns with our values.

Critical gap: Veilid is an internet-based overlay network. It routes packets through the Veilid network (similar to Tor). There is no BLE transport and no offline/proximity capability. Veilid requires internet connectivity to function -- the DHT, routing tables, and node discovery all depend on an IP network.

This is a fundamental architectural mismatch with our offline-first requirement.

Feasibility Score: 2/5

Time-to-Prototype: 2-3 months (for internet-based messaging)

VeilidChat already demonstrates this. But adding BLE/offline would require building an entirely new transport layer for Veilid, which the project does not currently support.

iOS Viability: Good (for internet-based use)

Flutter + Rust via FFI works well on iOS. VeilidChat is available on Android (Google Play, updated August 2025). iOS support exists in the framework.

Community Alignment: Moderate

Privacy goals align, but Veilid's internet-overlay model is fundamentally different from our offline-first model.

Key Risks

• No offline/BLE transport -- would need to be built from scratch
• Relatively early project, community still growing
• Adding BLE transport to Veilid's routing model is architecturally non-trivial
• VeilidChat is explicitly described as a technology demonstration, not production software

Option 7: BitChat (Emerging)

bit-chat.xyz | GitHub

Overview

BitChat launched in July 2025 by Jack Dorsey. It is an open-source peer-to-peer messaging app using BLE mesh networking for offline communication, with Nostr as an optional internet transport. It uses the Noise Protocol Framework for BLE encryption and X25519 + AES-256-GCM for key exchange.

Notable Characteristics

• BLE mesh with up to 7 hops
• Ephemeral messaging (messages in device memory only by default)
• No accounts, no registration, no phone numbers
• Dual transport: BLE mesh (offline) + Nostr (online)
• Saw real adoption (70,000 downloads in Madagascar during protests, September 2025)
• iOS available via TestFlight

Critical Concerns

Security researchers have found critical vulnerabilities in BitChat shortly after launch. Dorsey added a disclaimer stating the app should not be relied upon for security. The project has been described as suffering from insufficient security review.

Assessment

BitChat validates the UX model (BLE mesh chat without accounts) and demonstrates real-world demand. However, it is a messaging app, not a social platform, and its security posture is immature. Its codebase could be useful as a reference for BLE mesh patterns but should not be built upon directly.

Feasibility Score: 2/5 (as a foundation)

The codebase is too young and security-unaudited to build on. Useful as a UX and architecture reference.

Option 8: Offline Protocol Mesh SDK (Emerging)

docs.offlineprotocol.com

Overview

A React Native SDK providing offline-first mesh networking with:

• BLE, WiFi Direct, and Internet transport with automatic switching
• Cluster-based mesh architecture (devices form clusters, bridges connect clusters)
• Rust core for message routing and reliability
• MLS engine for end-to-end encryption
• BLE Manager for scanning and advertising

Assessment

This is the most architecturally aligned off-the-shelf option for our transport layer. It solves the hardest problems (cross-platform BLE, transport switching, mesh routing) in a React Native-compatible package with a Rust core. However:

• Maturity and production-readiness are unclear
• Licensing and long-term support model unknown
• Closed-source or limited documentation may restrict customization
• Does not include social feed / data layer functionality

Feasibility Score: 3/5 (needs evaluation)

Requires hands-on evaluation of maturity, licensing, and iOS reliability before committing.

Comparative Summary

*Offline Protocol prototype time assumes their SDK works as documented.

Recommendation

Primary Strategy: Layered Hybrid Approach

No single project satisfies all requirements. The recommended approach combines projects at different layers:

┌──────────────────────────────────────────────┐
│  React Native Application                     │
├──────────────────────────────────────────────┤
│  Social/Feed Layer                            │
│  p2panda-core + p2panda-encryption            │
│  (append-only feeds, MLS group encryption,    │
│   CRDT conflict resolution)                   │
├──────────────────────────────────────────────┤
│  Sync Engine                                  │
│  p2panda-sync                                 │
│  (set reconciliation over any transport)      │
├──────────────────────────────────────────────┤
│  Transport Layer                              │
│  Phase 1: Custom BLE (react-native-ble-plx)   │
│  Phase 2: Evaluate Offline Protocol Mesh SDK  │
│  Phase 3: WiFi Direct escalation (Android)    │
│  Phase 4: Tor relay (opt-in online)           │
├──────────────────────────────────────────────┤
│  Crypto Foundation                            │
│  Signal Protocol (libsignal-ts) for 1-to-1    │
│  p2panda-encryption (MLS) for groups          │
└──────────────────────────────────────────────┘

Why This Combination

p2panda for data + encryption: Its append-only log model, MLS-based group encryption, transport-agnostic sync, and CRDT conflict resolution are precisely what our social feed layer needs. The Rust foundation compiles to both platforms. The modular crate design means we can adopt incrementally.

Custom BLE transport initially, with migration path: Starting with react-native-ble-plx gives maximum control over iOS background BLE workarounds. The Offline Protocol Mesh SDK should be evaluated in parallel -- if it proves mature and well-licensed, it could replace the custom BLE layer in Phase 2.

Signal Protocol for 1-to-1 messaging: Battle-tested, well-understood, and available as a TypeScript library for React Native. Use it for direct messages where Double Ratchet forward secrecy is critical.

Not Berty/Wesh because: Despite being the most complete single solution, the IPFS dependency adds unnecessary complexity for offline-first, the gomobile bindings create debugging challenges, and the binary size overhead is substantial. However, Berty's BLE transport code (especially their iOS Multipeer Connectivity and cross-platform BLE work) should be studied as reference implementations.

Not Briar because: No iOS path and JVM-only codebase are disqualifying constraints.

Phased Implementation Plan

Phase 1: Trust Establishment Prototype (Weeks 1-6)

• React Native project setup with BLE and crypto dependencies
• QR code key exchange flow (works on both platforms immediately)
• NFC key exchange on Android (iOS NFC is read-only, QR fallback)
• Signal Protocol X3DH key agreement
• Local encrypted contact storage
• Deliverable: Two devices establish a contact via QR scan, derive shared secret

Phase 2: BLE Discovery + Messaging (Weeks 7-14)

• BLE advertising with rotating, unlinkable beacon IDs
• BLE scanning with background mode support (iOS: specific service UUIDs, state restoration)
• GATT-based message exchange after mutual authentication
• Store-and-forward message queue for offline delivery
• Deliverable: Contacts auto-discover each other via BLE, exchange encrypted messages

Phase 3: Feed Layer Integration (Weeks 15-22)

• Integrate p2panda-core via Rust FFI bridge (uniffi)
• Implement append-only feed creation and signing
• Implement p2panda-sync over BLE transport
• Add p2panda-encryption for audience-based feed encryption
• Deliverable: Users have social feeds that replicate to contacts via BLE proximity

Phase 4: Polish + Scale (Weeks 23-30)

• WiFi Direct escalation for bulk sync (Android-to-Android)
• Evaluate and potentially integrate Offline Protocol Mesh SDK
• Optional Tor relay for online mode
• Feed pruning/archival strategy
• Security audit of crypto integration
• Deliverable: Feature-complete prototype ready for limited testing

Build vs. Contribute Decision

Build our own app layer, using open-source components at the protocol level. Specifically:

• Use p2panda crates (data model, encryption, sync)
• Use libsignal-ts (1-to-1 encryption)
• Use react-native-ble-plx or Offline Protocol SDK (transport)
• Study Berty's BLE transport code as reference
• Contribute upstream to p2panda if we extend their crates
• Do not fork Briar or Berty -- the maintenance burden is not justified

Critical Path Items

1. iOS background BLE reliability -- this is the single biggest technical risk. Prototype early and test extensively on real iOS devices with the app backgrounded and screen locked.

2. Rust-to-React-Native bridge -- p2panda integration requires a reliable FFI bridge. Evaluate uniffi and react-native-rust-bridge early.

3. p2panda maturity -- the v0.1.0 APIs will change. Maintain a thin abstraction layer so internal API changes do not propagate through the app.

4. Sync protocol efficiency -- BLE bandwidth is limited (~1 Mbps theoretical, much less in practice). Feed sync must be highly efficient (delta encoding, set reconciliation).

Sources

• Briar Project | GitLab
• Berty Technologies | Wesh Network | weshnet GitHub
• p2panda | GitHub | Group Encryption Blog Post
• Reticulum Network | Sideband
• Veilid | VeilidChat | veilid-core docs
• BitChat | GitHub
• Offline Protocol Mesh SDK
• react-native-ble-plx
• libsignal | @privacyresearch/libsignal-protocol-typescript
• Apple CoreBluetooth Background Processing
• Berty: BLE Blog Post