Create comparison section

.gitignore

@@ -21,3 +21,4 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
+compare-waku-xmtp-libp2p.md

docs/learn/compare/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Comparisons",
+  "collapsed": false,
+  "position": 8
+}

docs/learn/compare/libp2p.md

@@ -0,0 +1,161 @@
+---
+title: Waku vs Libp2p
+hide_table_of_contents: true
+displayed_sidebar: learn
+---
+
+# Waku vs libp2p
+
+## Core Distinction
+
+**libp2p** is a general-purpose P2P networking framework providing transport, discovery, and pub/sub primitives for any decentralized application.
+
+**Waku** is a privacy-preserving messaging protocol built on top of libp2p, extending it with metadata privacy and zero-knowledge DoS protection.
+
+These protocols are complementary, Waku inherits libp2p's networking foundation and adds privacy-first messaging capabilities.
+
+## Quick Comparison
+
+| Aspect | libp2p | Waku |
+|--------|--------|------|
+| **Purpose** | General P2P infrastructure | Privacy-preserving messaging |
+| **Metadata Privacy** | None (connection patterns visible) | Strong (no-signature relay, k-anonymity) |
+| **DoS Protection** | Peer scoring only | RLN (zero-knowledge proofs) |
+| **Latency** | ~10-50ms overhead | ~500ms average |
+| **Message Size** | Transport-limited | 150KB max (4KB recommended) |
+| **Offline Delivery** | Application layer required | Built-in Store protocol (12+ hours) |
+| **Production Scale** | ETH2 (100K+ validators), IPFS | Status (200K users), RAILGUN, Waku Network (80K capacity) |
+| **Maturity** | 6+ years, battle-tested | 4+ years (v2 since 2021), production-ready |
+| **Implementations** | Go, Rust, JS, 10+ languages | Nim (reference), Go, JS, Rust (RLN) |
+
+## Privacy Architecture
+
+### libp2p Privacy Model
+- Strong transport encryption (TLS 1.3, Noise)
+- Forward secrecy through key rotation
+- **No metadata protection**: DHT queries, connection patterns, and relay routing are visible
+- GossipSub messages signed by default, exposing sender identity
+- Requires application-layer privacy additions
+
+### Waku Privacy Model
+- Same transport encryption as libp2p
+- **Strong metadata privacy**: no-signature policy prevents sender identification
+- Content topic strategies provide k-anonymity
+- **Formal privacy guarantees**: proven sender anonymity against single-node adversaries
+- **Zero-knowledge DoS protection**: Rate Limiting Nullifiers (RLN) prevent spam without revealing identity
+- First production P2P protocol achieving privacy-preserving DoS protection
+
+### Privacy Threat Model
+
+| Adversary | libp2p | Waku |
+|-----------|--------|------|
+| Casual eavesdropper | ✅ Protected (encryption) | ✅ Protected (encryption) |
+| Network-level observer | ❌ Metadata exposed | ✅ Sender anonymity preserved |
+| Compromised relay node | ❌ Can correlate traffic | ✅ Cannot identify sender |
+| Global passive adversary | ❌ No protection | ⚠️ Timing correlation possible |
+
+## When to Use Each Protocol
+
+### Choose libp2p When:
+- Building blockchain protocols or Layer 2 networks
+- Creating content-addressed storage systems
+- Need DHT-based peer discovery and routing
+- Require maximum decentralization with no service dependencies
+- Privacy is not a critical requirement
+- Proven scalability at Ethereum/IPFS scale is essential
+- Need deep customization of networking stack
+
+**Best For:** Infrastructure, blockchain nodes, content distribution, general P2P systems
+
+### Choose Waku When:
+- Privacy and sender anonymity are critical
+- Building censorship-resistant messaging
+- Need DoS protection that preserves privacy
+- Metadata protection is required (who talks to whom)
+- Can accept ~500ms latency (unsuitable for real-time)
+- Users can handle blockchain integration for RLN membership
+- Anonymous voting or governance systems
+
+**Best For:** Private messaging, crypto coordination, MEV protection, anonymous voting, decentralized social
+
+### Use Both When:
+- Building complex decentralized systems with infrastructure AND messaging needs
+- Need libp2p for blockchain/state sync + Waku for privacy-sensitive user communication
+- Want shared connection infrastructure with specialized privacy capabilities
+
+**Example:** Use libp2p for validator communication and state sync, Waku for private user messaging and coordination
+
+## Production Maturity
+
+### libp2p
+**Proven Deployments:**
+- Ethereum 2.0 (100K+ validators)
+- IPFS (tens of thousands of nodes)
+- Filecoin (7.5+ petabytes)
+- Polkadot/Substrate ecosystem
+
+**Maturity Notes:**
+- 6+ years in production
+- Comprehensive specifications and tooling
+- **Concern:** August 2025 maintenance transition for go-libp2p/js-libp2p to community maintainers
+- rust-libp2p remains well-supported (Polkadot ecosystem)
+
+### Waku
+**Proven Deployments:**
+- Status messenger (200K+ historical users)
+- RAILGUN (privacy layer used by Vitalik for 100 ETH transfer)
+- The Graph's Graphcast (indexer coordination)
+- Waku Network (80K concurrent capacity across 8 shards)
+
+**Maturity Notes:**
+- v2 production-ready since 2021
+- Complete rewrite from v1 (lessons learned)
+- Formal specifications (RFCs) and research papers
+- **Concern:** Incentivization layer incomplete (requires project-funded nodes currently)
+- Active development with expected API evolution
+
+## Key Limitations
+
+### libp2p Limitations
+- No metadata privacy (connection patterns visible)
+- No built-in spam/DoS protection beyond peer scoring
+- No message ordering guarantees
+- Requires extensive application-layer work for messaging features
+- No offline message delivery without additional storage layer
+- Vulnerable to Sybil attacks without application-layer mitigations
+
+### Waku Limitations
+- ~500ms average latency (unsuitable for real-time apps like voice/video)
+- 150KB message size limit (4KB recommended for performance)
+- Smaller ecosystem than libp2p
+- Incomplete incentivization requires running own service nodes
+- Light protocols create dependencies on service nodes
+- Current 80K capacity requires additional shards for significant growth
+- RLN doesn't eliminate spam (attackers can create multiple memberships)
+
+## Technical Requirements
+
+### libp2p Integration
+**Complexity:** Moderate to high
+- Multiple transport configuration (TCP, QUIC, WebSocket, WebRTC)
+- GossipSub tuning (20+ parameters)
+- NAT traversal setup
+- DHT configuration for peer discovery
+- Application-layer messaging features
+
+**Resources Required:**
+- Running infrastructure nodes
+- Development and maintenance costs
+- Potential relay hosting costs
+
+### Waku Integration
+**Complexity:** Moderate
+- Choose relay vs. light protocol strategy
+- RLN membership management (~$0.05/message/epoch proposed)
+- Content topic and autosharding configuration
+- Service node infrastructure (if requiring reliability)
+
+**Resources Required:**
+- RLN membership costs (blockchain-based)
+- Service node operation (for production reliability)
+- Currently relies on altruistic or project-funded operators

