diff --git a/readme-devlog.org b/readme-devlog.org
index 778b5b3..98e6a7a 100644
--- a/readme-devlog.org
+++ b/readme-devlog.org
@@ -121,3 +121,168 @@ synced document database that we use to manage feeds.
   - sends invitation+registration token to server
   - added to the realm
     - go to subsequent runs
+
+* WebRTC Full-Mesh Implementation Plan
+
+** Overview
+
+Implement a full-mesh WebRTC system where every client in a realm establishes direct
+peer-to-peer connections with all other clients. The existing WebSocket infrastructure
+serves as the signaling channel, leveraging the newly refactored broadcast protocol.
+
+** Architecture Components
+
+*** Protocol Extensions (src/common/protocol/messages-rtc.js)
+
+Create new WebRTC message schemas:
+- rtc.offer - SDP offer with connectionId
+- rtc.answer - SDP answer with connectionId
+- rtc.ice-candidate - ICE candidate exchange
+- rtc.peer-state - Connection state updates
+- rtc.request-connection - Initiate connection with polite flag
+- rtc.peer-joined - Server message when peer joins (includes member list)
+- rtc.peer-left - Server message when peer leaves
+
+*** Server-Side Updates
+
+**** broadcastToRealm Function Enhancement
+
+Update the function signature to:
+- Take complete messages instead of payloads
+- Add skipSelf flag (default true)
+- For rtc.peer-joined, set skipSelf=false to include sender
+
+**** Handler Updates (handler-realm.js)
+
+- On client join: Broadcast rtc.peer-joined to ALL members (including self)
+- On client leave: Broadcast rtc.peer-left to remaining members
+- Existing broadcast mechanism handles WebRTC signaling perfectly
+
+*** WebRTC Utilities (src/common/webrtc.js)
+
+Core utilities for WebRTC:
+- RTC_CONFIG with STUN servers
+- DATA_CHANNEL_CONFIG for reliable messaging
+- PerfectNegotiation class for glare-free negotiation
+- ConnectionHealthMonitor for ping/pong health checks
+
+*** Client WebRTC Manager (src/client/webrtc-manager.js)
+
+Main orchestrator that:
+- Manages all peer connections
+- Handles incoming RTC messages
+- Routes signaling between peers
+- Emits events for UI updates
+- Provides public API for sending messages
+
+*** Client Peer Connection (src/client/peer-connection.js)
+
+Individual peer connection handler:
+- RTCPeerConnection lifecycle management
+- Perfect negotiation implementation
+- Data channel setup and messaging
+- Health monitoring with ping/pong
+- Automatic reconnection with exponential backoff
+- Connection state tracking
+
+*** UI Components
+
+**** PeerList Component
+- Shows all realm members
+- Connection status indicators
+- Real-time state updates
+
+**** MessageInterface Component
+- Send messages via WebRTC or server broadcast
+- Display incoming messages
+- Mode selection (P2P vs server relay)
+
+** Connection Flow
+
+*** Initial Join
+1. Client authenticates via WebSocket
+2. Server sends realm.status
+3. Server broadcasts rtc.peer-joined to ALL members
+4. Client sees own join message with member list
+5. Client initializes WebRTCManager
+6. Client connects to all existing members
+
+*** Peer-to-Peer Connection
+1. Initiator creates RTCPeerConnection (polite=true)
+2. Creates data channel, triggering negotiation
+3. Sends offer via realm.broadcast to target peer
+4. Target creates RTCPeerConnection (polite=false)
+5. Exchanges answer and ICE candidates
+6. Data channel opens, health monitoring starts
+
+*** Reconnection
+1. Health monitor detects issues or connection drops
+2. Exponential backoff timer starts
+3. New connection attempt with fresh connectionId
+4. ICE restart or full renegotiation
+
+** Key Design Decisions
+
+*** Perfect Negotiation Pattern
+Prevents glare when both peers try to connect simultaneously by using
+polite/impolite roles.
+
+*** Health Monitoring
+Proactive ping/pong messages detect connection issues before browser APIs,
+enabling faster recovery.
+
+*** Connection ID Tracking
+Each connection attempt has unique ID to ensure offer/answer pairs match
+during concurrent connections.
+
+*** Leveraging Existing Infrastructure
+WebRTC signaling is just another payload type in the existing broadcast
+system - no new server complexity.
+
+** Implementation Order
+
+*** Phase 1: Core Infrastructure
+1. Create protocol message schemas
+2. Update broadcastToRealm function
+3. Add peer join/leave broadcasts
+4. Create WebRTC utilities module
+
+*** Phase 2: Client Connection Management
+1. Implement WebRTCManager
+2. Create PeerConnection class
+3. Add perfect negotiation
+4. Implement health monitoring
+
+*** Phase 3: UI Integration
+1. Update main app to initialize WebRTC
+2. Create PeerList component
+3. Add MessageInterface with dual modes
+4. Style connection indicators
+
+*** Phase 4: Robustness
+1. Add reconnection logic
+2. Implement ICE restart
+3. Handle edge cases
+4. Add comprehensive error handling
+
+** Testing Strategy
+
+*** Unit Tests
+- Perfect negotiation scenarios
+- Health monitoring logic
+- Message routing
+
+*** Integration Tests
+- Full connection flow with mocks
+- Signaling message flow
+- State management
+
+*** E2E Tests
+- Real browser testing
+- Network condition simulation
+- Multi-peer scenarios
+
+*** Load Tests
+- Mesh scalability limits
+- Message throughput
+- Connection stability