Modern P2P Topologies & Scaling Methods¶

Research date: May 2026 | Scope: Open-source only; all star counts approximate as of May 2026.

A reference survey of modern peer-to-peer network topologies for BNI engineering decisions — primarily MPowerUP's Circle architecture and future phases. Seven topology/protocol categories are covered, each with leading open-source implementations, community adoption signals, and explicit notes on BNI project relevance.

Per the Epistemic Honesty directive: star counts and last-active dates are [CONFIRMED] from sources collected May 2026 but may lag GitHub's live state by days to weeks. Architecture recommendations are [HYPOTHESIS] unless otherwise marked.

Quick-Reference Table¶

Project	Category	Stars	Last Active	License	Production Use
js-libp2p	Overlay / Gossip / DHT / Relay	~2.5k	Jan 2026	Apache 2.0 / MIT	IPFS, Ethereum browsers
go-libp2p	Same	~6.3k	Dec 2025	Apache 2.0 / MIT	Ethereum consensus, Filecoin, Celestia
rust-libp2p	Same	~5.3k	Active 2025	Apache 2.0 / MIT	Polkadot, Iroh
yjs/yjs	CRDT	~19.9k	Jan 2026	MIT	Tiptap, Liveblocks, MPowerUP
automerge/automerge	CRDT	~17.5k	Aug 2025 (v3.0)	MIT	Ink & Switch; growing
loro-dev/loro	CRDT	~5.3k	Active 2025	MIT	Roomy; early production
holepunchto/hypercore	Overlay / Log	~2.8k	Active 2025	MIT	Pear, Mapeo
holepunchto/hyperswarm	DHT / Relay	~1.3k	Active 2025	Apache 2.0	Pear, Keet, Mapeo
n0-computer/iroh	DHT / Relay / Transport	~8.35k	Apr 2026	Apache 2.0 / MIT	Beeper
orbitdb/orbitdb	CRDT DB	~8.7k	Active 2025	MIT	IPFS ecosystem
amark/gun	CRDT	~18.9k	Active 2025	Zlib	Various DApps
earthstar-project/earthstar	CRDT / Sync	~875	Mar 2025	LGPL 3.0	Small community
waku-org/js-waku	Pub/Sub	~180	Active 2025	MIT	Status app
nostr-protocol/nostr	Relay / Pub	~11.3k	Apr 2026	Public Domain	Damus, Amethyst
matrix-org/synapse	Federated	~12k	Active 2025	AGPL 3.0	Element, German Govt
peers/peerjs	Full Mesh / WebRTC	~13.3k	Active 2025	MIT	Education, prototypes
dmotz/trystero	Full Mesh / Hybrid	~2.5k	Active 2025–2026	MIT	Web multiplayer
socket.io	⚠️ NOT P2P	~61k	Active 2026	MIT	Client-server; listed only to explicitly exclude it

The implementation links above are not repeated in the per-category sections below; each category instead summarizes scaling characteristics and the BNI-relevant standouts.

Category 1 — Full Mesh P2P¶

Every node maintains a direct connection to every other node. Message latency is minimal (single hop) and there is no single point of failure, but connection count grows O(n²): 10 nodes require 45 connections, 50 nodes require 1,225. Full mesh is practical only for small, stable groups (2–10 nodes). On mobile, persistent socket keepalives drain battery regardless of activity. The model maps naturally to MPowerUP's small trusted Circles where every-member reachability is desirable.

Dimension	Value
Node count sweet spot	2–8 (hard ceiling ~12 before UX degrades)
Bandwidth per node	O(n) uploads — each node sends to all peers
Partition tolerance	High within the mesh; any surviving node has full state
Latency	Single-hop; lowest possible
Mobile / battery	Partial — acceptable for small Circles; prohibitive at >12 nodes

BNI-relevant implementations: js-libp2p (already in the MPowerUP stack — WebRTC transport forms a full mesh within a small Circle); peerjs (simpler WebRTC abstraction, useful for Toaster Chef multiplayer prototyping); trystero (serverless WebRTC matchmaking over BitTorrent / Nostr / MQTT / IPFS — builds full-mesh sessions with no signaling server; relevant to offline-resilient Circle formation).

