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 | Ubiquitous |
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.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| js-libp2p | TypeScript | ~2.5k | Jan 2026 | Apache 2.0 / MIT | IPFS, Ethereum | Already in MPowerUP stack — WebRTC transport creates direct connections that can form a full mesh within a small Circle |
| peerjs | TypeScript | ~13.3k | Active 2025 | MIT | Education, hobbyist | Simpler WebRTC abstraction; useful for Toaster Chef multiplayer prototyping |
| trystero | TypeScript | ~2.5k | Active 2025–2026 | MIT | Web game / collab tools | 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, not all — either in 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 (how gracefully it survives joins/leaves), 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.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| js-libp2p | TypeScript | ~2.5k | Jan 2026 | Apache 2.0 / MIT | Ethereum, IPFS, Filecoin, Mina, Celestia | Core MPowerUP transport — provides partial mesh via Kademlia + GossipSub overlay |
| go-libp2p | Go | ~6.3k | Dec 2025 | Apache 2.0 / MIT | Ethereum consensus, Filecoin, Lotus, Polygon Edge | Reference implementation; 30+ blockchain networks in production |
| rust-libp2p | Rust | ~5.3k | Active 2025 | Apache 2.0 / MIT | Polkadot/Substrate, Iroh networking | Solidified as production-grade in 2025; adding WebTransport for browser participation |
| hyperswarm | JavaScript | ~1.3k | Active 2025 | Apache 2.0 | Pear Runtime, Keet, Mapeo | DHT-backed peer discovery + UDP hole punching; connects any two 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 (peers per round), heartbeat interval, and push / pull / push-pull mode. Research as of August 2025 demonstrates gossip achieving global agreement at one million nodes.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| GossipSub spec | Spec + multi-lang | — | v1.2 active 2025 | MIT | Ethereum consensus, IPFS, Waku, Filecoin | MPowerUP's pub/sub layer — Yjs CRDT deltas propagate through GossipSub; Circle messages ride it |
| js-libp2p | TypeScript | ~2.5k | Jan 2026 | Apache 2.0 / MIT | See above | JS runtime that MPowerUP actually executes |
| hypercore | JavaScript | ~2.8k | Active 2025 | MIT | Pear, Mapeo | Append-only log replication is gossip-adjacent — nodes replicate diffs of signed feeds |
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 participating in a Circle) and content routing (find which peer holds a particular CRDT state chunk). The tradeoff: DHT lookups add latency; mobile nodes that go offline frequently create churn that requires routing table healing.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| go-libp2p-kad-dht | Go | 1,037 pkg dependents | Published May 2026 | MIT | IPFS/Kubo, Ethereum, Filecoin | Gold-standard Kademlia; used if BNI adds a Go relay/bootstrap node |
| js-libp2p (KAD-DHT) | TypeScript | Part of js-libp2p | Jan 2026 | Apache 2.0 / MIT | IPFS browser nodes | Already MPowerUP's discovery path — js-libp2p ships Kademlia DHT for peer discovery |
| hyperdht | JavaScript | Part of hyperswarm | Active 2025 | Apache 2.0 | Pear, Hyperswarm | Hyperswarm's underlying DHT; topic-based discovery with built-in hole punching; simpler API than Kademlia |
| iroh | Rust | ~8.35k | Apr 2026 | Apache 2.0 / MIT | Beeper | Pivoted from IPFS compatibility to a minimal "dial by key" stack; maintains own DHT; highly active; explicitly mobile-aware |
Category 5 — Pub/Sub over P2P¶
Publish/subscribe over P2P decouples message producers from consumers: nodes subscribe to topics and published messages propagate to all subscribers without knowing who they are. The dominant implementation in the libp2p ecosystem is GossipSub — a structured mesh of D peers per topic (reliability) plus gossip-based metadata propagation (scalability). Floodsub (the predecessor) broadcast to all peers — simpler but far more bandwidth-intensive. Waku is a production messaging layer built on GossipSub with added privacy features: a store protocol for offline message retrieval and RLN (Rate Limiting Nullifiers) for spam protection.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| GossipSub (js-libp2p) | TypeScript | ~2.5k | Jan 2026 | Apache 2.0 / MIT | Ethereum consensus, IPFS, MPowerUP | Current MPowerUP pub/sub — Yjs syncs CRDT deltas over GossipSub topics |
| js-waku | TypeScript | ~180 | Active 2025 | MIT | Status messaging app, Railgun | Privacy-preserving GossipSub extension with offline store — the store protocol solves the "message while offline" problem for Circles |
| nwaku | Nim | Moderate | Active 2025 | MIT / Apache 2.0 | Status network backbone | Reference Waku node; runs relay infrastructure MPowerUP could connect to instead of operating its own |
| synapse | Python | ~12k | Active 2025 | AGPL 3.0 | Element, Beeper, German govt, NHS | Not pure P2P — federated. Included because 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 messages it missed 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 will 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 will merge cleanly without conflict resolution. Two dominant variants: operation-based CRDTs (ship the operations; requires exactly-once delivery) and state-based CRDTs (ship the full or delta state; idempotent but can be large). Yjs uses a hybrid: operation logs with state vector comparison for efficient catch-up. 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). This makes large CRDT documents viable on mobile.
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| yjs | TypeScript | ~19.9k | Jan 2026 | MIT | Notion (partial), Linear, Tiptap, Liveblocks | Already MPowerUP's CRDT layer — 900k+ weekly npm downloads; y-libp2p provider integrates Yjs over GossipSub |
| automerge | Rust + WASM / JS / Swift / Kotlin | ~17.5k | Aug 2025 (v3.0) | MIT | Ink & Switch, early production | JSON-tree model vs Yjs's document model; better for typed structured data like MPowerUP help requests; 10× memory improvement in v3.0 |
| loro-dev/loro | Rust + WASM | ~5.3k | Active 2025–2026 | MIT | Roomy, Latch.bio | Newest serious contender; movable-tree + rich-text CRDTs; Rust core with Swift bindings; 1.0 released 2024 |
| orbitdb | TypeScript | ~8.7k | Active 2025 | MIT | IPFS-ecosystem apps | Merkle-CRDT database on Helia + libp2p; v2.1 released; presented at FOSDEM 2026 |
| gun | JavaScript | ~18.9k | Active 2025 | Zlib | Various DApps | High star count; single maintainer; maintenance concerns; less suitable for security-sensitive production use |
| earthstar | TypeScript | ~875 | Mar 2025 | LGPL 3.0 | Small community | Explicitly designed for small trusted groups with offline-first sync — philosophically closest to MPowerUP Circles. 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 their 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 where operators are compensated (Waku's RLN, Iroh's relay infrastructure).
Scaling characteristics
| 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 |
Implementations
| Project | Lang | Stars | Last Active | License | Notable Users | BNI Relevance |
|---|---|---|---|---|---|---|
| libp2p Circuit Relay v2 | TypeScript | Part of js-libp2p | Jan 2026 | Apache 2.0 / MIT | IPFS browser nodes, Ethereum | Already in MPowerUP — Circuit Relay handles mobile nodes behind carrier-grade NAT |
| hyperswarm | JavaScript | ~1.3k | Active 2025 | Apache 2.0 | Pear, Keet, Mapeo | DHT discovery + UDP hole punching + relay fallback in one library; simpler API than raw libp2p |
| hypercore | JavaScript | ~2.8k | Active 2025 | MIT | Pear, Mapeo | Mapeo (used by indigenous communities for offline land mapping) is the strongest analogical precedent for BNI's use case profile [CONFIRMED] |
| nostr | Spec + multi-lang | ~11.3k | Apr 2026 | Public Domain | Damus, Primal, Amethyst | Relay-based (not pure P2P); relays act as superpeers; NIP-17 provides sealed-sender DMs; Nostr relays could serve as lightweight rendezvous for MPowerUP Circle bootstrapping without a BNI-operated server [HYPOTHESIS] |
| trystero | TypeScript | ~2.5k | Active 2025–2026 | MIT | Web multiplayer, collab tools | Uses public infrastructure (BitTorrent DHT, Nostr relays, IPFS, MQTT) as signaling, then goes direct WebRTC — pragmatic serverless hybrid |
| iroh | Rust | ~8.35k | Apr 2026 | Apache 2.0 / MIT | Beeper | "Dial by key not IP"; built-in hole punching + QUIC + relay; production-tested for mobile; 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. 8.35k stars by April 2026 signals strong community interest.
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 — which doubles latency and requires 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]
See Also¶
- P2P & Decentralized Tech — IPLD, libp2p, Helia reference links
- MPowerUP P2P Reference
- ADR-001: MPowerUP Graph Database
- Red Team — MPowerUP