docs/learn/compare/xmtp.md

@@ -0,0 +1,130 @@
+---
+title: Waku vs XMTP
+hide_table_of_contents: true
+displayed_sidebar: learn
+---
+
+# Waku vs XMTP
+
+## TL;DR
+
+**Waku** = Privacy-first, permissionless, metadata protection, ~500ms latency, higher complexity
+**XMTP** = Developer-first, permissioned (5-20 nodes), fast UX, currently centralized (transitioning)
+
+**Core Tradeoff:** Privacy & decentralization (Waku) vs Performance & ease-of-use (XMTP)
+
+## Critical Technical Differences
+
+### Architecture
+
+**Waku**
+- **Network:** Permissionless P2P mesh (live since Dec 2023)
+- **Node Operation:** Anyone can run a node
+- **Current Scale:** 8 shards, ~80K user capacity, 200K+ users (Status)
+- **Privacy Model:** Metadata privacy + content encryption
+- **DoS Protection:** Rate Limiting Nullifiers (zero-knowledge proofs)
+
+**XMTP**
+- **Network:** Currently centralized (all nodes = Ephemera), transitioning to 5-20 permissioned operators
+- **Node Operation:** Selected operators only (XIP-54 criteria)
+- **Current Scale:** 2.2M+ identities, 1B+ messages, 60+ apps
+- **Privacy Model:** Content encryption only (MLS standard)
+- **DoS Protection:** Conditional deliverability (planned)
+
+### Encryption
+
+**Waku**
+- Noise Protocol Framework
+- Applications must implement encryption layer
+- Forward secrecy via key rotation
+- No quantum resistance (requires upgrade)
+
+**XMTP**
+- IETF RFC 9420 (MLS standard)
+- Automatic encryption (handled by SDK)
+- Perfect forward secrecy + post-compromise security
+- Hybrid post-quantum encryption (XWING/ML-KEM for Welcome messages)
+- NCC Group audited (Dec 2024)
+
+### Privacy & Anonymity
+
+| Aspect | Waku | XMTP |
+|--------|------|------|
+| **Content Privacy** | ✅ Encrypted | ✅ Encrypted (stronger standard) |
+| **Metadata Privacy** | ✅ Strong (no sender signatures) | ❌ Weak (centralized visibility) |
+| **Sender Anonymity** | ✅ Formal proofs | ❌ Pseudonymous (wallet-based) |
+| **IP Protection** | ⚠️ Better than most | ❌ Vulnerable (centralized) |
+| **Censorship Resistance** | ✅ Strong | ❌ Weak (small operator set) |
+
+### Performance
+
+| Metric | Waku | XMTP |
+|--------|------|------|
+| **Latency** | 500ms average | Web2-like  |
+| **Message Size** | 150KB max | 1MB max |
+| **Offline Storage** | 12+ hours (Store protocol) | Reliable node storage |
+| **Mobile Support** | Light protocols (SDK in dev) | Native SDKs (mature) |
+
+### Developer Experience
+
+**Waku**
+- **Complexity:** Moderate
+- **SDKs:** Nim, Go, JS (TypeScript)
+- **Documentation:** Comprehensive, technical
+- **Must Handle:** Encryption layer, content topics, node discovery
+
+**XMTP**
+- **Complexity:** Low
+- **SDKs:** JavaScript, Kotlin, Swift, React, React Native, Dart
+- **Documentation:** Excellent, developer-friendly
+- **Automatic:** Encryption, cross-app messaging, wallet integration
+
+### Economics
+
+**Waku**
+- Currently free
+- RLN membership cost: ~$0.05 proposed
+- Run your own infrastructure or use public nodes
+- No operator fees
+
+**XMTP**
+- Currently free
+- Fees coming with mainnet (amount TBD)
+- Hosted infrastructure (transitioning to operator set)
+- Fee model uncertain during transition
+
+## Decision Matrix
+
+### Choose Waku If You Need:
+
+- **Metadata privacy** (not just content encryption)
+- **Sender anonymity** (formal privacy guarantees)
+- **Permissionless network** (anyone can run nodes)
+- **Strong censorship resistance** (no central points of failure)
+- **Privacy-critical infrastructure** (threat model includes sophisticated adversaries)
+
+**Accept:**
+- ~500ms latency
+- Implementing your own encryption
+- Higher integration complexity
+- Running infrastructure or depending on service nodes
+
+**Use Cases:** Private transaction coordination, anonymous voting, privacy-first social networks, MEV protection, whistleblowing platforms
+
+### Choose XMTP If You Need:
+
+- **Wallet-to-wallet messaging** (EVM addresses)
+- **Fast time-to-market** (days not months)
+- **Cross-app interoperability** (60+ apps)
+- **Web2-like UX** (low latency, reliable delivery)
+- **Mature mobile SDKs** (production-ready)
+- **Automatic encryption** (no implementation required)
+
+**Accept:**
+- Current centralization (transitioning to 5-20 permissioned nodes)
+- Weak metadata privacy
+- Wallet-based pseudonymity (no anonymity)
+- Fee uncertainty during transition
+- EVM-only (for now)
+
+**Use Cases:** Crypto messaging apps, DeFi notifications, NFT marketplace chat, wallet-based social features, DAO communications

sidebars.js

@@ -139,7 +139,15 @@ const sidebars = {
         },
       ],
     },
-    "learn/waku-vs-libp2p",
+    {
+      type: "category",
+      label: "Comparisons",
+      collapsed: false,
+      items: [
+        "learn/compare/libp2p",
+        "learn/compare/xmtp",
+      ],
+    },
     "learn/glossary",
     "learn/faq",
   ],