Note

Full mesh beyond ~6 participants in a WebRTC session is well-documented to be impractical for video (CPU/bandwidth). For data-only channels the ceiling is higher, but n−1 keepalives still accumulate real battery cost on mobile. [CONFIRMED]

Category 2 — Partial Mesh / Overlay Networks¶

Each node connects to a subset of peers — either a structured overlay (DHT, where position encodes routing) or an unstructured overlay (random/heuristic connectivity). Partial mesh is the operational reality of almost every real-world P2P system at scale. libp2p itself is a partial mesh: each node maintains a Kademlia routing table and a small GossipSub mesh (typically D=6 peers per topic). Key design axes: degree (peers per node), churn handling, and NAT traversal.

[CONFIRMED] As of the libp2p 2025 Annual Report, libp2p powers 30+ major blockchain networks and secures/moves >$100B in value collectively. The project grew from 7 to 10 active implementations in 2025.

Dimension	Value
Node count sweet spot	10 → millions
Bandwidth per node	O(log n) for structured; O(D) fixed degree for GossipSub
Partition tolerance	Moderate to high; depends on redundancy factor
Latency	O(log n) hops for structured; variable for unstructured
Mobile / battery	Yes — libp2p AutoNAT + relay reduce keepalive overhead

BNI-relevant implementations: js-libp2p (core MPowerUP transport — partial mesh via Kademlia + GossipSub); go-libp2p / rust-libp2p (reference implementations; 30+ blockchain networks in production; rust-libp2p adding WebTransport for browser participation); hyperswarm (DHT-backed discovery + UDP hole punching, connecting peers by topic hash — strong candidate for Circle peer discovery).

Category 3 — Gossip / Epidemic Protocols¶

Gossip (epidemic) protocols propagate state or messages by having each node periodically select a random subset of neighbors and share what it knows. Information is "infected" probabilistically; it reaches the full network in O(log n) rounds and is highly resilient to node failure or churn. Gossip is eventually consistent — no guaranteed delivery order; partitioned nodes converge slowly on reconnect. Key parameters: fanout, heartbeat interval, and push / pull / push-pull mode. Research as of August 2025 demonstrates gossip achieving global agreement at one million nodes.

Dimension	Value
Node count sweet spot	10 → 1,000,000+ (probabilistic guarantee)
Bandwidth per node	O(fanout) per round — constant regardless of network size
Partition tolerance	High — partitioned segments re-sync on reconnect
Latency	O(log n) rounds × heartbeat interval; not real-time
Mobile / battery	Yes — heartbeat interval is tunable; longer = less battery, slower convergence

