UniClipboard: Peer-to-Peer Clipboard Sync Without an Account

The problem UniClipboard targets, and who it is actually for

Clipboard sync normally means routing your copied text through somebody else's service. UniClipboard takes the opposite position: the README describes it as local-first, peer-to-peer and end-to-end encrypted, with "No cloud account. No third-party servers." Devices that trust each other form a space, and clipboard content is encrypted in transit and at rest with XChaCha20-Poly1305 AEAD. The README states that even the relay only sees ciphertext, which matters because a relay is still a server, just one that cannot read what it forwards.

The intended user is someone running two or more of their own machines, typically desktops, who copies a snippet on one and wants it on the other without an account, an email address, or a subscription. A second audience is terminal users: the project ships a `uniclip` CLI that the README says mirrors the GUI flow and works headlessly, aimed at SSH sessions, scripts and tmux. That combination, P2P transport plus a headless client, is the part that distinguishes it from clipboard managers that only operate inside one machine.

How the peer-to-peer space works, and where the relay fits

The unit of trust is a space. According to the README, devices join a shared space with one invitation code plus a passphrase, and there is no cloud account involved. Pairing is therefore a two-step exchange: the code identifies the space, the passphrase authorises membership. Once joined, the README says desktop peers sync either on the same Wi-Fi or across the internet, with automatic NAT traversal and an encrypted relay fallback. That fallback is the honest part of the design: NAT traversal does not always succeed, so the project keeps a relay path that carries ciphertext rather than pretending direct connections are guaranteed.

The repository layout reflects a split between a daemon and its clients. The root Cargo workspace lists `apps/cli` (the `uniclip` binary) and `apps/daemon` (described in the Cargo.toml comments as the `uniclipd` binary), alongside crates such as `uc-daemon-contract`, `uc-daemon-process`, `uc-daemon-local`, `uc-daemon-client` and `uc-webserver`. A Tauri desktop package lives under `src-tauri`, with its adapter crate at `src-tauri/crates/uc-tauri`. In other words, the GUI is not the sync engine; it is one front end over a daemon that also serves the CLI. The workspace comments note that all desktop consumers use one immutable Engine revision, which is a deliberate choice to keep transport behaviour identical across front ends.

Storage and search are local. The README claims a local full-text index that stays encrypted on disk and returns results from tens of thousands of entries. Large payloads use streaming transfer so a file does not have to fit in memory. Both claims come from the project's own documentation; the README does not publish the benchmark methodology behind the search figure.

Installing UniClipboard and creating your first space

The README lists four install paths: download from GitHub Releases, a one-line script for Linux and macOS, Homebrew on macOS, and building from source. The script is the shortest route. It detects the OS and CPU and, on macOS, extracts `UniClipboard.app` into `/Applications`; on Linux it installs a `.deb` through `apt` or an `.rpm` through `dnf`/`yum` when sudo is available, and otherwise falls back to an AppImage in `~/.local/bin` with a `.desktop` entry.

curl -fsSL https://uniclipboard.app/install.sh | bash

You can pin a version or force the rootless AppImage path. Both flags are documented in the README:

# Pin a specific version
curl -fsSL https://uniclipboard.app/install.sh | bash -s -- --version v0.9.0

# Force AppImage (rootless even when sudo is available)
curl -fsSL https://uniclipboard.app/install.sh | bash -s -- --format appimage

After install, the README's usage section splits into two flows. On the first device you create a space; on every later device you join it via an invitation code and passphrase. For a headless machine, the `uniclip` CLI is the relevant entry point rather than the desktop binary. The README does not reproduce the full CLI flag list in the excerpt available here, so check the CLI section of the README before scripting it.

Uninstalling uses a matching script. The default removes the app and keeps data and config; `--purge` also removes data directories, config and cache; `--dry-run` previews without deleting.

# Remove the app only, keep data and config
curl -fsSL https://raw.githubusercontent.com/UniClipboard/UniClipboard/main/scripts/uninstall.sh | bash

