Back to Articles

Bananas: How P2P WebRTC Makes Screen Sharing Simpler Than It Should Be

[ View on GitHub ]

Bananas: How P2P WebRTC Makes Screen Sharing Simpler Than It Should Be

Hook

Over six thousand developers have starred a screen sharing tool that deliberately chose to forget everything you share the moment you close the window. No recordings, no history, no accounts—just ephemeral collaboration.

Context

Screen sharing shouldn’t require creating an account, remembering another password, or trusting a third party with your video stream. Yet most tools route everything through their servers.

Bananas takes the opposite bet. Built by mistweaverco with Svelte and WebRTC, it’s a cross-platform desktop app (Mac, Windows, and Linux) that connects peers directly. No authentication flow, no cloud storage, no middleware processing your screen capture. You launch the app, generate a session code, share it with a colleague, and your machines negotiate a direct connection. The project has attracted over 6,000 stars because it solves a specific frustration: sometimes you just need to show someone your screen without the ceremony of enterprise video conferencing.

Technical Insight

The architecture is deceptively simple but relies on WebRTC’s most elegant properties. When you start a session in Bananas, the app generates a unique identifier and connects to a signaling server—not to route video, but purely to exchange SDP (Session Description Protocol) offers and ICE (Interactive Connectivity Establishment) candidates. This is the handshake: two peers saying “here’s my network fingerprint, here’s how you might reach me.”

Once the handshake completes, the signaling server becomes irrelevant. Your screen capture stream flows directly from your machine to your peer’s machine over a UDP connection negotiated through STUN (Session Traversal Utilities for NAT) servers. If both peers are behind restrictive NATs—common in corporate networks—the connection falls back to TURN (Traversal Using Relays around NAT) servers. As the README notes, these servers are only “needed for exchanging the initial connection information.”

This is fundamentally different from traditional video conferencing tools that route video through servers that decode, mix, and re-encode streams. Bananas doesn’t do any of that. What you capture is what your peer sees, with no intermediary processing.

The Svelte frontend choice is interesting for a desktop application. Svelte compiles to vanilla JavaScript without a runtime, which typically results in smaller bundles compared to framework-heavy alternatives. For a desktop app where startup time matters, this contributes to the “simple” and “easy-to-use” experience the README promises.

What Bananas deliberately doesn’t do is as important as what it does. There’s no server-side recording capability because there’s no server receiving the stream. There’s no participant management UI beyond “share this code” because there’s no roster stored anywhere. These aren’t oversights—they’re architectural consequences of choosing P2P purity over feature completeness.

Gotcha

The P2P architecture that makes Bananas elegant also makes it fragile in certain network environments. If you’re behind a symmetric NAT—common in enterprise networks with aggressive firewall policies—and your peer is similarly restricted, the connection may fail to establish. The README acknowledges the dependency on “stun, turn and signaling servers” but doesn’t specify which public servers it uses or whether you can configure your own. For corporate environments with strict firewall policies, this could be a limitation.

The lack of any persistent state also means no session recovery. If your network hiccups and the WebRTC connection drops, you likely start over with a new session code. There’s no “reconnect to previous session” because the session never existed beyond the ephemeral connection between two peers. This is fine for quick “let me show you this bug” scenarios but potentially frustrating for longer sessions where interruptions are inevitable.

Verdict

Use Bananas if you need zero-friction screen sharing for ad-hoc pair programming, debugging sessions, or design reviews where privacy matters and you don’t want another SaaS account. It’s perfect for open-source maintainers doing remote collaboration with contributors, or for teams that already communicate through other channels and just need the visual component. The installation is straightforward—available through GitHub releases or via Homebrew on Mac with brew install --cask bananas—and the absence of authentication means you can share your screen quickly after launching. Skip it if you work in a corporate environment with restrictive NAT policies where P2P connections routinely fail, or if you need any session persistence—recordings, chat logs, or participant history. Also skip it for presentations to large groups; P2P architectures don’t scale well to one-to-many broadcasting scenarios.

// QUOTABLE

Over six thousand developers have starred a screen sharing tool that deliberately chose to forget everything you share the moment you close the window. No recordings, no history, no accounts—just e...

[ Tweet This ]
// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/developer-tools/mistweaverco-bananas.svg)](https://starlog.is/api/badge-click/developer-tools/mistweaverco-bananas)