BNI-relevant implementations: GossipSub (MPowerUP's pub/sub layer — Yjs CRDT deltas and Circle messages ride it); js-libp2p (the JS runtime MPowerUP actually executes); hypercore (append-only log replication is gossip-adjacent).

GossipSub v1.2 improvements

GossipSub v1.1+ adds Peer Exchange (PX) and score-based peer selection, dramatically reducing Sybil and eclipse attack surface vs. naive gossip. v1.2 adds IDONTWANT message aggregation to cut bandwidth for large messages. [CONFIRMED]

Category 4 — Distributed Hash Tables (DHT)¶

DHTs provide structured peer lookup by mapping both content and peers onto a common keyspace. The classic Kademlia algorithm routes a lookup in O(log n) hops via XOR-distance k-bucket routing tables. S/Kademlia adds signed node IDs and parallel disjoint lookups to resist Sybil attacks. DHTs serve two functions for MPowerUP: peer discovery (find nodes in a Circle) and content routing (find which peer holds a CRDT state chunk). Tradeoff: lookups add latency, and mobile nodes that go offline frequently create churn that requires routing-table healing.

Dimension	Value
Node count sweet spot	100 → 10,000,000+ (IPFS DHT spans millions of nodes)
Bandwidth per node	O(log n) per lookup; routing table maintenance is low overhead
Partition tolerance	Moderate — DHT heals slowly on reconnect
Latency	2–10 hops × RTT; suitable for bootstrapping, not real-time
Mobile / battery	Partial — routing table maintenance creates background chatter; tunable

BNI-relevant implementations: go-libp2p-kad-dht (gold-standard Kademlia; for a Go relay/bootstrap node); js-libp2p KAD-DHT (already MPowerUP's discovery path); hyperdht (topic-based discovery with built-in hole punching; simpler API than Kademlia); iroh (minimal "dial by key" stack, own DHT, highly active, explicitly mobile-aware).

Category 5 — Pub/Sub over P2P¶

Publish/subscribe over P2P decouples producers from consumers: nodes subscribe to topics and published messages propagate to all subscribers without knowing who they are. The dominant libp2p implementation is GossipSub — a structured mesh of D peers per topic (reliability) plus gossip-based metadata propagation (scalability). Floodsub (predecessor) broadcast to all peers — simpler but far more bandwidth-intensive. Waku is a production messaging layer built on GossipSub with a store protocol for offline message retrieval and RLN (Rate Limiting Nullifiers) for spam protection.

Dimension	Value
Node count sweet spot	GossipSub: 10 → 100,000+ (tested on Ethereum mainnet)
Bandwidth per node	Fixed fanout per topic (D=6 by default); independent of subscriber count
Partition tolerance	High — messages re-propagate when partitioned segments reconnect
Latency	Sub-second within a well-connected mesh for small payloads
Mobile / battery	Yes — Waku's resource-restricted node mode explicitly designed for mobile

BNI-relevant implementations: GossipSub (js-libp2p) (current MPowerUP pub/sub — Yjs syncs CRDT deltas over GossipSub topics); js-waku (privacy-preserving GossipSub extension with an offline store — solves the "message while offline" problem for Circles); nwaku (reference Waku node MPowerUP could connect to rather than operating its own); synapse (federated, not pure P2P — included because the Matrix room model maps well to Circles and MegOlm provides proven E2E encryption at scale).

Waku store protocol

Waku's store protocol allows a reconnecting offline node to retrieve missed messages by querying a Waku relay node — without those messages touching a centralized BNI server. [CONFIRMED] This directly addresses MPowerUP's relay gap. [HYPOTHESIS] Integration effort estimated at 1–2 weeks based on documented Waku examples; actual effort [UNKNOWN].

Category 6 — CRDTs over P2P¶

Conflict-free Replicated Data Types guarantee convergence: any two nodes that have seen the same set of operations arrive at the same state, regardless of application order. This makes CRDTs the natural sync primitive for offline-first mobile apps — a device that disconnects for a day, mutates locally, and reconnects merges cleanly without conflict resolution. Two dominant variants: operation-based (ship the operations; requires exactly-once delivery) and state-based (ship full or delta state; idempotent but can be large). Yjs uses a hybrid. As of 2025–2026 the field has converged on delta-state CRDTs with hybrid logical clocks as the bandwidth-efficient production approach.

[CONFIRMED] Automerge 3.0 (August 2025) reimplemented its Rust core to use compressed columnar storage, achieving 10× memory reduction (700 MB → 1.3 MB for a Moby Dick–sized document), making large CRDT documents viable on mobile.

Dimension	Value
Node count sweet spot	2–50 for rich-document CRDTs; state-based variants scale further
Bandwidth per node	Delta-state: incremental; state-based: proportional to doc size
Partition tolerance	Excellent — the core value proposition
Latency	Local writes instant; sync latency = transport latency
Mobile / battery	Yes — Automerge 3.0's memory reduction and Yjs binary encoding both proven on mobile

BNI-relevant implementations: yjs (already MPowerUP's CRDT layer; y-libp2p provider integrates Yjs over GossipSub); automerge (JSON-tree model, better for typed structured data like MPowerUP help requests; 10× memory improvement in v3.0); loro (newest serious contender — movable-tree + rich-text CRDTs, Rust core with Swift bindings); orbitdb (Merkle-CRDT database on Helia + libp2p); gun (high stars but single maintainer / maintenance concerns — less suitable for security-sensitive production); earthstar (designed for small trusted groups with offline-first sync — philosophically closest to MPowerUP Circles, but small community and LGPL are risk signals).

LGPL and React Native

Earthstar's LGPL 3.0 license has documented compatibility issues with React Native bundling (static linking requirements). Do not adopt as a primary MPowerUP dependency without legal review. [CONFIRMED]

Category 7 — Hybrid / Superpeer Topologies¶

Hybrid topologies combine structured routing efficiency with relay infrastructure reach. In libp2p this manifests as Circuit Relay v2 (relay nodes forward traffic for NAT-restricted nodes), AutoNAT (nodes self-discover reachability), and hole punching (two NAT-restricted nodes coordinate via a relay to establish a direct connection). For mobile-first apps the practical topology is: always attempt direct WebRTC via hole punching (cheapest); fall back to relay if hole punching fails (reliable but relay bears cost). The 2025–2026 research frontier adds incentivized relay networks (Waku's RLN, Iroh's relay infrastructure).

Dimension	Value
Node count sweet spot	Unlimited — relay infrastructure scales independently
Bandwidth per node	Direct path: O(1) after connection; relayed: relay node bears O(n_relayed) cost
Partition tolerance	High — relay provides fallback when direct fails
Latency	Direct: single-hop; relayed: 2-hop with relay RTT added
Mobile / battery	Yes — hole punching reduces need for persistent relay connections

BNI-relevant implementations: libp2p Circuit Relay v2 (already in MPowerUP — handles mobile nodes behind carrier-grade NAT); hyperswarm (DHT discovery + UDP hole punching + relay fallback in one library); hypercore — Mapeo (used by indigenous communities for offline land mapping) is the strongest analogical precedent for BNI's use-case profile [CONFIRMED]; nostr (relay-based; relays act as superpeers; NIP-17 sealed-sender DMs; relays could serve as lightweight rendezvous for Circle bootstrapping without a BNI-operated server [HYPOTHESIS]); trystero (uses public infrastructure as signaling, then goes direct WebRTC); iroh ("dial by key not IP"; built-in hole punching + QUIC + relay; most mobile-aware transport in the field).

BNI Synthesis¶

Topology fit for MPowerUP Circles¶

MPowerUP's Circle model — trusted groups of ~5–50 members, offline-first, mobile — maps to a layered three-tier architecture that is already partially in place:

Tier 1 — Direct peer connections: For active Circles with members online simultaneously, libp2p's WebRTC transport enables direct connections. For small active groups (≤8 members) this forms a practical full mesh — every message delivers in one hop. This is the current baseline.

Tier 2 — GossipSub overlay for async propagation: For larger Circles, or when only some members are online, GossipSub propagates Yjs CRDT delta updates across whichever subset is reachable. Offline members accumulate a state delta gap and sync on reconnect — exactly what Yjs's provider model handles. Key tuning lever: the GossipSub heartbeat interval. Longer intervals (30s vs. 1s) dramatically reduce battery drain with minimal impact for small Circles where latency tolerance is seconds, not milliseconds.

Tier 3 — Relay / bootstrap infrastructure: Mobile nodes behind carrier-grade NAT cannot accept inbound connections. libp2p Circuit Relay v2 handles this, but requires at least one publicly reachable relay node. BNI has no relay infrastructure today — this is the most critical operational gap for Phase 2 (location safety), where reliability is safety-critical. Options in order of infrastructure commitment:

Use Waku public relays (zero BNI infrastructure; Waku store protocol also solves offline message retrieval) [HYPOTHESIS]
Deploy a single lightweight go-libp2p or Iroh relay node
Use Trystero's public rendezvous infrastructure (BitTorrent DHT / Nostr relays) for signaling only, then go direct WebRTC

What the 2025–2026 research community has converged on¶

Based on FOSDEM 2026 (Local-First track) and the Local-First Conference (July 2026, Berlin):

CRDTs are no longer controversial. The debate has shifted from "OT vs. CRDT" to "where does the sync abstraction belong in the stack?" MPowerUP's placement (Yjs at the data layer, GossipSub at the transport layer) matches the emerging consensus.
Delta-state CRDTs with hybrid logical clocks are the bandwidth-efficient production approach. Yjs already uses this model; Automerge 3.0 improved it significantly.
Memory and mobile performance are solved at the CRDT library level. Automerge 3.0's 10× memory reduction and Loro's mobile bindings mean large CRDT documents are viable on mobile. Remaining challenge: transport-layer battery drain, not library memory.
Gossip + CRDT is the de facto standard for small-group local-first apps. Every serious production deployment surveyed — Mapeo, Berty, OrbitDB, Waku/Status — uses some variant of gossip for propagation and CRDTs for merge semantics. MPowerUP's architecture is well-aligned.
Iroh is the project to watch for mobile networking. "Dial by key, not by IP," built-in hole punching, QUIC transport, and an active mobile roadmap position it as a potential successor or complement to js-libp2p for mobile contexts.

Open problems BNI should track¶

NAT traversal is not solved for all mobile networks

libp2p hole punching works for most residential NATs but fails for symmetric NATs (common on some mobile carrier networks). When hole punching fails, traffic must route through a relay — doubling latency and requiring relay infrastructure. BNI has no relay nodes today. [CONFIRMED from libp2p documentation]

Keepalive battery drain is underappreciated

Socket-based P2P keepalives are required to maintain connection state through NAT mappings. A fully connected 8-member Circle means each device maintains 7 keepalive connections. At a 25-second keepalive interval, a device sends ~24,000 keepalive packets per day — measurable but manageable. The risk is that uninstrumented keepalive behavior goes unnoticed until user complaints arrive. [CONFIRMED — documented by Tailscale engineers and WebRTC mobile battery research]

CRDT history growth is an open problem at long time horizons

CRDTs accumulate operation history indefinitely. A Yjs document edited for a year may carry megabytes of tombstoned operations. Garbage collection requires coordination across all peers — you cannot GC an operation an offline peer hasn't seen yet. For MPowerUP, help requests that accumulate months of status-change CRDTs may eventually hit this. No production-solved solution exists for fully serverless CRDT GC. [CONFIRMED — documented in CRDT literature]

Sybil resistance: MPowerUP's Circle model has a natural mitigation — Circles are invite-only with did:key identity, closing the Sybil attack surface at the application layer. The DHT layer still needs hardening (libp2p S/Kademlia extensions help), but the social layer provides primary protection. [HYPOTHESIS — has not been formally red-teamed for the Phase 2 location-safety feature]

Recommended evaluations for MPowerUP Phase 2¶

Priority 1 — Solve the relay gap (pre-Phase 2): Evaluate integrating js-waku as an offline message store. The specific feature needed is Waku's store protocol. This is an integration, not a replacement — js-waku runs on top of libp2p and is compatible with the existing GossipSub transport. [HYPOTHESIS] Integration effort: 1–2 weeks based on documented examples; actual effort [UNKNOWN].

Priority 2 — Iroh for mobile transport spike: For location safety, reliability is safety-critical. A 1–2 week spike to test Iroh's React Native FFI path (via Expo native modules or Turbo Modules) would resolve whether the Rust core can be bound to the current Expo-managed workflow. Do not commit to Iroh without this validation. [HYPOTHESIS — Iroh Rust core can be bound to React Native; UNKNOWN whether Expo managed workflow supports it]

Priority 3 — Automerge 3.0 vs. Yjs for structured data: MPowerUP's help requests are typed records, not free text — a better fit for Automerge's JSON-tree model than Yjs's document model. Evaluation criterion: can Automerge's WASM bundle run from React Native/Expo without performance regression, and does its schema model simplify Phase 2 location-sharing data structures? Automerge has Kotlin and Swift bindings that may outperform WASM. [HYPOTHESIS]

Priority 4 — Monitor Loro: Loro is 18–24 months newer than both Yjs and Automerge 3.0. Its movable-tree CRDT and Swift bindings are production-quality. Track its React Native support progress; it may be the right CRDT library for Phase 3+ when the data model becomes more complex. Not yet ready to adopt as primary. [UNKNOWN: Loro React Native / Expo support status as of May 2026]