# Full wipe — also removes data directories, config, and cache
curl -fsSL https://raw.githubusercontent.com/UniClipboard/UniClipboard/main/scripts/uninstall.sh | bash -s -- --purge

Alpha status, mobile compatibility mode, and update gaps

Three limitations are visible without running anything. The first is maturity. The README carries a warning that UniClipboard "is currently under active development and may have unstable or missing features," and the release list is entirely `v1.0.0-alpha.*` builds, the most recent being v1.0.0-alpha.5 on 2026-08-16. The last push to the default branch was the same day. That is recent enough that the repository is not dormant, but an alpha release cadence is not the same thing as a stable one, and the project says so itself.

The second is mobile. The README is explicit that current iOS and Android releases connect through a compatibility mode, and that the bundled iOS Shortcut belongs to a separately versioned LAN compatibility channel. Mobile products may expose LAN HTTP as a user-selected channel that "never replaces or automatically takes over from the shared P2P core." Anyone expecting the phone to behave as an equal P2P peer today will be disappointed; the README frames that as the target architecture, not the shipped one. The mobile app itself is a separate repository, UniClipboard/UniClip.

The third is updates. The README states that `.deb` and `.rpm` installs are not picked up by the in-app updater, so those users must re-run the script or use the system package manager. If you install through a distribution package, you have opted out of in-app updates whether you meant to or not.

UniClipboard compared with SyncClipboard and ClipCascade

The searches that bring people here include SyncClipboard and ClipCascade, and the difference is architectural rather than cosmetic. SyncClipboard is built around a server you point your clients at, so the server is part of the data path and you are responsible for running it. UniClipboard tries to avoid that role entirely: peers connect directly where NAT traversal succeeds, and the relay is a ciphertext-only fallback. If you already run a server and want a client-server model you can inspect and firewall, SyncClipboard's approach is easier to reason about. If you do not want to operate a server at all, that is the gap UniClipboard is aiming at.

ClipCascade occupies similar ground, a self-hosted clipboard sync service, but self-hosted still means a host. The distinction to weigh is who can read your clipboard contents. UniClipboard's answer is that neither the relay nor the network layer can, because encryption happens on the devices. Whether that holds up is a question for the security documentation, not the marketing line: the repository includes a SECURITY.md, and that is the file to read before trusting the claim.

Licence and the cost of keeping up with an alpha

UniClipboard is AGPL-3.0-only; both the root Cargo workspace and package.json carry that identifier, and the README links to ./LICENSE. The practical consequence of AGPL for most individual users is nil, but if you intend to embed the daemon or the CLI in a product you distribute or expose over a network, the copyleft terms apply to that combined work. This is a description of the licence identifier, not legal advice; read the licence text and, for commercial use, a lawyer.

Upgrade cost is the real ongoing expense. The project is on alpha releases, so API and CLI surfaces can move between versions. The workspace pins all desktop consumers to one immutable Engine revision, which limits drift inside a build but does not protect you across builds. The `.deb` and `.rpm` updater gap means Linux users on those formats need a deliberate upgrade step. On the plus side, the repository is a normal Cargo workspace with a Makefile for the platform crate, so building from source is a known shape rather than a bespoke toolchain. The `cargo test --manifest-path tests/e2e/Cargo.toml` invocation documented in Cargo.toml is how the CLI end-to-end tests are built, since that crate is excluded from the workspace.

Editorial conclusion

Adopt UniClipboard if you want clipboard sync between your own desktops without a hosted account, and you are willing to run alpha software and verify the release notes and SECURITY.md before trusting it with anything sensitive. Skip it if you need a stable, signed desktop build or if your main requirement is phone-to-PC sync, since the mobile app is a separately versioned compatibility channel rather than the P2P core. Before installing, read the release notes for the build you intend to run and check whether your platform gets an in-app updater or only a package-manager path.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes