p2p.kiwi: P2P screen sharing for Mac, Windows and Linux

What p2p.kiwi is for, and who it is aimed at

p2p.kiwi is a desktop screen-sharing tool for Mac, Windows and Linux. The README describes it as "a simple and easy-to-use screen sharing tool" that uses a peer-to-peer connection "without the need for an account." That framing sets the target user: someone who wants to show a screen to one or a few people and does not want to create an identity, invite a colleague into a tenant, or route media through a vendor's conferencing infrastructure.

The repository topics list cross-platform, multi-cursor, p2p, pair-programming, pairing, peer-to-peer and screensharing. Pair programming is the clearest fit. A developer who needs a second pair of eyes on a branch can share the desktop directly rather than pushing to a remote branch and asking for a review. The multi-cursor topic suggests the app does more than broadcast pixels, though the README does not describe a remote-control mechanism.

The project is written in TypeScript and ships as an Electron app. The package.json main entry points at ./out/main/index.js, and the build scripts target electron-builder for Windows, macOS and Linux. That matters for adoption: this is not a web page you open in a browser. Every participant installs a native binary.

How the peer-to-peer connection and E2EE layers fit together

The README is explicit that peer-to-peer does not mean serverless. STUN and optional TURN servers "are still used to exchange ICE connectivity information," and the README adds that this is "not a signaling server for chat or media keys." So the signaling path exists for ICE negotiation only. Media flows over the WebRTC data path once connectivity is established.

The encryption stack is documented as four layers. ICE over UDP handles networking. DTLS-SRTP provides WebRTC transport security. SFrame encrypts media frames. MLS manages membership and end-to-end keys. The README answers three separate questions about these layers: MLS answers who is in the encrypted group and what secrets they hold, SFrame answers how a video or audio frame is encrypted so that infrastructure carrying it cannot read it, and DTLS-SRTP answers how WebRTC media is transported securely.

The README carries a warning that is worth repeating because it is the kind of mistake reviewers make: do not determine whether a call is end-to-end encrypted by checking whether WebRTC reports DTLS-SRTP. DTLS-SRTP is expected to encrypt transport. The project's stated E2EE guarantee comes from MLS-managed application keys encrypting media with SFrame, referencing RFC 9420 for MLS and RFC 9605 for SFrame.

That layering is the most interesting design decision in the project. Transport encryption and application-layer encryption are treated as separate properties, and the documentation names the RFCs so a reader can check the claim. What the README does not describe is key verification: there is no safety-number or fingerprint comparison step documented, so the reader cannot confirm from the README how two participants would detect a substituted key.

Installing p2p.kiwi on macOS, Arch Linux or from a release build

The README lists three install routes. On macOS, Homebrew installs the cask:

brew install --cask p2p-kiwi

The cask name is p2p-kiwi with a hyphen, not the dotted project name.

On Arch Linux, the README gives two AUR helpers for the p2p-kiwi-bin package:

paru -S p2p-kiwi-bin

or

yay -S p2p-kiwi-bin

Note that the README's own snippet for these two commands ends with a stray backtick. Copy the command without it. For Windows and for anyone who prefers a direct download, the README points at the GitHub releases page and says to grab the latest release. The current release line at the time of writing is v3.0.1, published on 2026-09-19, one day after v3.0.0.

For a first real use, the flow implied by the documentation is: install the app, launch it, start a session, and share the resulting connection information with the other participant so ICE can negotiate. The README does not document the exact UI steps for creating or joining a session, so treat the in-app flow as the source of truth rather than expecting a documented command line.

Building from source is possible. The repository has a Makefile with targets for macos, linux, linux-arm64, linux-debug and windows, and package.json defines a dev script that runs tsx ./scripts/dev.ts. The Makefile's run target is pnpm run dev. The README does not document the build prerequisites, so anyone going down this path is reading the Makefile and scripts directly.

Where p2p.kiwi is the wrong tool

The most concrete limitation is that p2p.kiwi is a desktop application, not a browser tab. A participant on a locked-down machine that cannot install Electron binaries cannot join. That immediately rules it out for sharing with clients, candidates or anyone outside your organisation who will not install software for a single call.

