CrowdTalkie Development Update: Mesh Hardware, P2P Stability, and What's Next
Since launching CrowdTalkie as the successor to Flash Protest, development has accelerated. This post summarizes what’s changed: new features, stability improvements, infrastructure work, and where the project is heading.
The Big Addition: Mesh Hardware Guide
The most visible new feature is a comprehensive Mesh Hardware page, accessible from the home screen. This is exploratory work—we’re researching what kind of software support CrowdTalkie would need to integrate with external mesh hardware.
CrowdTalkie’s Web Bluetooth mesh works for short-range communication (~30 meters between phones). But what if you need to coordinate across a larger area? External mesh radios can extend range from meters to kilometers. The new guide covers:
Wireless Technology Comparison
We break down LoRa, Bluetooth, WiFi, and Zigbee with an emphasis on what matters for crowd coordination:
- LoRa: Long range (2-10km line of sight), low power, excellent jamming resistance
- Bluetooth: Short range but ubiquitous, works with any phone
- WiFi: High bandwidth but easy to jam, range limited
- Zigbee: Good for sensor networks, less useful for audio
Consumer Dongle Recommendations
Not everyone wants to solder. We list ready-to-use options:
- LILYGO T-Beam: ESP32 + LoRa + GPS in one package
- Heltec LoRa V3: Compact, affordable LoRa node
- Avantree DG80: USB Bluetooth adapter for desktop integration
- Several others with pros, cons, and use cases
DIY Build Guide
For the hardware-inclined, we provide a complete build guide for an ESP32-S3 + SX1262 LoRa radio (~$36 in parts). The guide includes:
- Parts list with sourcing options
- Wiring diagrams
- Firmware flashing instructions
- Integration with CrowdTalkie’s Bluetooth bridge
This research helps us understand what CrowdTalkie would need at the software level to support external hardware—protocol bridges, audio encoding for low-bandwidth links, message routing across heterogeneous networks. We’re exploring the possibilities before committing to implementation.
P2P Networking Stability
The invisible work that makes everything else possible. Multiple PRs addressed peer-to-peer connection reliability:
Fixed Yamux Version Incompatibility
Different libp2p implementations were using incompatible yamux multiplexer versions, causing cross-device sync to fail silently. Pinning versions fixed connections between diverse device types.
Global Presence Topic for GossipSub
Peer discovery now uses a global presence topic. Devices announce themselves regardless of which room they’re in, making it easier to find peers before joining a specific room.
Floodsub Fallback
GossipSub requires a minimum number of peers to function properly. In low-peer scenarios (early room joins, sparse areas), we now fall back to floodsub—less efficient but more reliable with few connections.
Relay Subscription Fixes
Relay nodes weren’t properly subscribing to room topics dynamically. Fixed—relays now subscribe when rooms are created and forward messages correctly.
Improved Connection Monitoring
Added periodic connection logging and better ping service behavior. When connections drop, we know why.
Research & Feasibility Reports
We documented several technical investigations:
Flutter Conversion
Evaluated converting the React PWA to Flutter for native mobile performance. Conclusion: the PWA approach serves our goals better (instant access, no app store gatekeeping), but Flutter remains an option if we need native Bluetooth APIs that Web Bluetooth can’t provide.
Room Merge & ICS Hierarchy
Assessed adding room merging (combine two rooms into one) and Incident Command System organizational structures. Both are technically feasible. ICS hierarchy would let rooms adopt standard emergency response roles—useful for larger coordinated actions.
Wireless Dongles Research
Deep dive into non-cellular mesh communication technologies. This research fed directly into the Mesh Hardware page.
CI/CD Infrastructure
The project now has proper automated deployment:
- GitHub Actions workflow for automatic Cloudflare Pages deployment
- ESLint 9 flat config migration (modern linting)
- Basic test infrastructure in place
Pushes to main automatically deploy. No more manual deploys.
UI/UX Improvements
Several user-facing changes:
Language Cleanup
Replaced tactical/military language with plain civilian terms. CrowdTalkie is for communities, not combat. “Participants” instead of “operators.” “Room” instead of “channel.”
Interface Polish
- Fixed ShareRoom modal with sticky header/footer (no more scrolling past buttons)
- Updated PTT button design
- Improved QuickActions layout
- Better Room page organization
- Organizers can recenter the map on all participants
Performance
- Fixed memory leaks in useEffect hooks
- Optimized component re-renders
- Better geofence filtering performance
Bug Fixes
The usual parade of fixes:
- Peer geolocation authentication working correctly
- QR code sync status displays accurately
- Message event handler no longer crashes on undefined topics
- Connection status thresholds adjusted for real-world conditions
Technical Stack
For reference, here’s what CrowdTalkie runs on:
| Area | Technology |
|---|---|
| Frontend | React 18 + TypeScript + Vite |
| P2P Network | libp2p (WebRTC, WebSocket, GossipSub) |
| State Sync | Yjs CRDTs |
| Offline | IndexedDB + Service Worker |
| Fallback | Web Bluetooth mesh |
| Hosting | Cloudflare Pages |
What’s Next
The Mesh Hardware page represents early-stage exploration. Before building anything, we need to understand what software changes would be required and whether the community sees value in hardware integration.
The vision we’re evaluating is multi-transport resilience:
- Phone-to-phone Bluetooth for immediate vicinity (~30m)
- External mesh radios for extended range (~2-10km)
- Internet/WebRTC when available
- Automatic failover between all three
If we pursue this, it would mean building protocol bridges, optimizing audio for low-bandwidth links, and handling message routing across different network types.
We Want Your Input
Personally, I’m leaning toward LoRa as the external mesh technology to support first. The range (kilometers vs. meters), jamming resistance, and growing ecosystem (Meshtastic, etc.) make it compelling for resilient crowd coordination.
But this is a significant direction to take, and I’d like to hear from others:
- Is hardware integration something you’d actually use? Or is the current phone-only approach sufficient?
- If we support external radios, which technology matters most? LoRa? Something else?
- What’s your context? Large outdoor gatherings? Urban environments? Rural areas?
If you have thoughts, email me at [email protected]. This is the kind of decision that should be shaped by the people who’ll actually use the tool.
Other Explorations
We’re also looking at:
- Audio compression improvements for lower-bandwidth mesh links
- Store-and-forward for high-latency mesh paths
- Hardware integration SDK for third-party radio manufacturers (if we go that direction)
Try It
CrowdTalkie is live at crowdtalkie.com. Add it to your home screen—it works offline once installed.
The mesh hardware guide is accessible from the home page. Even if you never build a LoRa radio, the comparison table helps understand why resilient communication matters.
CrowdTalkie is part of the Antifascist Fun Brigade toolkit. When coordination matters, privacy and resilience aren’t optional.