TURN is the second constraint, and the README is honest about it by calling TURN optional. Optional in the configuration sense, not in the connectivity sense. On symmetric NATs and restrictive corporate networks, a direct peer connection may not form, and TURN relays become necessary. The README does not document how a user supplies their own TURN server, so a team behind a strict firewall may find that the app cannot connect at all and have no documented remedy.

The E2EE story also has an unresolved edge. The README explains what MLS and SFrame provide, but it does not describe how participants verify each other's keys. Application-layer encryption without a documented verification step protects against passive infrastructure but leaves the question of an active key-substitution attack unanswered in the documentation. For a pair-programming session between colleagues who already trust each other, that gap is minor. For a threat model that includes a hostile signaling path, it is the thing to investigate before relying on the E2EE claim.

Finally, the README does not document rollback, version pinning, or an upgrade procedure. It points at the releases page for downloads and stops there.

How p2p.kiwi differs from browser-based screen sharing

The obvious alternative is a browser-based WebRTC screen-sharing service, the kind where one participant opens a URL and the other clicks a link. The difference is where the code runs and what the user has to trust.

A browser-based tool executes in a page served by the operator. The participant trusts the served JavaScript on every session, and the operator can change that JavaScript at any time. p2p.kiwi ships as a signed desktop binary that the user installs once. The user can inspect the repository, since it is MIT licensed and the source is on GitHub, and can build the app themselves using the Makefile targets. That is a meaningfully different trust model, and it is the strongest argument for the desktop approach.

The cost is friction and reach. A browser tool works on a Chromebook, on a locked-down work laptop, and on a phone. p2p.kiwi does not, as far as the README describes. The second difference is the encryption layer. Most browser screen-sharing products rely on DTLS-SRTP and call that end-to-end encryption. p2p.kiwi adds SFrame media encryption under MLS-managed keys, which the README explicitly distinguishes from transport encryption. Whether that distinction matters depends on whether you consider the service operator part of your threat model. If you do, the extra layer is the point. If you do not, it is complexity you are paying for without a matching benefit.

Maintenance, licensing and the cost of staying current

The repository is not archived, and the last push was on 2026-09-19. Three releases landed in the four days before that: v2.0.2 on 2026-09-16, v3.0.0 on 2026-09-18 and v3.0.1 on 2026-09-19. A v3.0.0 to v3.0.1 patch one day later suggests the major release needed a quick fix, which is normal but worth noting if you plan to pin a version.

The project is MIT licensed. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and licence text are preserved. The repository also carries PRIVACY.md, TOS.md and SECURITY.md, so there are separate policy documents alongside the code licence. Those are policy documents, not licence terms, and they govern use of the project's own services rather than the source code. Nothing here is legal advice; read the files yourself.

Upgrade cost is where the documentation is thin. The README does not describe an update mechanism, a version compatibility policy, or what happens when one participant runs v3.0.1 and another runs v2.0.2. The E2EE stack depends on MLS group state and SFrame key derivation, so version skew between participants is the kind of thing that could plausibly break a session, and the README does not say whether it does. Verify that before standardising on a version across a team.

Build and release maintenance sits in the Makefile and the scripts directory. The Makefile exposes macos, linux, linux-arm64, linux-debug, windows and release targets, plus a set-version.sh script behind the version target. A team that wants to distribute its own builds has a documented entry point; a team that just wants to install and use the app does not need any of it.

Editorial conclusion

Adopt p2p.kiwi if you want a desktop screen-sharing client that pairs without account creation and you accept that the README does not document rollback or upgrade procedures. Skip it if you need a browser-only tool, a documented self-hosted signaling deployment, or a formal audit of the MLS and SFrame implementation. Before rolling it out, verify the release artifacts on the GitHub releases page, check which TURN configuration your network requires, and confirm that the E2EE guarantee described in the README matches your threat model.

Frequently asked questions

Official sources

1. dont-be-evil-company/p2p.kiwi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases