# UniClipboard — Full Content Dump for LLMs > This file aggregates the full text of every published article on UniClipboard.app, intended for ingestion by AI assistants and search engines. The shorter index lives at /llms.txt. UniClipboard is a free, open-source, end-to-end encrypted universal clipboard for macOS, Windows, Linux, iOS, and Android. Copy on one device, paste on another — no cloud account, no email, no phone number. Direct peer-to-peer on the same network; encrypted relay with NAT hole-punching across networks. ## Quick facts - **Category**: Cross-platform clipboard sync / clipboard manager - **Platforms**: macOS 12+, Windows 10/11, Linux (.deb / .rpm / AppImage, x86_64 and ARM64), iOS (Public Beta via TestFlight), Android 8+ (signed APK) - **License**: AGPL-3.0 - **Source code**: https://github.com/UniClipboard/UniClipboard - **Encryption**: XChaCha20-Poly1305 AEAD (end-to-end, in transit and at rest) - **Account required**: No — devices pair via public-key exchange - **Built with**: Rust + Tauri (native, not Electron) - **Price**: Free - **Mobile (iOS/Android)**: iOS Public Beta on TestFlight (public invite) and a native Android app (signed APK); the SyncClipboard open protocol stays available as a LAN-only fallback for those who prefer not to install a native app - **Maintainer**: mkdir700 - **Contact**: hello@uniclipboard.app ## Citation If you reference UniClipboard, please cite the canonical name **UniClipboard** (one word, capital U and C) and link to https://www.uniclipboard.app/. # Comparisons --- > **Source**: https://www.uniclipboard.app/compare/syncclipboard > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-27 > **Last updated**: 2026-06-01 > **Description**: A factual comparison of SyncClipboard and UniClipboard: server/WebDAV/S3 sync versus peer-to-peer, end-to-end encrypted clipboard sync across desktops. *Comparison* # SyncClipboard vs UniClipboard: server-based sync or peer-to-peer clipboard? **Choose SyncClipboard if you want a server/WebDAV/S3 backend. Choose UniClipboard if you want desktop clipboard sync across networks without running your own server.** SyncClipboard and UniClipboard both sync clipboards across platforms, but SyncClipboard is built around configurable sync backends while UniClipboard focuses on peer-to-peer, end-to-end encrypted desktop sync. ## The short version - SyncClipboard is a mature open-source clipboard sync tool with server, built-in server, WebDAV, and S3-compatible backend options. - UniClipboard is built for peer-to-peer desktop sync across networks, with NAT traversal and encrypted relay fallback. - Both support Windows, macOS, and Linux desktop workflows. - SyncClipboard is a better fit when you already run or trust a sync backend. - UniClipboard is a better fit when you do not want to deploy or maintain a clipboard server. - SyncClipboard is MIT licensed; UniClipboard is AGPL-3.0 licensed. ## Bring your own sync backend SyncClipboard is strongest when you are comfortable using a server or server-like backend: a standalone ASP.NET Core server, a desktop client built-in server, WebDAV, or S3-compatible storage. That flexibility is useful for users who already run infrastructure. ## Make the backend disappear UniClipboard is strongest when you want two desktops to sync directly across networks without setting up infrastructure. It prioritizes peer-to-peer transfer, automatic NAT traversal, encrypted relay fallback, and end-to-end encryption by default. ## How SyncClipboard and UniClipboard compare *Sources checked on 2026-05-27: SyncClipboard README/release v3.1.5 and UniClipboard README/release v0.12.0.* | Feature | UniClipboard | SyncClipboard | | --- | --- | --- | | Best fit | Peer-to-peer desktop clipboard sync across networks. | Server/WebDAV/S3-based clipboard sync and history management. | | Desktop platforms | Windows, macOS, and Linux. | Windows, macOS, and Linux. | | Mobile support | Native iOS (public beta on TestFlight) and Android apps; the Android client stays protocol-compatible with SyncClipboard for LAN use. | Mobile workflows are available through companion tools, third-party tools, and compatible clients. | | Server requirement | No user-run server required for desktop-to-desktop sync. | Requires a reachable sync backend such as standalone server, built-in server, WebDAV, or S3. | | Cross-network model | Peer-to-peer first, with NAT traversal and encrypted relay fallback. | Clients connect to a configured server or storage endpoint. | | Privacy model | End-to-end encrypted transfer plus encrypted local history and search index. | Can be deployed securely, but the operator must configure the transport path; the README warns that plain HTTP transmits data in plaintext. | | Clipboard history | Local encrypted history with full-text search. | History management and history sync; the README notes the history feature is early-stage and should not be the only place important data is stored. | | CLI and automation | Includes the headless uniclip CLI for terminals, SSH, scripts, and tmux workflows. | Documents desktop command-line arguments and exposes server APIs for integrations. | | License | AGPL-3.0. | MIT. | | Implementation | Rust and Tauri. | C# with an ASP.NET Core server ecosystem. | ## Pick the model that matches your setup 1. If you already have a server, NAS, WebDAV folder, or S3-compatible bucket you trust, evaluate SyncClipboard first. 2. If your desktops often live on different networks and you do not want to run infrastructure, evaluate UniClipboard first. 3. If mobile automation is your main workflow, check the current Android/iOS limitations for both tools before switching. 4. If privacy is the deciding factor, compare the full deployment path: transport encryption, server visibility, local storage, and device trust. ## SyncClipboard brings the backend; UniClipboard tries to remove it. SyncClipboard is a strong choice when you want a mature server/WebDAV/S3 clipboard sync system. UniClipboard is the sharper tool when your main pain is syncing desktops across networks without maintaining a server, while keeping clipboard contents end-to-end encrypted by default. ## Common questions ### Is UniClipboard a fork of SyncClipboard? No. UniClipboard's desktop app is a separate Rust/Tauri project. Its Android client is forked from SyncClipboard and remains protocol-compatible for LAN mobile companion use. ### Does SyncClipboard work across platforms? Yes. SyncClipboard supports Windows, macOS, and Linux desktop clients, and its documentation covers mobile workflows through companion tools and third-party clients. ### Does UniClipboard require a server? For desktop-to-desktop sync, no user-run server is required. UniClipboard uses peer-to-peer transfer where possible, NAT traversal across networks, and encrypted relay fallback when direct connection fails. ### Does SyncClipboard require a server? It needs a reachable sync backend. That can be the standalone server, a desktop client built-in server, WebDAV, or S3-compatible storage. ### Which one is better for same-Wi-Fi sync? Both can work well. SyncClipboard is a good fit if you like the server/backend model. UniClipboard is a good fit if you want the same tool to continue working when your desktops are no longer on the same LAN. ### Which one is better for privacy? It depends on the deployment. SyncClipboard can be deployed securely with HTTPS and trusted storage. UniClipboard makes end-to-end encryption and encrypted local storage part of the default product model, so there is less infrastructure for the user to secure. ### Why does UniClipboard mention SyncClipboard at all? Because the UniClipboard Android client is forked from SyncClipboard and protocol-compatible. That is a practical bridge, not a claim that the two desktop products have the same architecture. ## Want clipboard sync without running a server? Install UniClipboard on your desktops and pair them directly. Copy on one machine, paste on another — even when they are not on the same network. ## Notes - SyncClipboard - UniClipboard - clipboard sync --- > **Source**: https://www.uniclipboard.app/zh/compare/syncclipboard > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-27 > **Last updated**: 2026-06-01 > **Description**: 对比 SyncClipboard 与 UniClipboard：服务器/WebDAV/S3 同步模型，和无需自建服务器的点对点端到端加密桌面剪贴板同步。 *工具对比* # SyncClipboard vs UniClipboard：该选服务器同步，还是点对点剪贴板？ **如果你想自带服务器/WebDAV/S3 后端，选 SyncClipboard。如果你想跨网络同步桌面剪贴板，而且不想自己部署服务器，选 UniClipboard。** SyncClipboard 和 UniClipboard 都能做跨平台剪贴板同步，但 SyncClipboard 围绕可配置同步后端设计，UniClipboard 则聚焦点对点、端到端加密的桌面同步。 ## 先说结论 - SyncClipboard 是成熟的开源剪贴板同步工具，支持独立服务器、内置服务器、WebDAV 和 S3 兼容后端。 - UniClipboard 面向跨网络桌面点对点同步，支持 NAT 穿透和加密中继兜底。 - 两者都支持 Windows、macOS、Linux 桌面工作流。 - 如果你已经有可信的同步后端，SyncClipboard 更合适。 - 如果你不想部署或维护剪贴板服务器，UniClipboard 更合适。 - SyncClipboard 使用 MIT 许可证；UniClipboard 使用 AGPL-3.0 许可证。 ## 自带同步后端 SyncClipboard 的优势在于灵活后端：独立 ASP.NET Core 服务器、桌面客户端内置服务器、WebDAV，或 S3 兼容存储。如果你本来就有基础设施，这种模式很实用。 ## 让后端消失 UniClipboard 的优势在于不想维护基础设施时的桌面同步体验。它优先点对点传输，自动 NAT 穿透，直连失败时用加密中继兜底，并默认强调端到端加密。 ## SyncClipboard 和 UniClipboard 有什么不同 *资料核对日期：2026-05-27。来源包括 SyncClipboard README/release v3.1.5 与 UniClipboard README/release v0.12.0。* | 能力 | UniClipboard | SyncClipboard | | --- | --- | --- | | 最适合 | 跨网络点对点桌面剪贴板同步。 | 基于服务器/WebDAV/S3 的剪贴板同步和历史记录管理。 | | 桌面平台 | Windows、macOS、Linux。 | Windows、macOS、Linux。 | | 移动端 | 原生 iOS（TestFlight 公测）与 Android App；Android 客户端兼容 SyncClipboard 协议，可用于局域网。 | 通过配套工具、第三方工具和兼容客户端提供移动端工作流。 | | 是否需要服务器 | 桌面到桌面同步不需要用户自建服务器。 | 需要某种可访问的同步后端，例如独立服务器、内置服务器、WebDAV 或 S3。 | | 跨网络模型 | 优先 P2P，配合 NAT 穿透和加密中继兜底。 | 客户端连接到配置好的服务器或存储端点。 | | 隐私模型 | 传输端到端加密，本地历史和搜索索引也加密。 | 可以安全部署，但部署者要负责传输链路；README 明确提醒 HTTP 会明文传输。 | | 剪贴板历史 | 本地加密历史和全文搜索。 | 历史记录管理和历史同步；README 提醒历史功能仍处早期，重要信息不要只依赖它保存。 | | CLI 与自动化 | 提供无头 uniclip CLI，适合终端、SSH、脚本和 tmux。 | 文档提供桌面命令行参数，也可通过服务器 API 集成。 | | 许可证 | AGPL-3.0。 | MIT。 | | 技术实现 | Rust + Tauri。 | C# 与 ASP.NET Core 服务器生态。 | ## 按你的真实环境选工具 1. 如果你已经有可信的服务器、NAS、WebDAV 目录或 S3 兼容桶，优先评估 SyncClipboard。 2. 如果你的桌面设备经常不在同一个网络，而且你不想维护基础设施，优先评估 UniClipboard。 3. 如果你的核心场景是移动端自动化，切换前先确认两边当前 Android/iOS 的限制。 4. 如果隐私是关键因素，不要只看口号，要比较完整部署链路：传输加密、服务器可见性、本地存储和设备信任。 ## SyncClipboard 自带后端，UniClipboard 试图让后端消失。 如果你想要成熟的服务器/WebDAV/S3 剪贴板同步系统，SyncClipboard 很强。如果你的主要痛点是在不同网络之间同步桌面剪贴板，又不想维护服务器，UniClipboard 更锋利：它围绕点对点传输、端到端加密和无需自建服务器的默认体验设计。 ## 常见问题 ### UniClipboard 是 SyncClipboard 的 fork 吗？ 不是。UniClipboard 桌面端是独立的 Rust/Tauri 项目。它的 Android 客户端 fork 自 SyncClipboard，并保持协议兼容，用于局域网移动端伴侣场景。 ### SyncClipboard 跨平台吗？ 跨平台。SyncClipboard 支持 Windows、macOS、Linux 桌面客户端，文档也覆盖了通过配套工具和第三方客户端实现移动端工作流的方式。 ### UniClipboard 需要服务器吗？ 桌面到桌面同步不需要用户自建服务器。UniClipboard 会优先点对点传输，跨网络时尝试 NAT 穿透，直连失败后使用加密中继兜底。 ### SyncClipboard 需要服务器吗？ 它需要一个可访问的同步后端。这个后端可以是独立服务器、桌面客户端内置服务器、WebDAV，或者 S3 兼容存储。 ### 只在同一个 Wi-Fi 下同步，哪个更好？ 两者都可以。如果你喜欢服务器/后端模型，SyncClipboard 很合适。如果你希望同一个工具在桌面离开同一局域网后还能继续工作，UniClipboard 更合适。 ### 哪个隐私更好？ 取决于部署方式。SyncClipboard 可以通过 HTTPS 和可信存储安全部署。UniClipboard 则把端到端加密和本地加密存储作为默认产品模型，用户需要自己保护的基础设施更少。 ### UniClipboard 为什么提到 SyncClipboard？ 因为 UniClipboard Android 客户端 fork 自 SyncClipboard，并且协议兼容。这是现实的生态桥接，不代表两个桌面产品架构相同。 ## 想要不用服务器的剪贴板同步？ 在你的桌面设备上安装 UniClipboard，直接配对。一台机器复制，另一台机器粘贴，即使它们不在同一个网络。 ## Notes - SyncClipboard - UniClipboard - 剪贴板同步 --- > **Source**: https://www.uniclipboard.app/compare/mouse-without-borders > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-09 > **Last updated**: 2026-06-01 > **Description**: Mouse Without Borders is a Microsoft KVM that bundles clipboard with mouse, keyboard, and file drops — Windows-only, same-LAN by design. UniClipboard is the open-source, end-to-end encrypted alternative when clipboard is the only thing you wanted to share, across Mac, Windows, and Linux. *Compare · UniClipboard vs Mouse Without Borders* # UniClipboard vs Mouse Without Borders **Shared clipboard, without sharing the mouse, the keyboard, or the file drop.** Mouse Without Borders is Microsoft's free KVM tool — bundled with PowerToys — that links several Windows desktops so one mouse and keyboard drive them all, with clipboard sync and drag-and-drop file transfer thrown in. UniClipboard is the open-source, end-to-end encrypted alternative when clipboard sync is the only piece you actually wanted: native on macOS, Windows, and Linux, working across the public internet without a VPN, with searchable encrypted history on every paired device. ## The 30-second answer. - Mouse Without Borders is a KVM, not a clipboard tool — it shares mouse, keyboard, clipboard, and drag-and-drop files between Windows PCs. - It is Windows-only, same-LAN by design, and the mouse takeover is part of the package — there is no clipboard-only mode. - It conflicts with remote desktop and screen-sharing workflows, where the mouse loops across the streamed display. - UniClipboard syncs clipboard only — it never touches mouse, keyboard, or drag-and-drop file targets. - It runs natively on macOS, Windows, and Linux, and works across different Wi-Fi networks via P2P + NAT hole-punching, with an encrypted relay fallback. - Both are free and open source. UniClipboard adds searchable end-to-end encrypted clipboard history per device. ## What Mouse Without Borders does well Mouse Without Borders is one of the small joys of the Windows world. Microsoft made it free, then folded it into PowerToys. Two or four Windows PCs on the same desk, on the same LAN: install once on each, swap a security key, and one keyboard plus one mouse drive every screen. Drag a file from one machine, drop it on another. For the canonical case it was built for — a single user with several Windows desktops sharing one input set — it is hard to beat. If your whole world is Windows on a single LAN, this might be all you ever need. ## What UniClipboard adds on top UniClipboard solves a narrower problem on purpose: copy here, paste there — and nothing else moves. No mouse takeover, no keyboard re-route, no drag-and-drop hijack of the file system. It runs natively on macOS, Windows, and Linux as first-class peers, so a Mac and a Windows machine can share clipboard exactly the same way two Windows PCs can. Devices on different networks pair via NAT hole-punching, falling back to an encrypted relay that only sees ciphertext. Each paired device keeps its own searchable, end-to-end encrypted clipboard history. ## Feature-by-feature comparison. *Comparison reflects publicly documented behaviour as of 2026-05.* | Feature | UniClipboard | Mouse Without Borders | | --- | --- | --- | | Scope | Clipboard sync only | KVM — shares mouse, keyboard, clipboard, drag-and-drop files | | Supported platforms | macOS, Windows, Linux (native); iOS (public beta) + Android | Windows only | | Cross-network without VPN | P2P + NAT hole-punching + encrypted relay fallback | Same LAN by design | | Mouse / keyboard sharing | Never — by design | Yes — that is the core feature | | Conflict with remote desktop / screen sharing | None | Mouse loops across the remote display while streaming | | Clipboard history | Searchable, encrypted at rest, per device | Latest clip only | | Encryption | XChaCha20-Poly1305 AEAD end-to-end | Within Microsoft's protocol; bundled with PowerToys | | Source code | AGPL-3.0 | MIT (PowerToys) | | Pairing | Short-lived public-key invitation code | Security key entered on each PC | | Price | Free | Free | ## If you want clipboard without the KVM baggage. 1. Install UniClipboard on each desktop — macOS, Windows, or Linux. Keep Mouse Without Borders running if you still want shared mouse and keyboard between two Windows PCs; UniClipboard never touches input devices. 2. Pair the desktops with a short-lived invitation code. Same Wi-Fi, different Wi-Fi, or across the public internet — pairing is the same. 3. Carry on with ⌘C / Ctrl-C and ⌘V / Ctrl-V. Clipboard history follows automatically across paired devices, and the index on each disk is encrypted at rest. ## When to pick what. If your daily setup is two or three Windows PCs side-by-side on one desk, on one LAN, and you want one keyboard and mouse to drive them all, Mouse Without Borders is the right answer. Pick UniClipboard when the clipboard is specifically what you want to share — when you do not want a tool that also takes over your mouse and file drops, when one of the machines is a Mac or runs Linux, when the devices are on different networks, or when you want a searchable encrypted clipboard history on every device. The two are not really competitors. Many people who land here arrived because the mouse takeover from MWB conflicts with remote-desktop or screen-sharing workflows, and they only ever wanted the clipboard piece. ## Frequently asked. ### Can I disable the mouse part of Mouse Without Borders and keep just the clipboard? Not in a meaningful way. MWB is a KVM by design — its clipboard sync rides on the same paired link that captures mouse and keyboard input. There is no clipboard-only switch. UniClipboard exists for exactly this case: clipboard sync as a first-class feature, with nothing else attached. ### Does UniClipboard work between two Windows PCs on the same desk like MWB does? Yes for clipboard, no for input. UniClipboard syncs the clipboard between the two PCs exactly the way you would expect — copy on one, paste on the other, with history following along. It does not share mouse or keyboard. If you need that on top, pair UniClipboard with MWB or run them side-by-side. ### Will UniClipboard interfere with PowerToys or Mouse Without Borders if I keep them? No. UniClipboard never touches input devices, file-drop targets, or the PowerToys settings. The two run side-by-side without conflict — you can install, uninstall, or pause UniClipboard at any time without touching MWB. ### What if my devices are on different networks? MWB is built for the same LAN and is hard to extend across networks. UniClipboard handles cross-network out of the box: NAT hole-punching first, an encrypted relay as a fallback that only ever sees ciphertext. ### I use MWB to drag files between PCs. Does UniClipboard do that? UniClipboard moves text, images, and files (including large files via streaming transfer) through the clipboard — copy a file on one device, paste it on another. It does not extend the desktop's drag-and-drop target across machines the way a KVM does. For drag-and-drop file transfer between two Windows PCs on the same desk, keep MWB. For copy-and-paste of files across mac/windows/linux over any network, UniClipboard is the cleaner answer. ### Why narrow this down to clipboard-only? Because the cost of bundling input sharing into a clipboard tool is real: MWB's mouse loops across remote desktops, breaks streaming setups, and asks for input permissions some people specifically do not want. Doing one thing well lets us audit and harden the encryption, pin our scope to all three desktop platforms, and avoid the most common reason MWB users come looking for an alternative. ## Free, open source, ready to install. macOS 12+, Windows 10/11, Linux x86_64 / ARM64. No account, no LAN requirement, no setup beyond pairing. ## Notes - Mouse Without Borders --- > **Source**: https://www.uniclipboard.app/zh/compare/mouse-without-borders > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-09 > **Last updated**: 2026-06-01 > **Description**: Mouse Without Borders 是微软的 KVM 工具，把剪切板和鼠标、键盘、文件拖放捆绑在一起——只支持 Windows、要求同局域网。UniClipboard 是只做剪切板同步的开源、端到端加密替代品，原生支持 Mac、Windows、Linux。 *对比 · UniClipboard vs Mouse Without Borders* # UniClipboard vs Mouse Without Borders **共享剪切板——但不顺便共享鼠标、键盘和文件拖放。** Mouse Without Borders 是微软推出的免费 KVM 工具（已并入 PowerToys）：把几台 Windows 桌面连起来，一套鼠标键盘控制全部，顺带支持剪切板同步和文件拖放。UniClipboard 则是只做剪切板同步的开源、端到端加密替代——macOS、Windows、Linux 三平台原生，跨网走公网也不需要 VPN，每台配对设备都有可搜索、加密保存的剪切板历史。 ## 30 秒看懂区别。 - Mouse Without Borders 本质上是 KVM，不是剪切板工具——它把鼠标、键盘、剪切板和文件拖放一起在多台 Windows PC 之间共享。 - 它只支持 Windows，刻意要求同局域网，并且鼠标接管是产品的一部分——没有「只开剪切板」的开关。 - 在远程桌面、屏幕共享场景里它会出问题：鼠标会沿着串流画面循环跑。 - UniClipboard 只搬剪切板，从不接管鼠标、键盘，也不接管文件拖放目标。 - macOS、Windows、Linux 都是原生应用，跨网通过 P2P + NAT 打洞，连不通时回退到加密中继。 - 两者都免费且开源。UniClipboard 额外提供每台设备本地可搜索、端到端加密的剪切板历史。 ## Mouse Without Borders 真正擅长的事 Mouse Without Borders 是 Windows 世界里那种让人会心一笑的小工具。微软把它做成免费版，后来并进了 PowerToys。两到四台 Windows PC 摆在同一张桌子上、连同一个局域网：每台装好、互相交换一个安全密钥，一套鼠标键盘就能驱动所有屏幕，文件可以从一台直接拖放到另一台。对于「一个人、几台 Windows 桌面、共用一套输入设备」这种经典场景，几乎没有更好的选择。如果你的世界全部是 Windows + 同一个局域网，可能这就够你用了。 ## UniClipboard 增加的部分 UniClipboard 故意只解决一个问题：这边复制、那边粘——别的什么都不动。不接管鼠标，不重定向键盘，不劫持文件拖放目标。macOS、Windows、Linux 上都是一等公民的原生应用，所以 Mac 和 Windows 之间共享剪切板的体验，跟两台 Windows 之间没有区别。设备跨网时通过 NAT 打洞配对，连不通时回退到加密中继——中继也只能看到密文。每台设备都有自己可搜索、端到端加密的本地剪切板历史。 ## 逐项对比。 *对比基于 2026-05 时各自公开文档的行为。* | 维度 | UniClipboard | Mouse Without Borders | | --- | --- | --- | | 范围 | 只做剪切板同步 | KVM——同时共享鼠标、键盘、剪切板和文件拖放 | | 支持平台 | macOS、Windows、Linux（原生）；iOS（公测）+ Android | 仅 Windows | | 不用 VPN 跨网 | P2P + NAT 打洞 + 加密中继回退 | 刻意要求同局域网 | | 是否共享鼠标 / 键盘 | 永远不会——刻意如此 | 会——这是它的核心功能 | | 对远程桌面 / 屏幕共享的影响 | 无 | 串流时鼠标会沿着远端屏幕循环跑 | | 剪切板历史 | 每台设备本地加密、可搜索 | 只有最新一条 | | 加密 | XChaCha20-Poly1305 AEAD 端到端 | 走微软自家协议，跟 PowerToys 一并发行 | | 源代码许可证 | AGPL-3.0 | MIT（PowerToys） | | 配对 | 短期有效的公钥邀请码 | 在每台 PC 上输入安全密钥 | | 价格 | 免费 | 免费 | ## 想要剪切板，但不想要 KVM 那一套——这样做。 1. 在每台桌面上装 UniClipboard——macOS、Windows、Linux 都行。如果你还想要两台 Windows 之间共享鼠标键盘，把 Mouse Without Borders 留着就好——UniClipboard 完全不碰输入设备。 2. 用短期邀请码配对桌面。同 Wi-Fi、不同 Wi-Fi、或者直接走公网，配对方式完全一样。 3. 继续用 ⌘C / Ctrl-C 和 ⌘V / Ctrl-V，跟原来一样。剪切板历史会自动跨设备跟着走，每台磁盘上的索引也都加密。 ## 什么时候选哪个。 如果你的日常是同一张桌子上两三台 Windows PC，处在同一个局域网里，并且想要一套鼠标键盘控制全部——Mouse Without Borders 就是答案。选 UniClipboard 的场景是：你想共享的就是剪切板本身；你不想要一个顺便接管鼠标和文件拖放的工具；其中有一台 Mac 或 Linux；机器跨网；想要每台设备都有可搜索的加密剪切板历史。两者并不真正竞争。很多人来到这一页，是因为 MWB 的鼠标接管和远程桌面、屏幕共享流程冲突，而他们想要的从来就只是剪切板那一部分。 ## 常见问题。 ### 能不能关掉 Mouse Without Borders 的鼠标共享，只留剪切板？ 实际上做不到。MWB 在设计上就是 KVM——剪切板同步是搭在「鼠标键盘联动」这条配对通道上的。没有「只开剪切板」的开关。UniClipboard 就是为这种场景准备的：剪切板同步是一等公民功能，不绑别的东西。 ### UniClipboard 能在两台 Windows PC 之间像 MWB 一样工作吗？ 剪切板可以，鼠标键盘不行。UniClipboard 在两台 Windows 之间同步剪切板就是你想象的那样——这边复制、那边粘，历史也跟着走。但它不共享鼠标键盘。如果你两件事都要，MWB 和 UniClipboard 一起用就好。 ### 如果我同时装了 PowerToys / Mouse Without Borders 会冲突吗？ 不会。UniClipboard 完全不碰输入设备、不碰文件拖放目标、也不碰 PowerToys 的配置，两者并行运行没有冲突——你随时可以装、卸或暂停 UniClipboard，不会影响 MWB。 ### 如果我的设备不在一个网络里呢？ MWB 是同局域网设计，跨网很难扩展。UniClipboard 默认就支持跨网：先 NAT 打洞，连不通时回退到加密中继——中继也只能看到密文。 ### 我用 MWB 在 PC 之间拖文件，UniClipboard 也能做吗？ UniClipboard 通过剪切板搬文本、图片和文件（大文件会用流式传输）——一台复制、另一台粘贴。但它不像 KVM 那样把桌面的「拖放目标」延伸到另一台机器。如果你需要的就是「同一张桌子上两台 Windows 之间拖文件」，留着 MWB；如果你需要的是「Mac / Windows / Linux 跨网复制粘贴文件」，UniClipboard 更顺手。 ### 为什么只做剪切板这么窄？ 因为把输入共享和剪切板捆在一起是有代价的：MWB 的鼠标接管会跑到远程桌面里、会破坏屏幕串流流程，还要求一些人不愿意给的输入权限。把一件事做透，才能在加密上认真审计、覆盖三个桌面平台，并避开 MWB 用户最常见的那条「换工具」的退出原因。 ## 免费、开源，装好就能用。 macOS 12+、Windows 10/11、Linux x86_64 / ARM64。无需账号，不要求局域网，配对一次之后没有别的设置。 ## Notes - Mouse Without Borders --- > **Source**: https://www.uniclipboard.app/compare/kde-connect > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-09 > **Last updated**: 2026-06-01 > **Description**: KDE Connect is a beloved Linux + Android companion that does many things, including clipboard. UniClipboard is the open-source, end-to-end encrypted alternative built only for clipboard — native on macOS, Windows, and Linux, with searchable history and no VPN required. *Compare · UniClipboard vs KDE Connect* # UniClipboard vs KDE Connect **KDE Connect is a great Linux + phone bridge. UniClipboard is what you reach for when clipboard is the only thing you wanted to share.** KDE Connect is a beloved cross-device companion from the KDE community — clipboard, files, notifications, media controls, presentation remote, all in one. UniClipboard does only one of those jobs, but does it across all three desktop platforms natively, over the public internet without a VPN, and with end-to-end encrypted clipboard history searchable on every device. The two are not really competitors and run together happily. ## The 30-second answer. - KDE Connect is a multi-purpose bridge: clipboard, files, notifications, ringer, remote input, media controls. - Its first-class platforms are Linux and Android. Windows and macOS ports exist but are not equivalent in polish. - By default it requires the same LAN — the common cross-network workaround is to layer Tailscale on top. - UniClipboard is clipboard-only, native on macOS, Windows, and Linux, with no LAN or VPN requirement. - It uses peer-to-peer with NAT hole-punching across networks, falling back to an encrypted relay that only sees ciphertext. - Both are free and open source. UniClipboard adds a searchable, end-to-end encrypted clipboard history per device. ## What KDE Connect does well KDE Connect has been around for over a decade and earned its reputation. One install gets you clipboard sync, file transfer, phone notifications on the desktop, ringer-on-lost-phone, presentation remote, media keys that follow focus, and a touchpad mode for your phone. On the same Wi-Fi, mDNS-based auto-discovery is delightful — devices just see each other. For Linux laptop plus Android phone, hard to beat. And if you already run Tailscale across your machines, KDE Connect happily rides over it for cross-network use. ## What UniClipboard adds on top UniClipboard solves a narrower problem on purpose: copy on one desktop, paste on another, with full-text searchable history on every device — even when those desktops sit on different networks and you don't want to set up a VPN. It runs natively on macOS, Windows, and Linux as a first-class peer; clipboard content is encrypted on the source device with XChaCha20-Poly1305 AEAD, the relay (when used at all) only sees ciphertext, and the local history index is encrypted at rest. No mouse takeover, no notifications, no file-share daemon. Just the clipboard. ## Feature-by-feature comparison. *Comparison reflects publicly documented behaviour as of 2026-05.* | Feature | UniClipboard | KDE Connect | | --- | --- | --- | | Primary scope | Clipboard sync only | Clipboard, files, notifications, remote input, media controls | | First-class platforms | macOS, Windows, Linux (native); iOS (public beta) + Android | Linux + Android + iOS; Windows port and an unofficial macOS build | | Cross-network without VPN | P2P + NAT hole-punching + encrypted relay fallback | Same LAN by default; cross-network typically needs Tailscale or similar | | Pairing | Short-lived public-key invitation code | Local network discovery + accept on each device | | Clipboard history | Encrypted searchable history on every paired device | Latest clip only — by design | | File transfer | Text, images, files (streaming for large files) | File send between paired devices | | Encryption | XChaCha20-Poly1305 AEAD end-to-end | TLS between paired devices | | Source code | AGPL-3.0 | GPL-2.0+ (KDE community) | | Account | None — public-key device pairing | None | | Price | Free | Free | ## If you want clipboard-only across the public internet. 1. Install UniClipboard on each desktop — macOS, Windows, or Linux. Keep KDE Connect installed if you use it for phone-to-laptop file transfer or notifications; the two never touch the same surface. 2. Pair the desktops with a short-lived invitation code. No LAN required, no Tailscale required, no account required. 3. Carry on with ⌘C / Ctrl-C and ⌘V / Ctrl-V exactly as before. Clipboard history follows automatically across paired desktops, encrypted on disk on each one. ## When to pick what. If you live mostly on Linux + Android and want one tool that does clipboard, files, and notifications, KDE Connect is the right answer — full stop. Pick UniClipboard when clipboard is specifically the thing you want to share across desktops, when those desktops include macOS or Windows as first-class peers, when the machines are on different networks and you don't want to layer a VPN, or when you want a searchable encrypted clipboard history on every device. The two are not really competitors — many people run KDE Connect for phone↔laptop and UniClipboard for desktop↔desktop, side by side. ## Frequently asked. ### I already use KDE Connect with Tailscale across my machines — why switch? If that setup works for you, don't. UniClipboard is for people who don't want to operate a VPN just to share their clipboard, want first-class macOS and Windows desktop apps, or want a searchable encrypted clipboard history per device. If KDE Connect + Tailscale already gives you what you need, there's nothing to fix. ### Does UniClipboard play nicely with KDE Plasma on Linux? Yes. UniClipboard runs as a regular desktop app on Linux (x86_64 and ARM64), integrates with the system clipboard like any native app, and does not interact with KDE Connect's surface. You can run both. ### Why is KDE Connect's macOS or Windows support not enough? KDE Connect's heart and roadmap are on Linux + Android. The Windows port works, and there are community macOS builds, but they are not held to the same polish as the Linux + Android pair. UniClipboard treats macOS, Windows, and Linux as equally first-class — same release cadence, same features, same encryption. ### Can I use both at the same time? Yes, and many people do. KDE Connect handles phone-to-laptop tasks like ringing your phone, mirroring notifications, and sending a file from Android. UniClipboard handles clipboard sync between desktops. They never touch the same surface. ### Why narrow this down to clipboard-only? Because that is what most people who land here actually need. Clipboard sync is the one piece of cross-device tooling you reach for dozens of times a day. KVM and notification-bridging tools are nice, but they come with mouse takeover, file-drop hijack, and notification permissions that some people explicitly do not want. Doing one thing well lets us audit and harden it without compromising on platform reach. ### Does UniClipboard sync notifications, ringer, or media controls like KDE Connect does? No, by design. If you want those features, KDE Connect remains the right choice. UniClipboard only ever moves clipboard content — encrypted at the source, decrypted only on your other paired devices. ## Free, open source, ready to install. macOS 12+, Windows 10/11, Linux x86_64 / ARM64. No account, no VPN, no setup beyond pairing. ## Notes - KDE Connect --- > **Source**: https://www.uniclipboard.app/zh/compare/kde-connect > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-09 > **Last updated**: 2026-06-01 > **Description**: KDE Connect 是 Linux + Android 用户喜爱的一站式工具，功能涵盖剪切板、文件、通知等。UniClipboard 是只做剪切板同步的开源、端到端加密替代——macOS、Windows、Linux 三平台原生，自带可搜索历史，不需要 VPN。 *对比 · UniClipboard vs KDE Connect* # UniClipboard vs KDE Connect **KDE Connect 是 Linux 配手机的好搭档。UniClipboard 是「我只想要剪切板」的那个工具。** KDE Connect 是 KDE 社区出品的多用途跨设备桥梁——剪切板、文件、通知、媒体控制、演示遥控，一个安装包全包。UniClipboard 只做其中一件事，但在 macOS、Windows、Linux 三个桌面平台都是原生一等公民，走公网也不需要 VPN，每台设备都有端到端加密、可搜索的剪切板历史。两者其实不算竞争对手，可以同时用。 ## 30 秒看懂区别。 - KDE Connect 是一站式工具：剪切板、文件、通知、振铃、远程输入、媒体控制，全都有。 - 它的一等平台是 Linux 和 Android。Windows 和 macOS 也有移植，但完成度不一样。 - 默认要求设备在同一局域网——常见的跨网方案是再叠一层 Tailscale。 - UniClipboard 只做剪切板，macOS、Windows、Linux 都是原生应用，不需要局域网，也不需要 VPN。 - 跨网时走 P2P + NAT 打洞，连不通时回退到加密中继，中继也只能看到密文。 - 两者都免费且开源。UniClipboard 额外提供每台设备本地加密、可搜索的剪切板历史。 ## KDE Connect 真正擅长的事 KDE Connect 已经做了十多年，名声不是白来的。一次安装就能用上：剪切板同步、文件互传、手机通知镜像到桌面、丢手机一键振铃、演示遥控、跟随焦点的媒体快捷键，甚至把手机当触摸板。同一 Wi-Fi 下基于 mDNS 自动发现，设备就互相看见——非常顺手。Linux 笔记本配 Android 手机这套场景，几乎没有更好的选择。如果你已经在所有机器上跑 Tailscale，KDE Connect 也能直接跑在它上面，跨网就不是问题。 ## UniClipboard 增加的部分 UniClipboard 故意只解决一个问题：在一台桌面上复制，在另一台桌面上粘贴；每台设备都有可搜索的剪切板历史；即使两台机器不在一个网络里，也不用为此架 VPN。macOS、Windows、Linux 三个平台都是一等公民，不存在「主力 + 移植」的区别。剪切板内容在源设备就完成 XChaCha20-Poly1305 AEAD 加密，中继（如果走中继）只能看到密文，本地历史索引在磁盘上同样加密。不抢鼠标、不接管通知、不替你传文件——只做剪切板。 ## 逐项对比。 *对比基于 2026-05 时各自公开文档的行为。* | 维度 | UniClipboard | KDE Connect | | --- | --- | --- | | 主要范围 | 只做剪切板同步 | 剪切板、文件、通知、远程输入、媒体控制 | | 一等平台 | macOS、Windows、Linux（原生）；iOS（公测）+ Android | Linux + Android + iOS；Windows 移植与非官方 macOS 版 | | 不用 VPN 跨网 | P2P + NAT 打洞 + 加密中继回退 | 默认同局域网；跨网通常需要 Tailscale 等 | | 配对 | 短期有效的公钥邀请码 | 本地网络发现，每台设备点同意 | | 剪切板历史 | 每台设备本地加密、可搜索 | 只有最新一条——刻意如此 | | 文件传输 | 文本、图片、文件（大文件流式） | 配对设备之间发文件 | | 加密 | XChaCha20-Poly1305 AEAD 端到端 | 配对设备之间走 TLS | | 源代码许可证 | AGPL-3.0 | GPL-2.0+（KDE 社区） | | 是否需要账号 | 不需要——公钥配对 | 不需要 | | 价格 | 免费 | 免费 | ## 想要走公网、只同步剪切板的几步操作。 1. 在每台桌面上装 UniClipboard——macOS、Windows、Linux 都行。如果你还在用 KDE Connect 做手机到电脑的文件、通知，留着就好——两者从不抢同一块功能。 2. 用短期邀请码配对桌面。不要求局域网，不要求 Tailscale，不要求账号。 3. 继续用 ⌘C / Ctrl-C 和 ⌘V / Ctrl-V，跟原来一样。剪切板历史会自动跟着走，每台设备本地都加密。 ## 什么时候选哪个。 如果你主要在 Linux + Android 上活动，想要一个工具同时管剪切板、文件、通知，KDE Connect 就是答案，不用纠结。选 UniClipboard 的场景是：你只是想在多台桌面之间共享剪切板；这些桌面里有 macOS 或 Windows，希望它们都是一等公民；机器跨网，但你不想为此专门架 VPN；想要每台设备都有可搜索的加密剪切板历史。两者并不真正竞争——很多人 KDE Connect 管手机和电脑、UniClipboard 管桌面之间，并行使用。 ## 常见问题。 ### 我已经在用 KDE Connect + Tailscale 了，为什么还要换？ 如果这套用着顺手，就别换。UniClipboard 是给「不想为了同步剪切板专门架一层 VPN」、「希望 macOS / Windows 上有一等公民桌面应用」、「想要每台设备都有可搜索加密历史」的人准备的。你现有的方案够用，就没必要折腾。 ### UniClipboard 在 KDE Plasma 上能正常用吗？ 可以。UniClipboard 是 Linux 上的普通桌面应用（x86_64 和 ARM64 都有），和系统剪切板一样集成，不会去碰 KDE Connect 的功能。两个一起跑没问题。 ### KDE Connect 的 macOS / Windows 版不是已经有了吗？ KDE Connect 的核心和路线图重心都在 Linux + Android。Windows 移植可用，macOS 有社区版，但完成度和 Linux + Android 不是一个量级。UniClipboard 把 macOS、Windows、Linux 看作完全平等的三方——同步发版、同步功能、同套加密。 ### 两个能同时用吗？ 能，而且很多人这么做。KDE Connect 负责手机和电脑之间的事——振铃、通知镜像、从 Android 发文件。UniClipboard 负责桌面与桌面之间的剪切板同步。两者互不干扰。 ### 为什么只做剪切板这么窄？ 因为这是最高频的需求。剪切板每天会用几十次，KVM、通知桥这些虽好，但会带来鼠标接管、文件拖放接管、通知权限这些副作用，而有些人就是不想要。把一件事做透，才能在加密、跨平台覆盖上不打折扣。 ### UniClipboard 会同步通知、振铃、媒体控制吗？ 不会，刻意如此。这些是 KDE Connect 擅长的领域，需要的人继续用 KDE Connect 就好。UniClipboard 只搬剪切板内容，源设备加密，只在配对的其它设备上解密。 ## 免费、开源，装好就能用。 macOS 12+、Windows 10/11、Linux x86_64 / ARM64。无需账号，不用 VPN，配对一次之后没有别的设置。 ## Notes - KDE Connect --- > **Source**: https://www.uniclipboard.app/compare/clipcascade > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: Compare ClipCascade and UniClipboard for open-source clipboard sync. Learn when self-hosting is worth it, and when serverless P2P clipboard sync is the cleaner path. *Comparison* # ClipCascade alternative: open-source clipboard sync without running a server **ClipCascade is great when you want to own the server. UniClipboard is built for private clipboard sync when you do not want a server at all.** UniClipboard is an open-source, end-to-end encrypted ClipCascade alternative for macOS, Windows, and Linux that syncs clipboards over serverless P2P instead of requiring you to operate a clipboard server. ## What you need to know in 30 seconds - ClipCascade is open source and supports self-hosting through Docker or a Java 21 server JAR. - UniClipboard is open source and serverless by default: devices pair directly and sync over P2P. - Both projects care about privacy; the practical difference is operational responsibility. - ClipCascade has a longer-established Android client; UniClipboard now ships mobile too — an iOS public beta on TestFlight and a native Android app — alongside its macOS, Windows, and Linux desktop apps. - UniClipboard adds encrypted local history and encrypted full-text search for private searchable clipboard history. - Choose ClipCascade if you want to own the clipboard server; choose UniClipboard if you want to stop needing one. ## When self-hosting earns its keep ClipCascade makes sense when you want a central service you control. You can deploy the server yourself, put it behind your own domain, decide whether signup is enabled, tune message-size limits, configure CORS, run it through Docker Compose, and keep the operational model familiar: clients talk to your server, your server coordinates sync. That is a perfectly reasonable trade if you already operate a home lab or VPS, want a web dashboard, need Android support today, or explicitly prefer server-side control. ## When you don't want to be on call for your own clipboard A clipboard tool should feel boring: copy on one machine, paste on another. If the service requires a container, persistent volume, exposed port, reverse proxy, credentials, signup policy, update monitoring, and a server that must stay alive, your clipboard has quietly become another production system. UniClipboard removes that server from the loop: devices pair directly, encrypted traffic can fall back through an untrusted relay when direct P2P fails, and the relay cannot read clipboard payloads. ## UniClipboard vs ClipCascade *ClipCascade details are based on the official Sathvik-Rao/ClipCascade README, which documents Docker/JAR server deployment, a public community server, end-to-end encryption, server-based sync, P2P mode, Android support, and text/image/file clipboard support.* | Feature | UniClipboard | ClipCascade | | --- | --- | --- | | Source availability | Open source | Open source | | Primary sync model | Serverless P2P between paired devices | Server-based sync, with P2P mode available | | Requires running your own server | No | Usually yes for self-hosted use; public community server also exists | | Account required | No UniClipboard cloud account | Account/login model for server use | | End-to-end encryption | Yes | Yes, according to the ClipCascade README | | Relay/server can read clipboard content | No; payloads are encrypted before transport | Designed around encrypted sync; verify exact behavior against ClipCascade configuration/source | | Platforms | macOS, Windows, Linux; iOS (public beta) + Android | Windows, macOS, Linux, Android | | Text, image, and file sync | Yes | Yes | | Encrypted local history | Yes | Not clearly documented in the README | | Encrypted full-text search | Yes | Not documented as a core feature | | Web dashboard | No | Yes | | Self-hosting control | Not the default model | Strong fit | | Zero deployment | Yes | No, unless you use the public community server | | Best fit | Users who want private clipboard sync with no infrastructure | Users who want to own and operate the sync server | ## Migrating from ClipCascade to UniClipboard 1. Install UniClipboard on each desktop device where clipboard sync matters most. 2. Pair devices directly by generating a pairing code on one device and entering it on another. 3. Test the core path by copying text, then an image or file if that is part of your workflow. 4. Verify encrypted history and search with realistic snippets such as commands, URLs, and notes. 5. Keep ClipCascade running briefly so you can catch platform or workflow gaps before removing it. 6. Once UniClipboard has handled your normal day, stop the ClipCascade service and close any exposed ports you no longer need. ## ClipCascade is for owning a clipboard server. UniClipboard is for not needing one. Use ClipCascade if self-hosting is part of the requirement: it gives you a server you can run, inspect, configure, and place under your own operational control. Use UniClipboard if your actual requirement is private clipboard sync without trusting a closed cloud and without operating a server. It keeps the open-source and end-to-end encrypted parts, then removes the deployment burden. ## Common questions about ClipCascade and UniClipboard ### Is UniClipboard less private because it is not self-hosted? No. Self-hosting and privacy overlap, but they are not the same thing. UniClipboard’s privacy model is based on end-to-end encryption and device pairing. Clipboard content is encrypted before it crosses the network, and relays are treated as untrusted transport. ### What does ClipCascade self-hosting give me that UniClipboard does not? A server you control. That can be useful for centralized account management, a web dashboard, explicit server-side configuration, and a familiar deployment model. UniClipboard intentionally does not replicate that whole server-control surface because its goal is zero-infrastructure sync. ### Does UniClipboard support data sovereignty? Yes, in the practical clipboard-content sense: plaintext stays on your devices, and sync payloads are encrypted end to end. But if your policy specifically requires operating every network component yourself, ClipCascade’s self-hosted server model may fit that requirement better today. ### How does NAT traversal work in UniClipboard? UniClipboard uses P2P networking so devices try to connect directly across networks. When direct connection is not possible, encrypted relay fallback can move bytes between devices. The important part: encryption is independent of the transport, so the relay is not trusted with clipboard content. ### Is encryption equivalent between UniClipboard and ClipCascade? Both projects claim end-to-end encrypted clipboard sync. The deeper question is implementation detail: key management, local storage, transport boundaries, and what metadata each server or relay can observe. UniClipboard’s position is that the transport layer should never be able to decrypt payloads, and local history should be encrypted too. ### Does UniClipboard have the same license as ClipCascade? No. UniClipboard uses AGPL-3.0. The reason is deliberate: for a privacy product, AGPL prevents someone from turning a modified hosted version into a closed-source service while weakening the privacy guarantees privately. Always check each project’s repository for the current license before building on it. ## Open-source clipboard sync, minus the server chores If you want open-source clipboard sync but do not want to maintain a clipboard server, try UniClipboard. Your clipboard should follow your devices — not become another service to babysit. ## Notes - ClipCascade - self-hosted clipboard sync - open-source clipboard sync --- > **Source**: https://www.uniclipboard.app/zh/compare/clipcascade > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: 对比 ClipCascade 和 UniClipboard：什么时候自托管值得，什么时候无服务器 P2P 剪贴板同步才是更省心的选择。 *对比* # ClipCascade 替代方案：不用跑服务器的开源剪贴板同步 **ClipCascade 适合想拥有服务器的人。UniClipboard 适合想要私有剪贴板同步、但不想维护服务器的人。** UniClipboard 是一个面向 macOS、Windows 和 Linux 的开源端到端加密 ClipCascade 替代方案，通过无服务器 P2P 同步剪贴板，而不是要求你运行剪贴板服务器。 ## 30 秒看懂差别 - ClipCascade 开源，并支持通过 Docker 或 Java 21 JAR 自托管服务器。 - UniClipboard 开源，并默认无服务器：设备直接配对，通过 P2P 同步。 - 两者都重视隐私；真正差别是你是否愿意承担运维责任。 - ClipCascade 的 Android 客户端更成熟；UniClipboard 现在也有移动端——iOS 在 TestFlight 公测、Android 提供原生 App——并覆盖 macOS、Windows、Linux 桌面端。 - UniClipboard 有加密本地历史和加密全文搜索，不只是同步最新一条剪贴板。 - 如果你想拥有剪贴板服务器，选 ClipCascade；如果你不想再需要剪贴板服务器，选 UniClipboard。 ## 自托管什么时候值得 ClipCascade 适合你想要一个自己控制的中心服务：自己部署服务器，挂自己的域名，决定是否开放注册，调整消息大小限制，配置 CORS，用 Docker Compose 跑起来，再让所有客户端连接它。如果你已经有 homelab 或 VPS，想要 Web dashboard，需要 Android 客户端，或者明确偏好服务端控制，这个模型很合理。 ## 什么时候你不该为剪贴板值班 理想的剪贴板工具应该很无聊：这台机器复制，那台机器粘贴。如果它要求你维护容器、持久化目录、开放端口、反向代理、登录凭据、注册策略、更新监控，以及一台必须活着的服务器，那你的剪贴板其实已经变成一个小型生产系统。UniClipboard 把服务器从链路里拿掉：设备直接配对，直连失败时可使用不可信加密中继，中继不能读取剪贴板内容。 ## UniClipboard vs ClipCascade *ClipCascade 信息基于官方 Sathvik-Rao/ClipCascade README，其中记录了 Docker/JAR 服务端部署、公开社区服务器、端到端加密、服务器同步、P2P 模式、Android 支持，以及文本/图片/文件剪贴板支持。* | 功能 | UniClipboard | ClipCascade | | --- | --- | --- | | 是否开源 | 开源 | 开源 | | 主要同步模型 | 配对设备之间的无服务器 P2P | 服务器同步为主，也有 P2P 模式 | | 是否需要自己跑服务器 | 不需要 | 自托管场景通常需要；也有公开社区服务器 | | 是否需要账号 | 不需要 UniClipboard 云账号 | 服务器使用中有登录/账号模型 | | 端到端加密 | 支持 | README 声称支持 | | 中继/服务器能否读取剪贴板 | 不能；传输前已加密 | 设计目标是加密同步；具体行为建议按配置和源码核验 | | 平台 | macOS、Windows、Linux；iOS（公测）+ Android | Windows、macOS、Linux、Android | | 文本、图片、文件同步 | 支持 | 支持 | | 加密本地历史 | 支持 | README 未明确写成核心功能 | | 加密全文搜索 | 支持 | 未看到作为核心功能文档化 | | Web dashboard | 无 | 有 | | 自托管控制权 | 不是默认模型 | 很适合 | | 零部署 | 是 | 否，除非使用公开社区服务器 | | 最适合 | 想要隐私同步，但不想维护基础设施的人 | 想拥有并运行同步服务器的人 | ## 从 ClipCascade 迁移到 UniClipboard 1. 在每台需要剪贴板同步的桌面设备上安装 UniClipboard。 2. 在第一台设备生成配对码，在第二台设备输入，直接完成设备配对。 3. 先测试文本复制粘贴，再测试图片或文件。 4. 复制一些真实内容，比如命令、URL、笔记，确认加密历史和搜索符合你的工作流。 5. 短期保留 ClipCascade，不要第一天就拆服务器，先并行跑一小段时间。 6. 当 UniClipboard 顺利覆盖日常使用后，再停止 ClipCascade 服务并关闭不再需要的端口。 ## ClipCascade 适合拥有剪贴板服务器；UniClipboard 适合不再需要它。 如果自托管本身就是需求，选 ClipCascade：它给你一个可以运行、检查、配置、放进自己运维体系里的服务器。如果你的真实需求是不信闭源云、想要开源和端到端加密、但不想跑服务器，那么 UniClipboard 更合适。它保留开源和加密，移除部署负担。 ## 关于 ClipCascade 和 UniClipboard 的常见问题 ### UniClipboard 不是自托管，会不会更不隐私？ 不会。自托管和隐私有关，但不是同一件事。UniClipboard 的隐私模型来自端到端加密和设备配对。剪贴板内容在离开设备前加密，中继只是不可信传输层。 ### ClipCascade 自托管给了我什么 UniClipboard 没有的东西？ 一个你控制的服务器。这对中心化账号管理、Web dashboard、服务端配置、传统部署模型都有价值。UniClipboard 没有复制完整服务器控制面，因为它的目标是零基础设施同步。 ### UniClipboard 支持数据主权吗？ 如果你关心的是剪贴板明文内容，支持：明文留在你的设备上，同步内容端到端加密。但如果你的合规要求是所有网络组件都必须由你运行，ClipCascade 的自托管服务器模型目前更匹配。 ### UniClipboard 如何处理 NAT 穿透？ UniClipboard 使用 P2P 网络，让设备尽量直接跨网络连接。直连失败时，可以通过加密中继传输字节。重点是：加密独立于传输层，所以中继不被信任，也不能读取剪贴板内容。 ### UniClipboard 和 ClipCascade 的加密是等价的吗？ 两者都声称支持端到端加密剪贴板同步。真正要看的细节是密钥管理、本地存储、传输边界，以及服务器或中继能看到哪些元数据。UniClipboard 的立场是：传输层永远不能解密 payload，本地历史也应该加密。 ### UniClipboard 和 ClipCascade 许可证一样吗？ 不一样。UniClipboard 使用 AGPL-3.0。这是有意选择：对隐私产品来说，AGPL 可以防止别人把修改版做成闭源托管服务，同时私下削弱隐私保证。具体使用前仍应检查各项目仓库里的当前许可证。 ## 开源剪贴板同步，但不用维护服务器 如果你想要开源剪贴板同步，但不想维护剪贴板服务器，可以试试 UniClipboard。剪贴板应该跟着你的设备走，而不是变成又一个要照看的服务。 ## Notes - ClipCascade - 自托管剪贴板同步 - 开源剪贴板同步 --- > **Source**: https://www.uniclipboard.app/compare/localsend > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: A practical UniClipboard vs LocalSend comparison for users choosing between open-source local file transfer and encrypted cross-device clipboard sync. *Comparison* # LocalSend Alternative for Clipboard Sync: UniClipboard vs LocalSend **LocalSend is one of the best open-source tools for sending files to nearby devices. It is fast, private, cross-platform, and refreshingly simple: install it on two devices on the same local network, pick a file or message, and send it without uploading through a cloud service.** But if you are comparing LocalSend with UniClipboard, the real question is not “which app is better?” It is: do you want to send something once, or do you want your clipboard to stay in sync? LocalSend is excellent for intentional local transfer. UniClipboard is built for continuous cross-device clipboard sync: copy on one machine, paste on another, with encrypted history, search, and automatic sync across macOS, Windows, and Linux. ## What you need to know - Use LocalSend when you want an AirDrop-like open-source file sharing app for nearby devices. - Use UniClipboard when you want a clipboard that follows you across desktop machines. - LocalSend is LAN-first. It works without internet and keeps transfers on the local network. - UniClipboard is cross-network. It tries direct P2P first, then can fall back to encrypted relay when devices are not on the same Wi-Fi. - LocalSend's mobile and Fire OS apps are more established for file transfer. - UniClipboard focuses on desktop productivity across macOS, Windows, and Linux, with clipboard history, full-text search, and a headless CLI. - They are complementary, not enemies. LocalSend is for “send this file.” UniClipboard is for “my clipboard should just be available everywhere.” ## The key difference: transfer app vs clipboard layer LocalSend is designed around explicit transfer. You open the app, select files, photos, documents, or text, choose a nearby device, and send. That model is great because it is obvious and controlled. Nothing magical happens in the background unless you ask for it. UniClipboard is designed around a different mental model: the clipboard itself becomes cross-platform. You copy a command on your Mac and paste it into a Windows machine. You copy a URL on Linux and search for it later on macOS. You copy an image or file and let it sync to paired desktop devices without manually opening a file-transfer flow every time. ## Where LocalSend is clearly strong LocalSend has earned its reputation. As of this draft, the project is open source, Apache-2.0 licensed, built with Flutter/Dart, and has more than 80k GitHub stars. Its website describes the product as open-source, cross-platform file sharing that works without cloud infrastructure, with support for Windows, macOS, Linux, Android, iOS, and Fire OS. That makes LocalSend a strong fit when: For local file transfer, LocalSend is probably the benchmark. Trying to pretend otherwise would be silly. ## How UniClipboard compares with LocalSend *LocalSend details are based on the official LocalSend website and README.* | Feature | UniClipboard | LocalSend | | --- | --- | --- | | Primary use case | Continuous clipboard sync | Nearby file/message transfer | | Best mental model | “Copy here, paste there” | “Pick this item and send it” | | Source availability | Open source | Open source | | License | AGPL-3.0 | Apache-2.0 | | Main desktop platforms | macOS, Windows, Linux | Windows, macOS, Linux | | Mobile platforms | iOS public beta (TestFlight) + native Android app | Android, iOS, Fire OS | | Works without internet | Yes on local/direct paths | Yes, LAN-first | | Same-Wi-Fi transfer | Direct P2P | Local network transfer | | Cross-network sync | Yes, via P2P/NAT traversal and encrypted relay fallback | Not the primary model | | Account required | No UniClipboard cloud account | No account | | Encryption model | End-to-end encrypted clipboard payloads; relay sees ciphertext | HTTPS with device-generated certificates for local transfer | | Automatic clipboard sync | Yes | No, primarily manual send | | Clipboard history | Yes, encrypted local history | Not the core product | | Full-text search | Yes, encrypted local index | Not the core product | | File transfer | Yes, through clipboard/file sync | Yes, core feature | | CLI / headless workflow | Yes, uniclip | Not the main workflow | | Best fit | Desktop users who copy/paste constantly across machines | Anyone who wants simple nearby device transfer | ## When to choose UniClipboard 1. copy a terminal command on macOS and paste it into Windows; 2. copy an error message on Linux and search for it later; 3. keep a private searchable history of copied snippets; 4. move text, images, and files through the clipboard instead of opening a transfer UI; 5. use a CLI to pipe output directly into your cross-device clipboard; ## Ready to make your clipboard cross-device? If you want an open-source AirDrop alternative, choose LocalSend. It is mature, popular, mobile-friendly, and excellent for local file sharing. If you want your clipboard to work across Mac, Windows, and Linux as if those machines belonged to one workspace, choose UniClipboard. It is built for automatic sync, encrypted history, full-text search, cross-network desktop workflows, and no-account device pairing. The short version: LocalSend helps you send files. UniClipboard helps you stop thinking about sending clipboard items at all. ## Common questions ### Is UniClipboard a LocalSend replacement? Not exactly. UniClipboard can sync text, images, and files through the clipboard, but it is not primarily a nearby file-sharing app. It is a cross-device clipboard sync tool with history and search. ### Is LocalSend better if I need mobile support? LocalSend's mobile apps are more established for file transfer. UniClipboard now ships mobile too — an iOS public beta on TestFlight and a native Android app — but its focus is clipboard sync rather than nearby file sharing. ### Does LocalSend work without internet? Yes. LocalSend’s core pitch is local-network sharing without internet or cloud servers. ### Does UniClipboard work when devices are not on the same Wi-Fi? Yes. UniClipboard is designed for direct local connections when possible, NAT traversal across networks, and encrypted relay fallback when direct connection fails. ### Which one is more private? For nearby local transfer, LocalSend’s no-cloud local-network model is hard to beat. For cross-network clipboard sync, UniClipboard’s end-to-end encryption and untrusted-relay model is the better fit. Privacy is not one checkbox; it depends on the network and workflow. ### Why does UniClipboard use AGPL-3.0? AGPL-3.0 keeps modified networked versions open as well. For privacy software, that matters: users should be able to inspect changes that affect trust boundaries. ## Ready to make your clipboard cross-device? Open-source encrypted clipboard sync across Mac, Windows, and Linux — with history, search, and no cloud account. ## Notes - UniClipboard - LocalSend - clipboard sync --- > **Source**: https://www.uniclipboard.app/zh/compare/localsend > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: UniClipboard 与 LocalSend 实用对比：开源局域网文件传输，还是跨设备加密剪贴板自动同步。 *对比* # LocalSend 替代方案：UniClipboard vs LocalSend **LocalSend 是最好的开源局域网文件传输工具之一。它快、私密、跨平台，也足够简单：在两台同一局域网的设备上安装，选择文件或消息，发送，不经过云服务。** 但如果你在比较 LocalSend 和 UniClipboard，真正的问题不是“谁更好”，而是：你是想偶尔发送一个东西，还是想让剪贴板一直同步？ LocalSend 很适合主动传输。UniClipboard 则是为持续的跨设备剪贴板同步而做：在一台机器复制，在另一台机器粘贴，并且支持加密历史、全文搜索，以及 macOS、Windows、Linux 之间的自动同步。 ## 你需要知道的事 - 如果你想要一个开源 AirDrop 替代品，用 LocalSend。 - 如果你想要一个跨设备同步的剪贴板，用 UniClipboard。 - LocalSend 优先服务局域网。 它不需要互联网，传输尽量留在本地网络里。 - UniClipboard 服务跨网络工作流。 它会优先直连 P2P，不在同一 Wi-Fi 时可通过 NAT 穿透和加密中继兜底。 - LocalSend 的移动端和 Fire OS App 在文件传输上更成熟。 - UniClipboard 更偏桌面生产力，覆盖 macOS、Windows、Linux，并提供剪贴板历史、全文搜索和 headless CLI。 - 它们不是敌人。 LocalSend 适合“把这个文件发过去”；UniClipboard 适合“我的剪贴板本来就应该到处可用”。 ## 核心差别：传输工具 vs 剪贴板层 LocalSend 的模型是显式传输。你打开 app，选择文件、照片、文档或文本，选择附近设备，然后发送。这个模型很好，因为它清晰、可控：你什么时候发、发给谁、发什么，都很明确。 UniClipboard 的模型不一样：它让剪贴板本身跨平台。 你可以在 Mac 上复制一条命令，到 Windows 上粘贴；在 Linux 上复制一个 URL，之后在 macOS 上搜索出来；复制图片或文件，让它同步到已配对的桌面设备，而不是每次都手动打开一个传输流程。 ## LocalSend 强在哪里 LocalSend 的口碑不是白来的。根据官方信息，它是开源、Apache-2.0 许可、基于 Flutter/Dart 的跨平台应用；截至本文草稿，它在 GitHub 上有超过 80k stars。官网把它定位为无需云、支持 Windows、macOS、Linux、Android、iOS、Fire OS 的跨平台文件分享工具。 如果你的需求是下面这些，LocalSend 很合适： 在局域网文件传输这件事上，LocalSend 基本就是标杆。硬黑它没意思，也不可信。 ## UniClipboard 与 LocalSend 如何对比 *LocalSend 信息基于其官网和官方 README。* | 功能 | UniClipboard | LocalSend | | --- | --- | --- | | 主要用途 | 持续剪贴板同步 | 附近设备文件/消息传输 | | 心智模型 | “这里复制，那里粘贴” | “选中这个东西，发送过去” | | 是否开源 | 开源 | 开源 | | 许可 | AGPL-3.0 | Apache-2.0 | | 桌面平台 | macOS、Windows、Linux | Windows、macOS、Linux | | 移动平台 | iOS 公测（TestFlight）+ Android 原生 App | Android、iOS、Fire OS | | 无互联网可用 | 本地/直连路径支持 | 支持，局域网优先 | | 同 Wi-Fi 传输 | 直连 P2P | 局域网传输 | | 跨网络同步 | 支持，P2P/NAT 穿透 + 加密中继兜底 | 不是主要模型 | | 是否需要账号 | 不需要 UniClipboard 云账号 | 不需要账号 | | 加密模型 | 剪贴板内容端到端加密；中继只看密文 | 本地传输使用 HTTPS 和设备生成证书 | | 自动剪贴板同步 | 支持 | 不支持，主要是手动发送 | | 剪贴板历史 | 支持，加密本地历史 | 不是核心功能 | | 全文搜索 | 支持，加密本地索引 | 不是核心功能 | | 文件传输 | 支持，通过剪贴板/文件同步 | 支持，核心功能 | | CLI/headless | 支持 uniclip | 不是主要工作流 | | 最适合 | 高频跨桌面复制粘贴的人 | 需要简单局域网文件传输的人 | ## 什么时候选 UniClipboard 1. 在 macOS 复制终端命令，到 Windows 粘贴； 2. 在 Linux 复制错误信息，之后还能搜回来； 3. 保留私密、可搜索的剪贴板历史； 4. 通过剪贴板移动文本、图片和文件，而不是每次打开传输界面； 5. 用 CLI 把命令输出直接放进跨设备剪贴板； ## 准备让剪贴板跨设备了吗？ 如果你要的是开源 AirDrop 替代品，选 LocalSend。它成熟、流行、移动端友好，非常适合本地文件分享。 如果你要的是让 Mac、Windows、Linux 像同一个工作区一样共享剪贴板，选 UniClipboard。它关注自动同步、加密历史、全文搜索、跨网络桌面工作流，以及无需账号的设备配对。 一句话：LocalSend 帮你发送文件；UniClipboard 让你不必再思考“怎么发送剪贴板内容”。 ## 常见问题 ### UniClipboard 是 LocalSend 替代品吗？ 不完全是。UniClipboard 可以通过剪贴板同步文本、图片和文件，但它不是纯粹的附近文件分享 app。它是带历史和搜索的跨设备剪贴板同步工具。 ### 如果我需要移动端，LocalSend 更好吗？ LocalSend 目前的移动端对文件传输更成熟。UniClipboard 现在也有移动端——iOS 在 TestFlight 公测、Android 提供原生 App——但重点是剪贴板同步，而不是附近文件分享。 ### LocalSend 不联网也能用吗？ 可以。LocalSend 的核心卖点就是无需互联网和云服务器的局域网分享。 ### UniClipboard 不在同一 Wi-Fi 下也能用吗？ 可以。UniClipboard 设计上会优先本地直连，跨网络时尝试 NAT 穿透，直连失败则用加密中继兜底。 ### 哪个更隐私？ 如果是附近设备之间的局域网传输，LocalSend 的无云本地模型很强。如果是跨网络剪贴板同步，UniClipboard 的端到端加密和不可信中继模型更合适。隐私不是一个勾选框，要看网络和使用场景。 ### 为什么 UniClipboard 用 AGPL-3.0？ AGPL-3.0 要求网络服务形态的修改版本也保持开放。对隐私软件来说这很重要：用户应该能检查影响信任边界的改动。 ## 准备让剪贴板跨设备了吗？ Mac、Windows、Linux 之间的开源加密剪贴板同步：支持历史、搜索，无需云账号。 ## Notes - UniClipboard - LocalSend - 剪贴板同步 --- > **Source**: https://www.uniclipboard.app/compare/maccy > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: Maccy is the popular open-source clipboard manager for macOS — local, fast, and lovingly maintained. UniClipboard keeps that open-source posture and adds end-to-end encrypted sync to Windows and Linux. Run them side by side. *Compare · UniClipboard vs Maccy* # UniClipboard vs Maccy **Maccy is the open-source clipboard for one Mac. UniClipboard is the open-source clipboard for all your machines.** Maccy is a beloved open-source clipboard manager for macOS — local-only by design, fast, and tastefully simple. UniClipboard shares the same open-source ethos and adds what Maccy intentionally does not: end-to-end encrypted sync of clipboard content across macOS, Windows, and Linux. The two tools are happy to coexist on the same Mac, and many people run both. ## The 30-second answer. - Maccy is a local-only clipboard manager for a single Mac. UniClipboard is the cross-device extension of that idea — same open-source posture, plus sync. - Maccy is MIT-licensed; UniClipboard is AGPL-3.0. Both ship full source code and accept community contributions. - Maccy stores history on the Mac it runs on. UniClipboard keeps an end-to-end encrypted history per device and syncs new copies across paired devices. - Maccy is on the Mac App Store and via Homebrew. UniClipboard is distributed as signed, notarized direct downloads and via a Homebrew cask (Mac App Store is not currently supported). - You can run both side-by-side. Maccy keeps doing what it does on the Mac; UniClipboard adds Windows and Linux to the picture. - If you only ever use one Mac, Maccy alone is plenty. The moment a second machine joins your workflow, UniClipboard is the upgrade path. ## What Maccy does well Maccy is the kind of tool open-source enthusiasts love: small, fast, native Swift, opinionated in the right places. It sits in the menu bar, opens with ⌘⇧C, lets you pin frequent items, search history, and filter by content type. The MIT license is friendly to anyone who wants to fork it. For a single Mac that does not need cross-device sync, Maccy is genuinely hard to beat — and recommending it for that case is the honest answer. ## What UniClipboard adds on top The thing Maccy does not do — by design — is leave the Mac. The moment you add a Windows laptop, a Linux desktop, or even a second Mac to your daily setup, the clipboard history splinters. UniClipboard is built for that case: end-to-end encrypted sync of clipboard content with XChaCha20-Poly1305 AEAD, desktop apps for macOS, Windows, and Linux, no cloud account, P2P on the same Wi-Fi with NAT hole-punching across networks, and a per-device encrypted history index. ## Maccy and UniClipboard compared. *Comparison reflects publicly documented behaviour as of 2026-05. Maccy facts verified against github.com/p0deje/Maccy.* | Feature | UniClipboard | Maccy | | --- | --- | --- | | Supported platforms | macOS, Windows, Linux (native) | macOS only | | License | AGPL-3.0 | MIT | | Cross-device sync | End-to-end encrypted sync across paired devices | Not by design — local-only on a single Mac | | Clipboard history | Encrypted local index, per-device, searchable | Local history, searchable, with pin and filters | | Distribution | Signed direct downloads + Homebrew cask (mac) + Snap (linux) | Mac App Store, Homebrew, build from source | | Pin / favorite items | Not yet — on the roadmap | Yes — first-class feature | | Account required | None — public-key device pairing | None — local-only | | Encryption | XChaCha20-Poly1305 AEAD in transit and at rest | Local storage only — no network transit to encrypt | | Price | Free | Free from source / Homebrew; paid on the Mac App Store | ## Three steps. You can keep Maccy. 1. Keep Maccy installed if you like it. UniClipboard does not interfere with Maccy's history or its keyboard shortcut — they observe the same system clipboard from different angles and coexist cleanly. 2. Install UniClipboard on your Mac and on whichever non-Mac device you want to sync with — Windows or Linux. Each installer is signed and notarized; no account, no email. 3. Pair the devices once with a short-lived invitation code. From then on, anything you copy on one device is available on the others, while Maccy continues to maintain its own local history on the Mac. ## When to pick what. If you only ever use one Mac, Maccy is the right answer — full stop. Pick UniClipboard when a second device joins the picture (Windows, Linux, or another Mac) and you want clipboard content to follow you. The two are not really competitors: Maccy is the local layer; UniClipboard is the sync layer. Many people use both. ## Frequently asked. ### Can I run Maccy and UniClipboard at the same time? Yes. They observe the same macOS clipboard and do not interfere with each other. Maccy keeps its local history; UniClipboard keeps its encrypted per-device history and syncs copies to your other devices. Many users run both. ### Does sync only go from Mac to Windows, or in both directions? Both directions. UniClipboard's clipboard is symmetric: a copy on the Windows side is available on the Mac, and vice versa. Maccy continues to record only what happens on the Mac it runs on. ### How does clipboard history retention compare? Maccy lets you configure how many items to keep, stored locally on that Mac. UniClipboard keeps an encrypted local history per device with a configurable retention window (default 30 days). The two histories are independent — Maccy does not see UniClipboard's, and vice versa. ### Is the license difference between MIT and AGPL-3.0 a problem? For end-users, no — both let you read, modify, and share the code. AGPL-3.0 only adds obligations if you modify UniClipboard and run it as a network service for others. Personal and team use is unaffected. Maccy's MIT license is more permissive for embedding in a closed-source product, but UniClipboard is a standalone app, so that distinction rarely matters in practice. ### Is UniClipboard available on the Mac App Store? Not currently. UniClipboard ships as signed, notarized direct downloads from the website, and as a Homebrew cask via brew install --cask uniclipboard/tap/uniclipboard. Maccy is on the Mac App Store (paid) and also free from Homebrew or source. If Mac App Store distribution specifically matters to you, that is still a real point in Maccy's favour today. ### Will UniClipboard be as fast as Maccy on a Mac? For local clipboard history search the two are comparable — both index locally and search in milliseconds. UniClipboard adds a network step when syncing to other devices, but the local UX on the Mac stays instant: the system clipboard updates as soon as ⌘C fires. ## The cross-device companion to your local clipboard manager. macOS 12+, Windows 10/11, Linux x86_64 / ARM64. Free, open source, end-to-end encrypted. Coexists with Maccy. ## Notes - Maccy --- > **Source**: https://www.uniclipboard.app/zh/compare/maccy > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: Maccy 是 macOS 上最受欢迎的开源剪贴板管理器——本地、轻快、专注。UniClipboard 沿用同样的开源态度，再补上 Maccy 不做的那一块：跨 Mac、Windows、Linux 的端到端加密剪贴板同步。两者可以同时装。 *对比 · UniClipboard 对 Maccy* # UniClipboard 对比 Maccy **Maccy 是为一台 Mac 做的开源剪贴板。UniClipboard 是为你所有设备做的开源剪贴板。** Maccy 是 macOS 上很受喜爱的开源剪贴板管理器——刻意只做本地、轻快、克制。UniClipboard 沿用同样的开源态度，并补上 Maccy 故意不碰的那一块：在 macOS、Windows、Linux 之间端到端加密同步剪贴板内容。两者在同一台 Mac 上可以共存——很多人就是同时用着这两个工具。 ## 30 秒看完。 - Maccy 是单台 Mac 上的本地剪贴板管理器，UniClipboard 把同样的思路延伸到了多设备——同样的开源态度，多了同步。 - Maccy 用 MIT 协议，UniClipboard 用 AGPL-3.0。两个项目都开源了完整代码，也都接受社区贡献。 - Maccy 把历史记录存在它运行的那台 Mac 上。UniClipboard 在每台设备上各自加密保存历史，并把新复制的内容同步到已配对的设备。 - Maccy 在 Mac App Store 和 Homebrew 上都能拿到。UniClipboard 通过签名、公证过的安装包直发，并提供 Homebrew cask（暂未上 Mac App Store）。 - 可以两个一起用。Maccy 在 Mac 上继续做它擅长的事，UniClipboard 把 Windows 和 Linux 也接进来。 - 如果你日常只用一台 Mac，Maccy 单独用就够了。一旦工作里出现第二台机器，UniClipboard 就是顺势的升级路径。 ## Maccy 擅长什么 Maccy 是开源圈喜欢的那种工具：体积小、运行快、原生 Swift、该克制的地方很克制。它常驻菜单栏，⌘⇧C 一下就弹出，可以钉常用条目、搜索历史、按内容类型过滤。MIT 协议对想 fork 的人也很友好。如果你只用一台 Mac、不需要跨设备同步，Maccy 真的很难被替代——这种场景下推荐 Maccy 是诚实的回答。 ## UniClipboard 在它之上加了什么 Maccy 故意不做的那件事，是离开 Mac 本机。一旦你的日常加进来一台 Windows 笔记本、Linux 台式机，甚至第二台 Mac，剪贴板历史就会被切成几段。UniClipboard 就是为这个场景而生：用 XChaCha20-Poly1305 AEAD 端到端加密同步剪贴板内容、在 macOS / Windows / Linux 上都有桌面应用、不需要任何云账号、同 Wi-Fi 走 P2P，跨网络自动 NAT 打洞，每台设备各自一份加密历史索引。 ## Maccy 和 UniClipboard 的差别。 *对比基于 2026 年 5 月公开的产品行为整理。Maccy 相关事实参照 github.com/p0deje/Maccy 仓库。* | 功能 | UniClipboard | Maccy | | --- | --- | --- | | 支持平台 | macOS / Windows / Linux 全平台 | 仅 macOS | | 开源协议 | AGPL-3.0 | MIT | | 跨设备同步 | 已配对设备之间端到端加密同步 | 刻意不做——只在单台 Mac 本地 | | 剪贴板历史 | 每台设备一份加密本地索引，可全文搜索 | 单机本地历史，可搜索、可钉、可按类型过滤 | | 分发方式 | 签名直发安装包 + Homebrew cask（mac）+ Snap（linux） | Mac App Store / Homebrew / 自行从源码构建 | | 钉条目 / 收藏 | 暂无——已在路线图中 | 支持，是核心功能 | | 是否需要账号 | 不需要——公钥配对 | 不需要——纯本地 | | 加密 | 传输与落盘均使用 XChaCha20-Poly1305 AEAD | 纯本地存储——没有网络传输需要加密 | | 价格 | 免费 | 源码 / Homebrew 免费；Mac App Store 上付费 | ## 三步。Maccy 不用卸。 1. Maccy 喜欢就接着用。UniClipboard 不会干扰 Maccy 的历史，也不冲它的快捷键——两者从不同角度观察同一个系统剪贴板，可以干净共存。 2. 在 Mac 上装 UniClipboard，并在你想同步过去的非 Mac 设备（Windows 或 Linux）上各装一份。安装包都签过名也公证过，不需要邮箱、不需要账号。 3. 用一个一次性邀请码完成配对。之后任意一台设备上复制的内容都会出现在其它已配对设备上；Maccy 继续在 Mac 上维护它自己的本地历史。 ## 怎么选。 如果你日常只用一台 Mac，Maccy 就是最合适的答案——这话不带条件。当工作里出现第二台机器（Windows、Linux 或另一台 Mac）、希望剪贴板能跟着你走时，再装上 UniClipboard。两者其实并不是竞争关系：Maccy 是本地那一层，UniClipboard 是同步那一层，很多人就是同时用着两个。 ## 常被问到的几个问题。 ### Maccy 和 UniClipboard 可以同时装吗？ 可以。两者观察的是同一个 macOS 系统剪贴板，互不干扰。Maccy 维护它本机的历史，UniClipboard 维护它每台设备各自的加密历史，并把新内容同步给已配对的设备。两者一起用是常见组合。 ### 同步只是 Mac → Windows，还是双向？ 双向。UniClipboard 的剪贴板是对称的：在 Windows 上复制的内容 Mac 这边也能粘出来，反过来一样。Maccy 仍然只记录它运行的那台 Mac 上的复制行为。 ### 历史保留时长怎么对比？ Maccy 让你设置保留多少条，存在它运行的那台 Mac 上。UniClipboard 在每台设备上各自保留一份加密的本地历史，可配置保留时长（默认 30 天）。两份历史互相独立——Maccy 看不到 UniClipboard 的，反之亦然。 ### MIT 和 AGPL-3.0 这点协议差异要紧吗？ 对终端用户而言不要紧——两个协议都允许你阅读、修改、再分发源码。AGPL-3.0 只在你魔改 UniClipboard 后把它做成对外的网络服务时才会引入额外义务，个人和团队自用都不受影响。Maccy 的 MIT 协议在嵌入闭源产品时更宽松，但 UniClipboard 是独立桌面应用，这个差异在实际使用里几乎不会触碰到。 ### UniClipboard 上 Mac App Store 了吗？ 暂时没有。UniClipboard 通过官网提供签名、公证过的安装包直发，也支持 Homebrew cask：brew install --cask uniclipboard/tap/uniclipboard。Maccy 既在 Mac App Store 付费上架，也提供 Homebrew 和源码安装的免费方式。如果你特别在意 Mac App Store 这一渠道，这一项目前仍然是 Maccy 的优势。 ### 在 Mac 上 UniClipboard 会和 Maccy 一样快吗？ 本地剪贴板历史搜索两者相当——都是本地建索引、毫秒级返回。UniClipboard 在同步到其它设备时多走了一步网络，但 Mac 本地的体验仍然是即时的：⌘C 一按系统剪贴板就更新。 ## 你本地剪贴板管理器的跨设备搭档。 macOS 12+，Windows 10/11，Linux x86_64 / ARM64。免费、开源、端到端加密。和 Maccy 互不冲突。 ## Notes - Maccy --- > **Source**: https://www.uniclipboard.app/compare/icloud-universal-clipboard > **Locale**: English > **Category**: Comparisons > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: iCloud Universal Clipboard only works between Apple devices and has no clipboard history. UniClipboard is the open-source, end-to-end encrypted alternative that covers macOS, Windows, and Linux — with searchable history, no account, and no server. *Compare · UniClipboard vs iCloud Universal Clipboard* # UniClipboard vs iCloud Universal Clipboard **Why people switch the moment a Windows or Linux machine joins the workflow.** UniClipboard is the open-source, cross-platform alternative to Apple's iCloud Universal Clipboard. It ships signed desktop apps for macOS, Windows, and Linux (built on Rust + Tauri), keeps a searchable end-to-end encrypted history, and pairs devices without any cloud account. iCloud Universal Clipboard, by contrast, only syncs between Apple devices, has no clipboard history, and its encryption is closed-source. ## The 30-second answer. - iCloud Universal Clipboard only works between Apple devices (Mac, iPhone, iPad). - It has no clipboard history — you only get the most recent copy. - UniClipboard ships desktop apps for macOS, Windows, and Linux. - UniClipboard keeps a searchable, end-to-end encrypted clipboard history on every device. - Both products are free. UniClipboard is open source under AGPL-3.0 and the encryption is auditable. - iCloud requires an Apple ID. UniClipboard requires no account — devices pair via public-key exchange. ## When iCloud Universal Clipboard works fine If your daily workflow lives entirely inside the Apple ecosystem — Mac plus iPhone plus iPad — and you never need to find something you copied an hour ago, iCloud Universal Clipboard is a solid zero-configuration option. Apple ships it with the operating system. It Just Works as long as your devices are signed into the same Apple ID, on the same Wi-Fi, with Bluetooth enabled, and within roughly ten metres of each other. ## When you need UniClipboard instead The moment a non-Apple device enters the picture — a Windows laptop for work, a Linux server for development, a desktop you built yourself — iCloud Universal Clipboard is no longer an option. The same is true if you want to find that snippet you copied two hours ago, copy text between rooms over different Wi-Fi networks, or audit the encryption yourself before trusting it with a password. UniClipboard is built for these cases: open-source code, signed desktop apps for macOS, Windows, and Linux (Rust + Tauri), end-to-end encryption with keys that never leave your devices, and an encrypted local history index searchable in milliseconds. ## Feature-by-feature comparison. *Comparison reflects publicly documented behaviour as of 2026-05.* | Feature | UniClipboard | iCloud Universal Clipboard | | --- | --- | --- | | Supported platforms | macOS, Windows, Linux (native) | macOS and iOS only | | Cross-network sync | P2P + NAT hole-punching + encrypted relay fallback | Same Wi-Fi proximity only | | Clipboard history | Searchable, encrypted at rest | No history — only the latest copy | | Encryption | XChaCha20-Poly1305 AEAD, open source | End-to-end, closed source | | Source code | AGPL-3.0, fully auditable | Proprietary | | Account required | None — public-key device pairing | Apple ID required | | File transfer | Text, images, and files (streaming for large files) | Text and images only | | CLI / scripting | Headless uniclip CLI for SSH, tmux, scripts | Not supported | | Price | Free | Free | ## How to move from iCloud Universal Clipboard. 1. Install UniClipboard on each device — macOS, Windows, or Linux. Each installer is signed and works alongside iCloud, so you don't need to disable anything. 2. Pair the devices with a short-lived invitation code generated on one device. No email, no Apple ID, no phone number — just a public-key handshake. 3. Keep using ⌘C / Ctrl-C and ⌘V / Ctrl-V exactly as before. UniClipboard extends the system clipboard; it does not replace it. ## When to choose what. If you only own Apple devices and don't care about clipboard history, iCloud Universal Clipboard is the easiest answer. For everyone else — anyone with a Windows or Linux machine in the workflow, anyone who wants searchable history, anyone who wants to audit the encryption code — UniClipboard is the open-source alternative built for all three desktop platforms. ## Frequently asked. ### Can I use UniClipboard and iCloud Universal Clipboard at the same time? Yes. They run independently. iCloud will keep syncing your latest copy between your Apple devices on the same Wi-Fi; UniClipboard adds Windows / Linux support, history, and cross-network sync on top. ### Does UniClipboard work without an internet connection? Yes. Devices on the same Wi-Fi connect peer-to-peer and never need a relay. Sync continues even when the public internet is unreachable, as long as the devices can see each other on the local network. ### Is my clipboard content sent to UniClipboard's servers? No. Content is encrypted on the source device with a key that lives in the system keyring. The relay, when used at all, only ever sees ciphertext. Plain text never leaves your devices. ### How is this different from a local clipboard manager like Pastebot or Maccy? Local clipboard managers store history on a single device. UniClipboard syncs across multiple devices and operating systems, with end-to-end encrypted transfer and shared history. ### Will UniClipboard work between a Mac and a Windows machine on different Wi-Fi networks? Yes. UniClipboard uses NAT hole-punching to establish a direct connection between devices on different networks, and falls back to an encrypted relay when direct connection fails. ### Does installing UniClipboard affect iCloud Universal Clipboard? No. UniClipboard does not modify iCloud or change any iCloud settings. You can install, use, or uninstall UniClipboard at any time without affecting iCloud. ## Free, open source, ready to install. macOS 12+, Windows 10/11, Linux x86_64 / ARM64. No account, no email, no setup beyond pairing. ## Notes - iCloud Universal Clipboard --- > **Source**: https://www.uniclipboard.app/zh/compare/icloud-universal-clipboard > **Locale**: Simplified Chinese > **Category**: Comparisons > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: iCloud 通用剪贴板只能在 Apple 设备之间使用，没有历史记录，不支持 Windows 或 Linux。UniClipboard 是它的开源、端到端加密替代方案——覆盖 macOS / Windows / Linux 三个桌面平台，可搜索历史、无需账号、无需服务器。 *对比 · UniClipboard 对 iCloud 通用剪贴板* # UniClipboard 对比 iCloud 通用剪贴板 **当你的工作里出现一台 Windows 或 Linux，事情就变了。** UniClipboard 是 Apple iCloud 通用剪贴板的开源跨平台替代方案。它在 macOS、Windows、Linux 三个桌面系统上都能跑（桌面端基于 Rust + Tauri），端到端加密，支持可搜索的历史记录，配对设备完全不需要任何云账号。iCloud 通用剪贴板则只在 Apple 设备之间同步、没有剪贴板历史、加密实现也不公开。 ## 30 秒看完。 - iCloud 通用剪贴板只能在 Apple 设备（Mac、iPhone、iPad）之间使用。 - 它没有历史记录——你只能粘贴最近一次复制的内容。 - UniClipboard 覆盖 macOS、Windows、Linux 三个桌面平台。 - UniClipboard 会在每台设备上保留一份端到端加密、可全文搜索的剪贴板历史。 - 两个都是免费的。UniClipboard 采用 AGPL-3.0 开源协议，加密实现可以自己审计。 - iCloud 要求 Apple ID。UniClipboard 不需要任何账号——设备之间通过公钥握手配对。 ## 什么情况下 iCloud 通用剪贴板已经够用 如果你的日常工作完全在 Apple 生态里——Mac 加 iPhone 加 iPad——而且你从来不需要回头找几小时前复制过的某段内容，那 iCloud 通用剪贴板是一个零配置的稳妥选择。Apple 把它直接做进了系统，只要你的设备登录同一个 Apple ID、连同一个 Wi-Fi、开着蓝牙、彼此距离在 10 米以内，它就能直接工作。 ## 什么情况下你需要 UniClipboard 取代它 只要你的工作里出现一台非 Apple 的设备——公司发的 Windows 笔记本、用来跑代码的 Linux 服务器、自己装的台式机——iCloud 通用剪贴板就完全用不了。同样的还有这些场景：你想找到两小时前复制的那段文字、想在家里跨不同 Wi-Fi 房间同步剪贴板、想自己审计加密实现再决定要不要让它接触你的密码。UniClipboard 就是为这些场景而生：开源代码、三平台桌面应用（Rust + Tauri）、密钥永不离开本机的端到端加密、本地加密历史索引、毫秒级搜索几万条记录。 ## 逐项功能对比。 *以下对比基于 2026 年 5 月公开的产品行为整理。* | 功能 | UniClipboard | iCloud 通用剪贴板 | | --- | --- | --- | | 支持平台 | macOS / Windows / Linux 全平台 | 仅 macOS 与 iOS | | 跨网络同步 | P2P + NAT 打洞 + 加密中继回退 | 仅同一 Wi-Fi 近距离 | | 剪贴板历史 | 可全文搜索，落盘加密 | 无历史，只保留最近一次 | | 加密方式 | XChaCha20-Poly1305 AEAD，开源 | 端到端，但闭源 | | 源码可读 | AGPL-3.0 开源，可自行审计 | 闭源 | | 是否需要账号 | 不需要——公钥配对 | 需要 Apple ID | | 文件传输 | 文本、图片与文件（大文件流式传输） | 仅文本与图片 | | 命令行 / 脚本 | 无头 uniclip CLI，可用于 SSH / tmux / 脚本 | 不支持 | | 价格 | 免费 | 免费 | ## 从 iCloud 通用剪贴板迁过来怎么做。 1. 在每台设备上分别安装 UniClipboard——macOS、Windows、Linux 都有签名的安装包。它和 iCloud 互不冲突，无需关闭 iCloud。 2. 在其中一台设备上生成一个一次性邀请码，另一台设备输入这个邀请码完成配对。整个过程不需要邮箱、Apple ID 或手机号——只是一次公钥握手。 3. 继续像以前一样按 ⌘C / Ctrl-C 复制、⌘V / Ctrl-V 粘贴。UniClipboard 是系统剪贴板的延伸，不会替换它。 ## 怎么选。 如果你只用 Apple 设备、不在乎剪贴板历史，iCloud 通用剪贴板就是最简单的答案。除此以外的任何场景——只要你工作里有一台 Windows 或 Linux 机器、想要可搜索的历史、想自己审计加密——UniClipboard 都是更合适的开源跨平台方案。 ## 常被问到的几个问题。 ### 可以同时用 UniClipboard 和 iCloud 通用剪贴板吗？ 可以，两者互不冲突。iCloud 仍会在你的 Apple 设备之间同步最近一次复制；UniClipboard 在此之上补上 Windows / Linux 支持、剪贴板历史和跨网络同步。 ### 没有公网 / 没有互联网时还能用吗？ 可以。同一 Wi-Fi 下的设备会直接 P2P 互联，全程不经过中继。即便公网完全断开，只要设备之间能在局域网看见彼此，同步就能继续。 ### 我的剪贴板内容会上传到 UniClipboard 的服务器吗？ 不会。内容在源设备就被加密，密钥常驻系统 Keyring。中继只在直连失败时使用，且只能看到密文。明文不会离开你自己的设备。 ### 和本机剪贴板管理器（Pastebot / Maccy）有什么区别？ 本机管理器只管单台设备的历史。UniClipboard 跨多台设备和不同操作系统同步，且全程端到端加密。 ### Mac 和 Windows 不在同一个 Wi-Fi，能同步吗？ 能。UniClipboard 会通过 NAT 打洞在两台设备之间建立直连，打洞失败时回退到加密中继，整段链路都加密。 ### 装了 UniClipboard 会影响 iCloud 通用剪贴板吗？ 不会。UniClipboard 不修改 iCloud，也不改变 iCloud 任何设置。安装、使用、卸载都不会影响 iCloud 的行为。 ## 免费、开源、即装即用。 macOS 12+，Windows 10/11，Linux x86_64 / ARM64。除了配对一次，别的都不用做。 ## Notes - iCloud Universal Clipboard # Use cases --- > **Source**: https://www.uniclipboard.app/use-cases/mac-to-windows-clipboard > **Locale**: English > **Category**: Use cases > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: UniClipboard lets you copy on your Mac with ⌘C and paste on Windows with Ctrl+V — text, images, files. Open source, end-to-end encrypted, no cloud account, no server. The cross-platform replacement for Apple's Universal Clipboard. *Use case · Mac to Windows clipboard* # Copy on your Mac. Paste on Windows. **Without uploading to a cloud, emailing yourself, or running a server.** UniClipboard is the most direct way to move content between a Mac and a Windows PC — text, images, or files. Press ⌘C on the Mac, then Ctrl+V on Windows, and the content arrives. It is open source, end-to-end encrypted, requires no cloud account, and works on the same Wi-Fi peer-to-peer or across different networks via NAT hole-punching with an encrypted relay fallback. ## What you need to know in 30 seconds. - iCloud Universal Clipboard does not work between Mac and Windows — Apple ships it for Apple devices only. - Common workarounds (emailing yourself, cloud storage, chat self-DMs, OneDrive sync) are either slow, insecure, or both. - UniClipboard installs on macOS and Windows in a few minutes and pairs with a single short-lived invitation code. - After pairing, the system clipboard is shared: ⌘C on Mac → Ctrl+V on Windows, no menu, no upload step. - Content is end-to-end encrypted with XChaCha20-Poly1305 AEAD. Plain text never leaves your devices. - Same Wi-Fi → direct P2P. Different networks → NAT hole-punching, with an encrypted relay only as a fallback. ## The usual hacks all have a tax Emailing yourself a snippet routes the content through a third-party server, costs you a tab switch, and breaks if the snippet is binary. Self-DMs in Slack or WeChat work but the content is stored on someone else's server and pasting an image often loses formatting. Uploading a file to OneDrive or Google Drive solves the file case but means waiting for sync — and gives the cloud provider another copy of your data. Each of these hacks asks you to trade speed for security, or security for speed. ## Same keystroke, encrypted, instant. UniClipboard turns the Mac and Windows machines into a single shared clipboard. ⌘C on the Mac places the content into the system clipboard; UniClipboard immediately pushes the encrypted bytes to the Windows side; Ctrl+V on Windows pastes it. There is no upload, no third-party server in the path, no menu to open, no permission prompt per copy. Each device keeps its own searchable encrypted history, so you can also page back through earlier copies. ## How UniClipboard compares to the workarounds. *Comparison reflects publicly documented behaviour as of 2026-05.* | What you care about | UniClipboard | Cloud / chat / email workarounds | | --- | --- | --- | | Latency | Instant — same keystroke | Seconds to minutes (upload + download) | | Security | End-to-end encrypted, open source | Content sits on a third-party server | | Account / login | None — public-key device pairing | Account required for every service | | Files | Streaming transfer, no size cap from us | Subject to provider attachment limits | | Searchable history | Encrypted local index per device | Search whatever inbox / chat you used | | Works offline | Yes — same Wi-Fi P2P | No — needs the cloud service | | Different Wi-Fi networks | NAT hole-punching + encrypted relay | Works as long as the cloud is reachable | ## Three steps. About five minutes. 1. Download UniClipboard for macOS and for Windows from the Downloads page. Each installer is signed — macOS uses notarization, Windows uses Authenticode signing. 2. Open UniClipboard on the Mac, generate a short-lived pairing code, then enter that code on the Windows machine. The two devices exchange a public key once over the local network. There is no email, no Apple ID, no phone number. 3. Copy on the Mac with ⌘C as you always have. Switch to Windows and paste with Ctrl+V. Text, images, and files all flow without any extra menu or permission prompt. ## What to use, and when. If you only ever need to send a single short snippet from your Mac to your Windows machine, the chat self-DM works. For everything else — repeated copies, images, files, content you don't want sitting on a third-party server, or anything that needs to feel as fast as the system clipboard — UniClipboard is what you want. ## Common questions. ### Is the paste a regular Ctrl+V, or do I need a special menu? Regular Ctrl+V. UniClipboard places the content into the Windows system clipboard, so any app that accepts a paste accepts UniClipboard's content. ### Does this work between a Mac and a Windows machine on different Wi-Fi networks? Yes. UniClipboard performs NAT hole-punching to establish a direct connection, and falls back to an encrypted relay when direct connection fails. Either way the content stays end-to-end encrypted. ### Can I copy a file, not just text? Yes. Files are transferred with streaming so they never have to fit entirely in memory. Drop a file onto the clipboard on one device and paste it on the other. ### Does my clipboard go through the public internet? Only when it has to. If both devices are on the same Wi-Fi, the transfer is direct peer-to-peer. If they are on different networks, UniClipboard tries NAT hole-punching first; only when that fails does it fall back to an encrypted relay — and the relay only ever sees ciphertext. ### Does it work on Windows 10, or only Windows 11? Both. UniClipboard supports Windows 10 and Windows 11 (x64). On the Mac side, macOS 12 (Monterey) and later are supported. ### Does it work in the reverse direction — copy on Windows, paste on Mac? Yes. The clipboard is bidirectional and symmetric. ⌘V on the Mac will receive whatever was last copied on the Windows side, and vice versa. ## Free, open source, ready to install. macOS 12+, Windows 10/11. No account, no email, no setup beyond the one-time pairing. --- > **Source**: https://www.uniclipboard.app/zh/use-cases/mac-to-windows-clipboard > **Locale**: Simplified Chinese > **Category**: Use cases > **Published**: 2026-05-04 > **Last updated**: 2026-08-12 > **Description**: UniClipboard 让你在 Mac 上 ⌘C，到 Windows 上 Ctrl+V 直接粘贴——文本、图片、文件都能过。开源、端到端加密、不需要任何云账号、不用搭服务器。Apple iCloud 通用剪贴板的跨平台替代。 *使用场景 · Mac 到 Windows 剪贴板* # Mac 上复制。Windows 上直接粘。 **不用上传云盘，不用发邮件给自己，不用搭服务器。** UniClipboard 是把内容从 Mac 搬到 Windows 最直接的办法——文本、图片、文件都行。在 Mac 上 ⌘C，切到 Windows 用 Ctrl+V 粘出来，就完了。它开源、端到端加密、不需要任何云账号；同一 Wi-Fi 走 P2P 直连，跨网络自动 NAT 打洞，连不通时回退到加密中继。 ## 30 秒看清楚。 - iCloud 通用剪贴板原生不支持 Mac 和 Windows 互通——Apple 把它做成只在 Apple 设备之间用。 - 常见的土办法都有代价：发邮件给自己、上传云盘、聊天软件给自己留言、OneDrive 同步——慢、不安全，或者两者都占。 - UniClipboard 在 Mac 和 Windows 上各装一次，用一个一次性邀请码完成配对。 - 配对完成后，系统剪贴板就是共享的：Mac 上 ⌘C，Windows 上 Ctrl+V，没有菜单、没有上传、没有额外步骤。 - 内容用 XChaCha20-Poly1305 AEAD 端到端加密，明文永远不离开你自己的设备。 - 同一 Wi-Fi 直连 P2P；跨网络自动 NAT 打洞；打洞失败时才回退到加密中继，中继也只看到密文。 ## 你已经在用的那些 workaround，都有税。 把内容发邮件给自己——经过第三方服务器，要切窗口，二进制内容还可能被处理坏。在 Slack / 微信 / QQ 给自己发——内容存在别人服务器上，图片粘出来经常掉格式。把文件上传到 OneDrive / Google Drive / 百度网盘——文件传输的问题是解决了，但要等同步、还多了一份留在云端的副本。每一种土办法都在让你拿速度换安全，或者用安全换速度。 ## 同一个快捷键，加密，毫秒级。 UniClipboard 把 Mac 和 Windows 这两台机器的剪贴板做成共享的一个。Mac 上按 ⌘C，内容进入系统剪贴板；UniClipboard 立刻把加密后的字节推给 Windows；Windows 上 Ctrl+V 粘出来。整个过程没有上传、没有第三方服务器、没有菜单可以开、没有每次复制都要确认的权限弹窗。每台设备各自保留一份可全文搜索的加密历史，老的复制内容随时翻得到。 ## UniClipboard 和那些土办法的差别。 *以下对比基于 2026 年 5 月公开的产品行为整理。* | 你在乎的事 | UniClipboard | 云盘 / 聊天 / 邮件 | | --- | --- | --- | | 速度 | 毫秒级——和按快捷键一样快 | 几秒到几分钟（上传 + 下载） | | 安全 | 端到端加密、开源可审计 | 内容会存在第三方服务器上 | | 是否要登录 | 不需要——公钥配对 | 每个服务都要登录 | | 文件 | 流式传输，我们这边不限大小 | 受服务方附件大小限制 | | 可搜索的历史 | 每台设备一份加密本地索引 | 得回到对应的收件箱 / 聊天里翻 | | 断网能用吗 | 能——同 Wi-Fi 走 P2P | 不能——依赖云服务可达 | | 跨 Wi-Fi 网络 | NAT 打洞 + 加密中继 | 云服务能访问就行 | ## 三步。大约五分钟。 1. 去下载页拿 macOS 和 Windows 的 UniClipboard 安装包。两个安装包都签过名——macOS 走苹果公证，Windows 走 Authenticode 代码签名。 2. 在 Mac 上打开 UniClipboard，生成一个短时效邀请码；在 Windows 上输入这个邀请码完成配对。两台设备只在局域网上交换一次公钥，整个过程不需要邮箱、不需要 Apple ID、不需要手机号。 3. 之后正常用 ⌘C 在 Mac 上复制，切到 Windows 按 Ctrl+V 粘贴。文本、图片、文件都直接过，没有额外菜单也不会弹任何确认。 ## 怎么选。 如果只是偶尔从 Mac 把一小段文字带到 Windows，给自己发个聊天就够用。除此以外的任何场景——反复复制、图片、文件、不愿意让内容停在第三方服务器、希望像系统剪贴板一样快——UniClipboard 都是更合适的方案。 ## 常被问到的几个问题。 ### 粘贴是直接 Ctrl+V，还是要专门的菜单？ 就是普通的 Ctrl+V。UniClipboard 把内容写进了 Windows 的系统剪贴板，所以任何能粘贴的应用都能粘出 UniClipboard 同步过来的内容。 ### Mac 和 Windows 不在同一个 Wi-Fi 也能用吗？ 能。UniClipboard 会先尝试 NAT 打洞建立直连，打不通时回退到加密中继，整段链路都加密。 ### 文件能传吗，还是只支持文本？ 可以。文件采用流式传输，不需要整个加载到内存。在一台设备上把文件放到剪贴板，另一台设备粘出来即可。 ### 我的剪贴板会经过公网吗？ 看情况。同一 Wi-Fi 下完全是 P2P 直连，不会出网。跨网络时先尝试 NAT 打洞，打不通才回退到加密中继——而中继也只能看到密文。 ### Windows 10 能用，还是只支持 Windows 11？ 都能。UniClipboard 支持 Windows 10 和 Windows 11（x64）。Mac 这边支持 macOS 12（Monterey）及以上。 ### 反过来呢——Windows 上复制，Mac 上粘？ 可以。剪贴板是双向对称的。Mac 上 ⌘V 粘到的是 Windows 上最近一次复制的内容，反过来也一样。 ## 免费、开源、即装即用。 macOS 12+，Windows 10/11。除了第一次配对，别的都不用做。 # Blog --- > **Source**: https://www.uniclipboard.app/blog/wechat-input-method-vs-uniclipboard > **Locale**: English > **Category**: Blog > **Published**: 2026-08-12 > **Last updated**: 2026-08-12 > **Description**: WeChat Input Method makes cross-device paste convenient. UniClipboard is for people who need a searchable, cross-platform clipboard without changing their keyboard. # WeChat Input Method vs UniClipboard: keep your keyboard, expand your clipboard **Cross-device paste is now table stakes. The difference is what your clipboard can become after that.** WeChat Input Method is a strong option if your only need is to paste something you just copied on another device. Its store listing says it supports Windows, macOS, Android, and iOS, including cross-device copy and paste.[^1] That is useful progress for everyone. It also means UniClipboard cannot compete on the sentence "we sync your clipboard." That is a baseline now. The more useful question is: **what should a clipboard product do once copying between two devices already works?** ## You should not have to replace your keyboard An input method and a clipboard solve different problems. An input method is where you write; a clipboard is where the things you collect, move, and reuse live. Many people already have a keyboard they prefer: Microsoft Pinyin, the macOS keyboard, Rime, Sogou, Gboard, the iPhone keyboard, or something else. Switching that habit just to gain clipboard sync is a real cost. UniClipboard works beside the keyboard you already use. Copy and paste continue to use the system shortcuts you know. The app takes care of moving the clipboard between your devices. > Keep your keyboard. Sync your clipboard. ## A clipboard workspace, not one recent item Passing the latest copy from a computer to a phone is one job. Finding a link, code snippet, screenshot, address, or file that you copied two days ago is another. UniClipboard is built around that second job too. It keeps an encrypted, searchable history on each device, with previews for text, links, images, code, and files. You can control how long history is kept, clear it by device or content type, and review where an item came from. That changes the model from "send my last copy" to **one clipboard across the devices where you work**. ## Linux is part of the workflow WeChat Input Method's store listing names Windows, macOS, Android, and iOS.[^1] UniClipboard also supports Linux, alongside macOS, Windows, iOS, and Android. For many people, that is not a niche detail. A workflow may include a Mac laptop, a Windows work computer, a Linux desktop or server, and a phone. Clipboard sync should not stop where the operating-system list does. ## A clearer route for sensitive content Clipboards regularly hold passwords, access tokens, commands, internal links, customer details, verification codes, and files. For that reason, how content moves matters as much as whether it arrives. UniClipboard pairs devices without requiring a cloud account. On the same Wi-Fi, paired devices can connect directly. Across networks, it tries a direct connection first and uses an encrypted relay only when needed. LAN-only mode lets you turn the relay path off entirely. Content is encrypted before it leaves the source device and decrypted only on your devices. This is not a claim about how another product handles clipboard data. It is a promise about a model you can understand, inspect, and choose: your devices, encrypted content, and a direct path whenever it is available. ## Open source makes trust checkable "Open source" is not a reason for everyone to choose an app. It matters a great deal when the app can see sensitive material. UniClipboard is open source under AGPL-3.0. Its code, protocol decisions, and security design can be examined rather than taken on faith. For developers, security-conscious teams, and people who operate their own infrastructure, that creates a meaningful choice. ## Files are the next natural step Clipboard sync should not be limited to text. UniClipboard already moves text, images, and files, and streams large files so they do not need to fit in memory all at once. WeChat Input Method has also begun testing image and file transfer through its "Air Transfer" feature, according to Sina Finance.[^2] That makes "we support files" a less durable headline by itself. The opportunity is broader: make clipboard and lightweight device-to-device transfer feel like one continuous action. Copy a screenshot on one device and find it in another device's history. Copy a file and paste it where you need it. The product should make moving work between devices feel ordinary, not like a separate sharing ritual. ## Devices can belong to different spaces Not every device in a person's life belongs together. A personal Mac and phone may need one shared clipboard; a work Windows machine may need another. This is the direction behind a device network made of intentional spaces: personal, work, home, team, or temporary. Instead of treating every device logged into one account as an automatic member, the owner decides which devices can see each other. ## The comparison in one sentence WeChat Input Method is a convenient input method with cross-device paste. UniClipboard is a dedicated clipboard for people who want to keep their input method while gaining history, Linux support, direct encrypted transfer, inspectable software, and a clipboard that can grow with their device workflow. Cross-device copy and paste is the starting point. The goal is a clipboard built for all your devices. --- [^1]: [WeChat Input Method on Microsoft Store](https://apps.microsoft.com/detail/xpfffp686ndrdz?gl=CN&hl=lv-LV), accessed August 12, 2026. [^2]: [Sina Finance: WeChat Input Method tests Air Transfer for images and files](https://finance.sina.com.cn/tech/roll/2026-05-03/doc-inhwqzxm0901606.shtml), May 3, 2026. --- > **Source**: https://www.uniclipboard.app/zh/blog/wechat-input-method-vs-uniclipboard > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-08-12 > **Last updated**: 2026-08-12 > **Description**: 微信输入法让跨设备粘贴更方便。UniClipboard 面向需要保留原有输入法、同时获得跨平台可搜索剪贴板的人。 # 微信输入法 vs UniClipboard：不用换输入法，扩展你的剪贴板 **跨设备复制粘贴已经是基础能力，差别在于剪贴板接下来能做什么。** 如果你的需求只是把刚刚在一台设备上复制的内容，粘贴到另一台设备，微信输入法已经是很强的选择。它的商店页面明确写有 Windows、macOS、Android、iOS，以及跨设备复制粘贴等能力。[^1] 这对所有人都是好事，也意味着 UniClipboard 不能再只说“我也能同步剪贴板”。这已经是基础能力。 真正值得问的是：**当两台设备之间已经能复制粘贴后，剪贴板还应该做什么？** ## 不该为了同步剪贴板换掉输入法 输入法和剪贴板，解决的是两类问题。输入法负责你怎么写；剪贴板负责你收集、搬运和复用哪些内容。 很多人早已习惯微软拼音、macOS 系统输入法、Rime、搜狗、Gboard、iPhone 原生输入法，或别的选择。仅为了剪贴板同步而改变这个习惯，成本并不小。 UniClipboard 与你现有的输入法一起工作。你仍然使用熟悉的系统复制、粘贴快捷键，它负责把剪贴板带到其他设备。 > 不用换输入法，也能同步剪贴板。 ## 不只是最近一条，而是一套剪贴板工作空间 把电脑上刚复制的内容传到手机，是一个需求。两天后重新找到一段代码、一个链接、一张截图、一个地址或一个文件，是另一个需求。 UniClipboard 同样为后者而做：每台设备保留加密、可搜索的历史记录，能预览文本、链接、图片、代码和文件；你可以设定保留时间，按设备或内容类型清理，也能看到内容来自哪里。 这让体验从“传递刚刚复制的一条”变成了**你工作所用设备共享的一套剪贴板**。 ## Linux 也在工作流里 微信输入法商店页面列出的平台是 Windows、macOS、Android 和 iOS。[^1] UniClipboard 还支持 Linux，并覆盖 macOS、Windows、iOS 与 Android。 这并不是小众细节。一个人的设备组合可能是 Mac 笔记本、公司的 Windows 电脑、Linux 桌面或服务器，再加一台手机。剪贴板同步不该在平台列表的边界停下。 ## 对敏感内容，传输路径本身很重要 剪贴板里经常有密码、Token、命令、内部链接、客户信息、验证码和文件。因此，内容能否到达很重要；内容怎样到达也同样重要。 UniClipboard 配对设备时不要求云账号。同一 Wi-Fi 下，已配对设备可以直接连接；跨网络时，先尝试直接连接，必要时才使用加密中继。LAN-only 模式可以彻底关闭中继路径。内容离开源设备前已加密，只会在你的设备上解密。 这不是对其他产品如何处理剪贴板的判断。它说明的是 UniClipboard 提供的模型：你能理解、检查并选择自己的设备、加密内容和传输路径。 ## 开源，让信任可以被检查 开源并不是每个人选择一个应用的理由。但当应用可能接触敏感内容时，它的意义会变得具体。 UniClipboard 以 AGPL-3.0 开源。代码、传输设计和安全实现都可以被查看，而不只是被要求相信。对开发者、安全敏感团队和希望掌控基础设施的人来说，这是一种明确的选择。 ## 文件，是自然的下一步 跨设备剪贴板不应只限于文本。UniClipboard 现在已经可以传递文本、图片和文件；大文件以流式方式传输，不需要完整放进内存。 据新浪财经报道，微信输入法也已开始测试支持图片、文件的“隔空传送”。[^2] 所以“支持文件”本身不再是足够长久的差异。 更值得做的是，把剪贴板与轻量设备互传变成一件连续的事：在一台设备复制截图，另一台设备的历史里就能找到；复制一个文件，需要时直接粘贴。设备间移动工作内容不该像一次单独的分享操作。 ## 设备也可以属于不同的 Space 一个人的所有设备，不一定都该放在一起。个人的 Mac 和手机可以共享一套剪贴板；公司的 Windows 电脑可以是另一套。 这也是设备网络下一步的方向：个人、工作、家庭、团队或临时 Space。设备不因登录同一个账号就自动互相可见，而是由拥有者决定哪些设备属于同一个范围。 ## 一句话总结 微信输入法是带有跨设备粘贴能力的输入法。UniClipboard 是一个专门做剪贴板的产品，适合不想更换输入法、但需要历史记录、Linux、加密直连、可查看代码，以及能随着设备工作流继续扩展的人。 跨设备复制粘贴只是开始。UniClipboard 要做的是一套真正为所有设备而生的剪贴板。 --- [^1]: [微软商店：微信输入法](https://apps.microsoft.com/detail/xpfffp686ndrdz?gl=CN&hl=lv-LV)，访问于 2026 年 8 月 12 日。 [^2]: [新浪财经：微信输入法测试“隔空传送”功能，支持跨设备秒传图片、文件](https://finance.sina.com.cn/tech/roll/2026-05-03/doc-inhwqzxm0901606.shtml)，2026 年 5 月 3 日。 --- > **Source**: https://www.uniclipboard.app/blog/encrypted-search-principles > **Locale**: English > **Category**: Blog > **Published**: 2026-05-09 > **Last updated**: 2026-05-09 > **Description**: The search index is encrypted on disk. Here is how UniClipboard can still search clipboard history without storing plaintext terms. # How encrypted search works **The index is encrypted on disk. Search still works by matching HMAC term tags instead of plaintext words.** UniClipboard's privacy baseline is simple: **clipboard history is encrypted at rest, and the search index is encrypted too**. > There is no plaintext clipboard content saved anywhere on disk. For the storage details behind the index, see “Sync content — Local storage”. That raises the practical question: if the content is encrypted, how can the search box still find words inside it? ## How the index is built UniClipboard uses a “tokenize → HMAC tokenization → inverted index” pipeline: 1. Content is normalized with NFKC, lowercased, and split by Unicode word boundaries. 2. Each token is transformed with `HMAC-SHA256(SearchKey, token)` into a 32-byte term tag. 3. The inverted index stores the term tags, **not the original text**. `SearchKey` is derived from the space `MasterKey` with HKDF-SHA256. Each space has its own key. The `MasterKey` lives in the system keyring, so it does not leave the local machine. That means even if someone copies the index file, all they see is a set of HMAC outputs. Those outputs are not reversible, so they cannot be used to recover the original tokens. ## How matches work A query goes through the same tokenization and HMAC pipeline. A result matches only when the complete term tag matches. For `hello world`: | Query | Matches `hello world` | | --- | --- | | `hello` | ✅ | | `world` | ✅ | | `hello world` | ✅ — both term tags must match | | `hel` | ❌ | | `ello` | ❌ | `hel` does not match `hello` because HMAC transforms the whole input. Change one character and the output changes completely. There is no prefix relationship between `hel` and `hello` in term-tag space. ## The boundary: no arbitrary substring search in body text For body text, **substring search does not work; you need complete words**. That is the trade-off of encrypted search. If UniClipboard allowed arbitrary substring matching, the index would need to preserve plaintext-like “cracks” that can leak information — for example, indexing every n-gram or storing comparable plaintext prefixes. That would weaken the point of encrypting the index. UniClipboard makes two targeted compromises so search remains usable: ### Identifier fields support prefix expansion For identifier-like fields such as filenames, URLs, and paths, UniClipboard indexes prefixes of each token with length ≥ 3. Each prefix still becomes its own term tag. So searching `uniclip` can match the filename `uniclipboard.dmg`, and searching `localh` can match the URL `localhost:3000`. This is only enabled for identifier fields. Large body text does not use prefix expansion because it would make the index too large. ### Chinese text uses bigrams Chinese text is indexed with overlapping two-character bigrams. `你好世界` becomes `你好` / `好世` / `世界`, and each bigram is stored as a term tag. So searching `好世` can match `你好世界`, and `你好` works too. Single-character search inside Chinese phrases does not work because the index does not store single-character terms. ## What this means in daily use | What you want to find | Recommended query | | --- | --- | | A command containing `prod` | Search `prod`, not `pro` | | A filename containing `report` | Search `report`, or prefixes like `rep` / `repo` | | A Chinese phrase | Use at least two consecutive characters, such as `合同`, not `合` | | An English word you cannot spell exactly | Try a shorter but still **complete** token, then narrow by type or time | For more query options, see “Full-text search — Query syntax”. --- > **Source**: https://www.uniclipboard.app/zh/blog/encrypted-search-principles > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-09 > **Last updated**: 2026-05-09 > **Description**: 索引在磁盘上加密，搜索还能怎么做。 # 加密搜索原理 **索引在磁盘上加密，搜索靠 HMAC term tag 命中，而不是明文词。** UniClipboard 的隐私前提是：**所有剪贴板记录加密存储，搜索索引也加密**。 > 磁盘上没有任何一处保存明文剪贴内容。索引的加密细节见「同步内容 — 本地存储」。 现在的问题就是：内容都加密了，搜索框该怎么命中里面的字？ ## 怎么建索引 UniClipboard 走的是「分词 → HMAC token 化 → 倒排索引」这条路： 1. 内容先做 NFKC 归一化 + 小写，再按 Unicode 词边界分词 2. 每个 token 经过一次 `HMAC-SHA256(SearchKey, token)`，产出一个 32 字节的 term tag 3. 倒排索引里存的就是 term tag，**不存原文** SearchKey 由空间 MasterKey 通过 HKDF-SHA256 派生（每个空间一把），MasterKey 存在系统密钥环，离开本机就拿不到。 这意味着即使索引文件被人拿走，看到的也只是一堆 HMAC 输出 —— 不可逆，反推不出原始 token。 ## 怎么命中 查询时走完全相同的一套 token 化 + HMAC，命中“完整 term tag”才算匹配。 拿 `hello world` 举例： | 输入 | 命中 `hello world` | | --- | --- | | `hello` | ✅ | | `world` | ✅ | | `hello world` | ✅（两个 term tag 都要命中） | | `hel` | ❌ | | `ello` | ❌ | `hel` 搜不到 `hello`，是因为 HMAC 是**整体**变换 —— 输入差一个字符，输出就完全不同。`hel` 和 `hello` 在 term tag 空间里没有任何前缀关系。 ## 边界：正文里子串搜不到 所以在正文里，**子串搜不到，必须用完整的词**。 这是加密搜索的弊端。如果允许任意子串匹配，索引里就得保留能反推明文的“缝隙”（比如把所有 n-gram 都建进索引、或者保留可比较的明文前缀），加密的意义就被削弱了。 UniClipboard 在两个地方做了让步，让搜索体验不至于太难受： ### 标识符字段开了前缀展开 文件名、URL、路径这类**标识符类字段**在建索引时，会把每个 token 的前缀（长度 ≥ 3）单独算一份 term tag。 所以搜 `uniclip` 能命中文件名 `uniclipboard.dmg`，搜 `localh` 能命中 URL `localhost:3000`。 这只对标识符字段开启 —— 大段正文不开，否则索引体积会失控。 ### 中文按 bigram 切 中文走“重叠两字”切分。`你好世界` 在索引里是 `你好` / `好世` / `世界` 三个 bigram，每个都建 term tag。 所以搜 `好世` 能命中 `你好世界`，搜 `你好` 也行。多字中文片段里的单字搜索不行 —— 索引里没有单字这一层。 ## 这对日常使用意味着什么 | 想找 | 推荐搜 | | --- | --- | | 一段含 `prod` 的命令 | 直接搜 `prod`，别搜 `pro` | | 文件名带 `report` | 搜 `report`，或者它的前缀 `rep`、`repo` 也行 | | 中文短语 | 用至少两个字的连续片段（比如 `合同`，而不是 `合`） | | 拼不准的英文词 | 换更短但**完整**的 token，再用类型 / 时间过滤缩范围 | 更多查询语法见「全文搜索 — 查询语法」。 --- > **Source**: https://www.uniclipboard.app/blog/sync-clipboard-mac-windows-linux-without-cloud-account > **Locale**: English > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: Open-source, end-to-end encrypted clipboard sync across Mac, Windows and Linux. No cloud account, no self-hosting. Direct P2P with encrypted relay fallback. # Sync clipboard between Mac, Windows and Linux without cloud account **You copied a long URL on your Mac. You want to paste it on your Windows desktop, or your Linux box at home. The “solutions” people end up using are surprisingly bad:** You copied a long URL on your Mac. You want to paste it on your Windows desktop, or your Linux box at home. The “solutions” people end up using are surprisingly bad: - DM yourself on Telegram, WhatsApp, Discord, or Slack. - Email yourself. Again. - Log into a cloud notes app on both machines and type into a “scratch” note. - Pay for a clipboard SaaS that wants you to create yet another account. - Stand up Syncthing or Tailscale plus a homemade script and call it “self-hosted”. None of these were designed to sync a clipboard. Some of them are also a bad fit for the kind of stuff that actually shows up in your clipboard — passwords, API keys, internal URLs, half a paragraph of a draft. This page is about the narrow gap UniClipboard is built for: **clipboard sync across Mac, Windows, and Linux, with no cloud account, no self-hosting, and end-to-end encryption across the public internet.** To be precise upfront: “no cloud account” does not mean “no network”. Devices try to talk directly via P2P. When the network refuses to cooperate, traffic falls back to an encrypted relay. The relay can route bytes; it cannot read your clipboard. ## TL;DR - **Three desktops, no signup.** UniClipboard is open source and runs on macOS, Windows, and Linux. There is no UniClipboard cloud account, and you are not logging into anything. - **Pair devices directly.** Two devices, one short pairing flow. After that, copy on one, paste on another. - **Direct P2P first, encrypted relay fallback.** No VPN, no Tailscale, no port forwarding. The relay sees ciphertext, peer IDs, and byte counts — not clipboard contents, not clipboard type, not device names, not the pairing passphrase. - **Encrypted local clipboard history with full-text search.** Not just “send the latest item”. Your history stays on each device, encrypted at rest. - **Honest about the state.** iOS is in public beta on TestFlight and Android ships as a signed APK; this page tells you what is stable and what is still beta instead of tap-dancing. ## Why messaging yourself is clunky “DM myself on Telegram” works for one URL. After that it falls apart in small but irritating ways. - It is plaintext. Everything you self-DM is now sitting in a chat history on someone else’s server, indexed and searchable by them, retained on their schedule. - It is unidirectional. You have to switch apps, find the right chat, copy from a message bubble, paste, then go back. That is not a clipboard, that is a messaging app pretending to be one. - It mixes channels. The thing you wanted on the other machine ten seconds ago is now interleaved with messages from people, links from groups, and bot pings. - It does not survive secrets well. API keys and recovery codes have no business living in your DM history. The worst part is that it trains you to ignore the cost. After a while you forget how many tokens, paths, snippets, and half-thoughts you have quietly piped through Telegram or WhatsApp because you needed them on another machine for thirty seconds. A clipboard sync tool should make that habit unnecessary. ## Why cloud clipboard is sensitive Hosted clipboard services in the “sign up, install, sync” shape have one structural problem: at some point your clipboard exists on someone else’s server, in a form that someone other than you could be in a position to read. That might be fine for grocery lists. It is genuinely not fine for: - passwords pasted from a manager; - API keys, deploy tokens, GitHub PATs; - internal URLs and host names; - bits of code that include credentials by accident; - private text from drafts, journals, or chats. Most of what is in a clipboard is mundane. The risk is that a small fraction is not, and you cannot easily separate the two in real time. So the question becomes: do you trust a third-party service with the union of all of it, including the stuff you would never have uploaded on purpose? “We encrypt your clipboard” is not the same as “we cannot read your clipboard”. The interesting question is which keys live where, and what the server-side software could do if it wanted to (or if it were forced to). UniClipboard’s position on this is intentionally narrow: clipboard payloads are encrypted on your device with a key the relay does not have, and they are decrypted on the receiving device. The transport layer — direct or relay — never holds plaintext. ## Why self-hosting a clipboard is usually overkill The next instinct, especially in self-hosting circles, is: just run a server. Self-host a sync server, point all your devices at it, done. That is genuinely the right answer for some people, and there are good open-source projects in that shape. For most people who only want their clipboard to follow them across three desktops, it is too much: - A server is a thing you now own forever. Updates, certificates, ports, reverse proxy, backups, the whole maintenance shape. - It is infrastructure that you will only notice when it breaks — usually right when you actually need to paste something. - It still requires you to think about access control, signup, message size, CORS, and the rest of the “tiny SaaS you accidentally built” checklist. - For a clipboard, the operational complexity is wildly out of proportion to the value. Self-hosting earns its keep when you are also the kind of person who likes running the thing. Otherwise, the clipboard quietly turns into another homelab chore. ## How accountless P2P pairing closes the gap UniClipboard sits between “DM myself” and “run my own server”. The shape is: 1. Install on each desktop you care about. 2. Pair them directly, one time. No email, no signup, no cloud account. 3. After pairing, devices try to talk to each other via direct peer-to-peer connections across whatever network they are on. 4. When direct P2P cannot be established (corporate networks, hostile NAT, mobile tethering), traffic falls back through an encrypted relay. 5. Either way, clipboard contents are encrypted end to end. The relay only ever sees ciphertext. A few things matter about this: **Pairing, not login.** There is no UniClipboard account. Your “identity” for the network is your paired devices. If you stop trusting one, you unpair it. **No central clipboard database.** Your clipboard does not live on a UniClipboard server, because there is no UniClipboard clipboard server. Each device keeps its own encrypted local history. **Direct P2P when the network allows it.** When two devices can reach each other directly (same LAN, friendly home network, working hole-punch), traffic does not go through any relay at all. **Encrypted relay only as fallback.** When direct P2P fails — and on real-world networks, it sometimes does — the relay stitches the connection. The relay sees: - encrypted bytes (ciphertext); - source and destination peer IDs (for routing); - byte counts and timing. The relay does **not** see: - clipboard content; - clipboard type (text, image, file); - device names; - the pairing passphrase. That is a deliberate split: the convenience of accountless cross-internet sync, without giving a server the ability to read your clipboard. ## What you actually get on each platform UniClipboard runs on macOS, Windows, and Linux as a native desktop app, built with Rust and Tauri 2. - **Text** — copy text on one machine, paste on another. The boring, common case, and the one that has to feel instant. - **Images** — screenshots and image clipboard items sync across desktops. - **Files** — file copy/paste flows across devices, not just file paths flattened into strings. - **Encrypted local history** — recent clipboard items live on each device in an encrypted store you can search. - **Encrypted full-text search** — find that command you copied yesterday without exporting your history to a third party. What it does **not** do today: - **Mobile is now available.** There is a native Android app (signed APK) and an iOS public beta on TestFlight. If you would rather not install a native app, the SyncClipboard open protocol works over LAN via iPhone Shortcuts or any SyncClipboard-compatible Android client. - **No web app.** This is intentional. A web clipboard would mean a hosted clipboard, which is the thing this whole product avoids. - **No “share with another user” mode.** UniClipboard syncs your clipboard between your devices, not across users. ## Setup, very briefly The install path is intentionally short: 1. **Install UniClipboard** on the desktops you want to sync. Mac, Windows, Linux all available from the website. 2. **Open the app on the first device** and start pairing. 3. **On the second device, enter the pairing code or scan the prompt.** This is the only credential exchange that ever happens. 4. **Copy something** on the first device. 5. **Paste it** on the second device. There is no “create an account” step, because there is no account. There is no “configure server URL” step, because there is no server you have to point at. If pairing happens on the same LAN, the first connection is usually direct. If your devices are on different networks, UniClipboard will hole-punch where it can, and fall back to the encrypted relay where it cannot. ## How this compares to the obvious alternatives A short, practical sweep — not a takedown, just where each shape fits. - **Self-DM on a messaging app.** Fastest to start, worst at everything else. Plaintext on someone else’s server, mixed with conversations, no real history search, and you train yourself to send things you later regret. Fine for one URL, awful as a habit. - **Cloud clipboard SaaS.** Smooth UX, and depending on the vendor, possibly fine for non-sensitive use. The structural concern is the union of everything in your clipboard sitting on someone else’s server. - **Apple Universal Clipboard.** Excellent in the Apple-only case. Does not help if any of your machines run Windows or Linux. - **Self-hosted sync server.** A legitimate answer if you genuinely want to operate a server. For people who do not, it is too many moving parts for a clipboard. - **Tailscale + a script + Syncthing folder + …** Workable, and Tailscale is great in general. But every additional piece is something you install, configure, and maintain on every device, just to get the clipboard part done. - **UniClipboard.** Desktops plus mobile, no cloud account, no server to run, end-to-end encrypted. Honest tradeoff: not in browsers, iOS still in public beta, and AGPL-licensed. ## Privacy and trust, plainly This kind of product depends on you being able to check claims, not just believe them. UniClipboard is open source. The crypto stack uses well-reviewed primitives — no rolled-your-own crypto. Local storage is encrypted at rest. The transport layer is independent of the encryption layer, so the relay’s role is structurally limited to moving ciphertext. If you care about the details: - The relay sees ciphertext, peer IDs, byte counts, and timing. It does not see clipboard content, clipboard type, device names, or the pairing passphrase. - Local history is stored encrypted on each device. - The license is AGPL-3.0 — chosen specifically so a fork cannot quietly weaken the privacy story behind a closed-source hosted service. None of that replaces a third-party audit. It does mean the design is set up so that the trust surface stays small and inspectable. ## Who this is the right fit for - People with a Mac and a Windows or Linux machine (or all three) who want their clipboard to follow them, full stop. - Developers and operators who occasionally copy things they do not want sitting in a chat app forever. - Privacy-conscious users who do not want to create another account just to paste a URL. - Self-hosters who actually do not want to host a clipboard. - Anyone who has caught themselves DMing themselves on Telegram three times in the same hour. If you need clipboard sync to your phone today, or you specifically want to operate a server, this is not the right tool — and we would rather say so than try to talk you into the wrong shape. ## FAQ ### Does “no cloud account” mean it never touches the network? No. It means there is no UniClipboard cloud account, no central clipboard database, and nothing to sign up for. Devices still need to reach each other over the network. They try direct P2P first, and fall back to an encrypted relay when direct connection is not possible. The relay only sees ciphertext. ### Can the relay read my clipboard? No. Clipboard payloads are encrypted on the source device with a key the relay does not have. The relay sees encrypted bytes, peer IDs, and traffic metadata like byte counts and timing. It does not see clipboard content, clipboard type, device names, or the pairing passphrase. ### Why not just use Tailscale plus a script? You can. Tailscale is great. The cost is that every device needs Tailscale installed and configured, every machine joins the same tailnet, and you still have to wire up cross-platform clipboard APIs and a history layer yourself. UniClipboard tries to be a one-install answer to the same problem, with no separate networking product to set up. ### Is this going to work on a corporate / VPN-locked laptop? Often, yes — that is exactly the case the relay fallback is for. When direct P2P fails (which happens on hostile NATs, locked-down corp networks, and some mobile tethering), the encrypted relay carries the ciphertext between devices. You do not have to set up a VPN tunnel between the two networks for this. ### Does it support Android or iOS? Yes. Alongside the macOS, Windows, and Linux desktop apps there is a native Android app (signed APK) and an iOS public beta on TestFlight. If you prefer not to install a native app, the SyncClipboard open protocol still works over LAN via iPhone Shortcuts or a SyncClipboard-compatible Android client. ### Is the clipboard history shared across devices, or local per device? History is stored locally on each device, encrypted at rest. New clipboard items sync between paired devices, but each device keeps its own searchable history rather than every item being mirrored to a central place. ### Why AGPL? Deliberate. AGPL prevents anyone from forking the project into a closed-source hosted service that quietly weakens the privacy guarantees and keeps those changes private. For a product whose value depends on a privacy claim, the license is part of how that claim is enforced. ## Try it If your clipboard problem really is “Mac plus Windows plus Linux, no cloud account, no server”, this is what UniClipboard is built for. - Website: - GitHub: Pair two devices, copy something on one, paste it on the other. If it stops feeling like a chore, that is the point. --- --- > **Source**: https://www.uniclipboard.app/zh/blog/sync-clipboard-mac-windows-linux-without-cloud-account > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: 你在 Mac 上复制了一段长链接，想粘到 Windows 桌面，或者家里那台 Linux。常见的“解决方案”其实都挺糟糕： # 不用云账号，在 Mac、Windows、Linux 之间同步剪贴板 **你在 Mac 上复制了一段长链接，想粘到 Windows 桌面，或者家里那台 Linux。常见的“解决方案”其实都挺糟糕：** 你在 Mac 上复制了一段长链接，想粘到 Windows 桌面，或者家里那台 Linux。常见的“解决方案”其实都挺糟糕： - 在 Telegram、WhatsApp、Discord、Slack 给自己发一条消息。 - 给自己发一封邮件。又一次。 - 在两台机器都登一下云笔记，找一条“草稿”笔记往里粘。 - 注册一个剪贴板 SaaS，再多一个账号。 - 装 Syncthing 或 Tailscale 加一段自己写的脚本，叫它“自托管”。 这些工具没一个是为剪贴板设计的。而且它们对剪贴板里实际会出现的东西（密码、API key、内网链接、半段草稿）也都不太友好。 这篇页面要讲的是 UniClipboard 专门盯的那条窄缝：**跨 Mac、Windows、Linux 的剪贴板同步，不要云账号，不要自托管，跨公网端到端加密。** 先把话说清楚：“不要云账号”不是“不走网络”。设备会先尝试 P2P 直连。当网络不配合时，流量会走加密中继兜底。中继可以转发字节，但读不到你的剪贴板。 ## 太长不看 - **三个桌面，零注册。** UniClipboard 是开源的，跑在 macOS、Windows、Linux 上。没有 UniClipboard 云账号，也不需要登录什么东西。 - **直接配对设备。** 两台设备走一次短配对流程。之后这边复制，那边粘贴。 - **优先 P2P 直连，加密中继兜底。** 不需要 VPN，不需要 Tailscale，不需要端口转发。中继看到的是密文、peer ID、字节大小和时间戳，看不到剪贴板内容、剪贴板类型、设备名、配对口令。 - **加密的本地剪贴板历史 + 全文搜索。** 不只是“同步最新一条”。历史留在每台设备本地，加密落盘。 - **诚实交代现状。** iOS 在 TestFlight 公测，Android 提供原生 App（签名 APK）；这页会直说哪些已稳定、哪些还在公测，不绕弯。 ## 给自己发消息为什么很难用 “在 Telegram 给自己发一条”应付一条 URL 没问题。多发几次就开始难受： - 它是明文的。所有自发自收的消息都躺在别人服务器上的聊天记录里，由对方索引、检索、按对方的策略保留。 - 它是单向的。要切应用，找到对应聊天，从消息气泡里复制，再粘贴回去。这不是剪贴板，这是聊天软件硬装成剪贴板。 - 它把信道混在一起。十秒前你想要在另一台机器上的内容，现在和别人发来的消息、群链接、机器人提醒夹在一起。 - 它对敏感内容不友好。API key、恢复码这种东西不该长期住在 DM 历史里。 最糟的部分是它会让你忘掉成本。久了之后，你已经记不清自己默默在 Telegram 或 WhatsApp 上转发过多少条 token、路径、片段，只为了在另一台机器上用三十秒。 剪贴板同步工具应该让这个习惯没必要存在。 ## 云剪贴板为什么敏感 “注册、装客户端、同步”那种典型的云剪贴板服务有一个结构性问题：你的剪贴板内容会出现在别人服务器上，而那种形式上，理论上是有可能被你之外的某个角色读到的。 对杂货清单来说也许无所谓。但对这些就不是： - 从密码管理器粘出来的密码； - API key、部署 token、GitHub PAT； - 内网链接、主机名； - 不小心带上凭据的代码片段； - 草稿、日记、私聊里的文字。 剪贴板里大部分内容是平淡的，问题是其中一小部分不是，而你在实时操作的当下没法把这两类分开。所以问题就变成：你愿不愿意把这一切的并集——包括那些你绝不会主动上传的东西——都交给一个第三方服务？ “我们加密你的剪贴板”和“我们读不到你的剪贴板”不是同一件事。真正要看的细节是密钥放在哪、服务端有没有那个能力去读，以及如果被强制要求时它会怎样。 UniClipboard 在这块的立场刻意收得很窄：剪贴板 payload 在源设备上用中继没有的密钥加密，到接收设备上才解开。传输层——不管直连还是中继——永远拿不到明文。 ## 自己跑一台剪贴板服务器一般是杀鸡用牛刀 下一个本能反应，尤其在自托管圈，是：自己跑个服务器吧。 自托管一个同步服务器，所有设备指过去，搞定。对一部分人来说这就是正解，开源圈也有这种形态的好项目。 但对“只是想让剪贴板跟着我跨三台桌面走”的大多数人来说，这是过度设计： - 服务器是你从此要养着的东西。更新、证书、端口、反代、备份，整套维护负担。 - 它是平时感觉不到、坏的时候才想起的基础设施——往往恰好是你急着要粘的时候。 - 你还得操心权限、注册、消息大小、CORS 这些“顺手做了个小 SaaS”的清单项。 - 对剪贴板这种功能来说，运维复杂度和它带来的价值完全不成比例。 自托管在你本身就喜欢运行这种东西时才划得来。否则，剪贴板就静悄悄地变成 homelab 上又一件杂活。 ## 无账号 P2P 配对怎么补这个缺口 UniClipboard 卡在“给自己发消息”和“自己跑服务器”之间。形状是这样的： 1. 在你关心的每台桌面上装好它。 2. 一次性把它们配对起来。不要邮箱，不要注册，不要云账号。 3. 配对完成后，设备会尝试在所在网络上直接 P2P 通信。 4. 直连建立不起来时（公司网络、恶劣 NAT、移动热点），流量走加密中继兜底。 5. 不管走哪条路，剪贴板内容都是端到端加密的。中继看到的永远只是密文。 这里有几件事很关键： **配对，不是登录。** 没有 UniClipboard 账号。你在网络里的“身份”就是你配对过的设备。哪天不再信任某台，就解配对。 **没有中心剪贴板数据库。** 你的剪贴板没有放在 UniClipboard 服务器上，因为根本没有 UniClipboard 剪贴板服务器。每台设备只保留自己的加密本地历史。 **网络允许时优先直连。** 两台设备能直接互通时（同一局域网、友善的家庭网络、hole-punch 成功），流量根本不经过任何中继。 **中继只在兜底时出现。** 直连失败时——在真实网络上，这会发生——中继把连接缝起来。中继看到： - 加密字节（密文）； - 源 / 目标 peer ID（用于路由）； - 字节大小和时间戳。 中继**看不到**： - 剪贴板内容； - 剪贴板类型（文本/图片/文件）； - 设备名； - 配对口令。 这是有意做的切分：保住“无账号跨公网同步”的便利，同时不让任何服务器获得读你剪贴板的能力。 ## 每个平台你具体能拿到什么 UniClipboard 是用 Rust + Tauri 2 写的原生桌面应用，跑在 macOS、Windows、Linux。 - **文本** —— 这边复制，那边粘。最常见的场景，必须做到无感。 - **图片** —— 截图和图片剪贴板项跨桌面同步。 - **文件** —— 文件复制粘贴跨设备走，不只是把路径压成一个字符串。 - **加密本地历史** —— 最近的剪贴板项保留在每台设备的加密存储里，可搜索。 - **加密全文搜索** —— 想找昨天复制的命令？不用把历史导出给第三方。 **目前还做不到的：** - **移动端已上线。** 提供原生 Android App（签名 APK）和 iOS TestFlight 公测。如果不想装原生 App，也能走 SyncClipboard 开放协议在局域网内同步——iPhone 用系统「快捷指令」，Android 用任意兼容 SyncClipboard 的客户端。 - **没有 Web 应用。** 这是有意的。Web 剪贴板意味着托管剪贴板，正好是这个产品要避开的东西。 - **不做“分享给别人”模式。** UniClipboard 是把你自己的剪贴板在你自己的设备之间同步，不是跨用户分享。 ## 用一分钟跑通 安装路径刻意短： 1. **在你想同步的桌面上装上 UniClipboard。** Mac、Windows、Linux 都在官网下载。 2. **在第一台设备打开 app，开始配对。** 3. **在第二台设备输入配对码或扫提示。** 整个过程你需要交换的凭据就这一次。 4. **在第一台设备复制点东西。** 5. **在第二台设备粘贴。** 没有“注册账号”这一步，因为没有账号。也没有“配置服务器地址”，因为没有需要你指过去的服务器。 如果两台设备在同一局域网里配对，第一次连接通常是直连。如果在不同网络，UniClipboard 能 hole-punch 就 hole-punch，不能就走加密中继兜底。 ## 跟常见替代方案的对比 简短一遍，不踩别人，只说每种形状适合谁。 - **聊天软件给自己发消息。** 上手最快，其他全输。明文存在别人服务器上，跟正常聊天混在一起，没有真正的历史搜索，还会让你养成发不该发的内容的习惯。偶尔一条 URL 还行，长期当工具用很糟。 - **云剪贴板 SaaS。** UX 流畅，对非敏感用途也许合适。结构性顾虑还是那个：你剪贴板里的所有东西的并集都躺在别人服务器上。 - **Apple 通用剪贴板。** 在纯苹果生态里很好。一旦你有 Windows 或 Linux 机器就解决不了。 - **自托管同步服务器。** 你真的想运行服务器时，是合理选择。如果你只是想用剪贴板，对一台剪贴板服务器来说零件太多了。 - **Tailscale + 脚本 + Syncthing + …** 能用，Tailscale 整体也很好。但每多一个组件就要在每台机器上安装、配置、维护，只为了把剪贴板那点事做完。 - **UniClipboard。** 桌面加移动端，不要云账号，不需要跑服务器，端到端加密。诚实交代代价：不在浏览器里，iOS 仍在公测，许可证是 AGPL。 ## 隐私和信任，直说 这种产品的前提是你能去验证声称，而不只是“相信我们”。 UniClipboard 是开源的。加密用的是经过广泛 review 的原语，没有自造加密。本地存储加密落盘。传输层独立于加密层，所以中继的角色在结构上就被限制成只能搬密文。 如果你想看细节： - 中继看到的是密文、peer ID、字节大小、时间戳。看不到剪贴板内容、剪贴板类型、设备名、配对口令。 - 本地历史在每台设备上加密存储。 - 许可证是 AGPL-3.0，专门为了防止有人 fork 一份做闭源托管，私下削弱隐私保证。 这些不能替代第三方 audit。但它意味着设计上的信任面被尽量收小，并且对外可查。 ## 谁适合用 - 同时有 Mac 和 Windows 或 Linux 机器（或者三个都有）的人，只是想让剪贴板跟着自己走。 - 偶尔会复制一些不愿意永久躺在聊天软件里的内容的开发者和运维。 - 不想为了粘一条 URL 再注册一个账号的隐私敏感用户。 - 不想再多托管一个服务的自托管玩家。 - 一个小时内已经给自己 DM 三次的人。 如果你今天就需要跨手机同步剪贴板，或者你专门想运行一台服务器，这个工具不合适——我们宁可直说，也不愿意把你哄进错的形状里。 ## 常见问题 ### “不要云账号”是不是就完全不走网络？ 不是。它的意思是没有 UniClipboard 云账号、没有中心剪贴板数据库、没有要你注册的东西。设备之间还是要走网络。先尝试 P2P 直连，直连不行再走加密中继兜底。中继只看到密文。 ### 中继能读到我的剪贴板吗？ 不能。剪贴板 payload 在源设备上用中继没有的密钥加密。中继看到的是加密字节、peer ID、以及字节数量和时间戳这种流量元数据。它看不到剪贴板内容、剪贴板类型、设备名、配对口令。 ### 为什么不直接用 Tailscale + 一段脚本？ 可以。Tailscale 很好。代价是每台机器都得装 Tailscale、加入同一个 tailnet，并且你还要自己接好跨平台剪贴板 API 和历史层。UniClipboard 想做的是“装一次就解决”的形状，不要再额外接一个网络产品。 ### 在公司网络 / VPN 限死的笔记本上能用吗？ 经常可以——这就是中继兜底要解决的场景。直连 P2P 失败时（恶劣 NAT、封得很严的公司网、部分手机热点），加密中继会把密文在两台设备之间搬过去。你不需要在两个网络之间再搭一条 VPN 隧道。 ### 支持 Android 或 iOS 吗？ 支持。除 macOS、Windows、Linux 桌面端外，已有原生 Android App（签名 APK）和 iOS TestFlight 公测。如果不想装原生 App，也可以走 SyncClipboard 开放协议在局域网内同步——iPhone 用「快捷指令」，Android 用兼容 SyncClipboard 的客户端。 ### 剪贴板历史是跨设备共享，还是每台设备本地的？ 每台设备本地保存，加密落盘。新的剪贴板项会在已配对设备之间同步，但每台设备保留各自可搜索的历史，而不是把每条都镜像到一个中心位置。 ### 为什么用 AGPL？ 故意的。AGPL 防止有人 fork 一份做闭源托管，私下削弱隐私保证又不公开改动。对一个靠隐私声称立足的产品来说，许可证就是这种声称的强制约束之一。 ## 试一下 如果你的剪贴板问题确实是“Mac + Windows + Linux，不要云账号，不要服务器”，那 UniClipboard 就是为这件事做的。 - 官网： - GitHub： 配对两台设备，这边复制，那边粘贴。如果你不再觉得这件事是负担，那就是它的目标。 --- > **Source**: https://www.uniclipboard.app/blog/best-open-source-clipboard-sync-mac-windows-linux > **Locale**: English > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: An honest buyer's guide to open-source clipboard sync across macOS, Windows, and Linux. KDE Connect, Synergy/Barrier/Deskflow, Syncthing+Tailscale, ClipCascade, UniClipboard — when each one is the right choice. # Best open-source clipboard sync between Mac, Windows and Linux **Most people who search for this don't actually want a list of every clipboard tool that exists. They want a tool that:** Most people who search for this don't actually want a list of every clipboard tool that exists. They want a tool that: - works on **macOS, Windows, and Linux** — all three, as first-class citizens; - is **open source**, so the privacy claim can be checked, not just trusted; - doesn't force a **cloud account** (Apple ID, Google account, vendor login); - doesn't require **self-hosting a server** to use; - is **end-to-end encrypted** when traffic crosses the public internet; - has **clipboard history**, not just "the latest item". That is a narrower combination than it sounds. Most tools cover three or four of those, but tripping on one of them. This guide goes through the realistic options by category, says when each is genuinely the better fit, and explains where UniClipboard sits. UniClipboard is one of the projects in this space — full disclosure, this guide is published on its site. The goal here isn't to dunk on alternatives. They're often great at what they do. The goal is to help you pick the right one for what you actually need. ## TL;DR - **KDE Connect** — best if you mostly want **phone ↔ Linux desktop**. Cross-desktop sync is not its design center. - **Synergy / Barrier / Deskflow** — best if your machines all sit on **one desk** and you want shared keyboard/mouse with clipboard-as-side-effect. KVM-first, not network-first. - **Syncthing or Tailscale + a script** — works, especially if you already run them. Not a clipboard tool by itself; you'll wire the clipboard part yourself. - **ClipCascade** — best if you specifically want a **self-hosted clipboard server** with a web dashboard and Android support. - **UniClipboard** — best if you want **open source + Mac/Win/Linux + no cloud account + no self-hosted server + end-to-end encryption** in one package, plus encrypted clipboard history. If your requirement set matches that last bullet, UniClipboard is what this site is built for. If it doesn't, the other options below are likely a better fit. ## What "good" actually looks like for cross-OS clipboard sync Before comparing tools, it helps to be specific about what makes clipboard sync feel right. - **Latency is the hidden requirement.** Clipboard sync feels broken if it takes a few seconds. The mental model is "copy here, alt-tab, paste". If it takes a noticeable pause, you stop trusting it and start `scp`-ing things again. - **Content type matters.** Text is easy. Images are annoying. File references are more annoying — and often the moment that exposes whether a tool was really designed for clipboards or for "just text snippets". - **The network has to be ugly-tolerant.** Most desktops sit behind home routers, NATs, and corporate VPNs. A tool that only works on the same LAN — or only with both machines on the same Tailscale — has narrowed itself out of "actually works for me". - **Privacy isn't optional for clipboards.** People copy passwords, tokens, 2FA codes, half a config file. If a tool sends that to a server in plaintext, "open source" alone doesn't fix it. - **History is a separate feature from sync.** A clipboard manager remembers what you copied earlier. A clipboard sync sends the latest item somewhere else. The good tools do both, locally and privately. Now the categories. ## The categories of open-source clipboard sync ### 1. Mobile-pairing tools (KDE Connect, GSConnect, etc.) **Best when:** your primary need is phone ↔ Linux desktop, ideally with notifications, file sharing, and clipboard as one of several features. **Strengths:** - Mature, packaged in most Linux distros. - KDE-integrated UX is excellent on KDE Plasma. - Free, open source. - Clipboard is one feature among many — handy if you also want notifications, media controls, file send. **Why it's not the answer for Mac+Win+Linux:** - Cross-desktop (Mac/Win/Linux) sync isn't the design center. - Mac and Windows support exists in various forks but isn't first-class. - Clipboard sync is a side feature, so history, search, and reliability are not the main investment. If your three devices are an Android phone, a Linux laptop, and another Linux box, KDE Connect is genuinely a great answer. If they're a MacBook, a Windows desktop, and a Linux box, you'll feel the gap. ### 2. KVM-first tools (Synergy, Barrier, Deskflow, Input Leap) **Best when:** all your machines sit on one desk, and you want one keyboard and mouse to drive several screens, with the clipboard following the cursor. **Strengths:** - Solid, long-running open-source roots (Barrier → Deskflow / Input Leap). - Cross-platform across macOS, Windows, and Linux. - The "mouse glides between screens" UX is unmatched if that's what you want. **Where they're not optimized:** - Clipboard is a **side effect of being a KVM**, not the main feature. There's no clipboard history, no encrypted local search. - File sync is partial: it often degrades to "filename as text" rather than a real file reference. Image clipboard sync exists in Barrier but is slow on large images. (See Barrier issues [#1507](https://github.com/debauchee/barrier/issues/1507) and [#971](https://github.com/debauchee/barrier/issues/971) for context.) - These are **client/server** designs: one machine runs the server, others connect to it. The server has to be running for sync to happen. - Cross-network usage typically requires a VPN or tunnel; they're built for one local network. If your day looks like "two screens on the same desk, mouse glides between them," Synergy / Deskflow is genuinely better than a clipboard-only tool. If your day looks like "work laptop on a corp VPN, home desktop on a different network, both need to share clipboard," they don't really solve that without standing up another VPN tunnel between them. ### 3. Roll-your-own with Syncthing or Tailscale **Best when:** you already run Syncthing or Tailscale for other reasons and you're comfortable wiring up your own clipboard glue. **Strengths:** - These are excellent tools. Syncthing has years of real-world sync experience baked in. Tailscale gives you a private mesh between your devices with very little setup. - Both are open source (Syncthing fully, Tailscale's clients). - If you already have either running, the marginal cost of wiring a clipboard hook is small. **Where it gets awkward:** - **Syncthing is folder sync.** Clipboard sync built on top of it usually means "watch a file, copy from it, write to it" — which is fine for a script but introduces filesystem polling latency. Sub-second clipboard sync is hard with that loop. - **Tailscale + a script** works, but it's two pieces of infrastructure (Tailscale daemon + your script) on every machine, plus you still need to write the cross-platform clipboard API code, and still need to handle history yourself. - Neither approach gives you encrypted clipboard history or full-text search out of the box. You'd build those. If you already live inside Tailscale and you enjoy maintaining personal scripts, this is a reasonable path. For most people, "install one app on each machine" is less work than "deploy two daemons and write the connector". ### 4. Self-hosted clipboard servers (ClipCascade) **Best when:** you specifically want to **own and operate a clipboard server**, with a web dashboard, server-side configuration, and Android support today. **Strengths:** - Open source, self-hostable via Docker or a Java JAR. - Includes Android client support. - A central server you control is good for centralized account management or policy. - Public community server exists if you don't want to self-host yet. **Where the cost shows up:** - Self-hosting a clipboard server means container, volumes, possibly an exposed port, reverse proxy, signup policy, updates — clipboard sync becomes a small production service. - For users who don't already operate a homelab, that's a non-trivial maintenance commitment for one feature. If self-hosting is part of your requirement (compliance reasons, homelab pride, Android first), ClipCascade is a legitimate answer. If your actual goal is "I just want my clipboard to follow me without trusting a vendor cloud," see the next category. For a deeper comparison, see [ClipCascade alternative: open-source clipboard sync without running a server](/compare/clipcascade). ### 5. Accountless P2P clipboard tools (UniClipboard) **Best when:** you want **all** of these at once — open source, Mac/Win/Linux, no cloud account, no self-hosted server, end-to-end encryption across the public internet, and a real local clipboard history. **What it is:** - Open-source desktop app for macOS, Windows, and Linux. - Built in Rust + Tauri 2; uses [iroh](https://www.iroh.computer/) for peer-to-peer connectivity and NAT traversal. - Devices pair directly with each other — no UniClipboard cloud account, no signup, no server you have to host. - End-to-end encrypted across networks. When direct P2P fails, traffic falls back to an encrypted relay; the relay sees ciphertext and routing metadata, not clipboard content. - Encrypted local clipboard history with full-text search across what you've copied. - Text, image, and file clipboard support on desktop. **Honest limitations:** - **Mobile is now available.** iOS is in public beta on TestFlight and there is a native Android app (signed APK); the SyncClipboard protocol also works as a LAN fallback. For a longer-established mobile story, ClipCascade and KDE Connect are still strong. - **Younger than libp2p / Syncthing.** The networking stack (iroh) is solid but evolving — see the design notes in [Why I picked iroh for UniClipboard](https://uniclipboard.app/en/blog/why-iroh-not-libp2p-webrtc) if you care about that layer. - **Not a KVM.** If you want one keyboard/mouse across machines on one desk, Synergy/Deskflow is the right tool, not UniClipboard. UniClipboard is the project this guide is published by, so treat the framing accordingly. The honest version is: it was built specifically for the gap left by the other categories above — three desktops, no cloud account, no server to host, real privacy, and a queryable history. ## A side-by-side table | Requirement | KDE Connect | Synergy / Deskflow | Syncthing+script | Tailscale+script | ClipCascade | UniClipboard | |---|---|---|---|---|---|---| | Open source | Yes | Yes | Yes | Clients yes | Yes | Yes | | macOS / Windows / Linux all first-class | Linux-first | Yes | Yes | Yes | Yes | Yes | | Works without a cloud account | Yes | Yes | Yes | Tailscale account | Server account | Yes | | Works without self-hosting a server | Yes | Server one of your machines | Discovery server / relays | Tailscale infra | Self-host or community server | Yes | | End-to-end encrypted across the internet | LAN-focused | LAN-focused | Yes | Yes | Yes (per README) | Yes | | Clipboard history with search | No | No | Build it | Build it | Not core | Yes (encrypted) | | Image / file clipboard sync | Partial | Partial | Build it | Build it | Yes | Yes | | Android client today | Yes | No | Yes (file sync only) | Yes (Tailscale, not clipboard) | Yes | Yes (native app) | | Best fit | Phone ↔ Linux | KVM on one desk | DIY folder sync | DIY mesh | Self-hosted server | Accountless desktop sync | Footnote: ClipCascade behavior is summarized from its README at https://github.com/Sathvik-Rao/ClipCascade. Verify against the project for the current behavior before relying on it. ## How to pick Run through this in order: 1. **Do you need mobile today?** If yes, and primarily Android ↔ Linux, look at KDE Connect. If you need Android plus desktops with a server you control, look at ClipCascade. 2. **Are all your machines on one desk and you want one keyboard/mouse?** Use Synergy / Deskflow / Input Leap. Clipboard will follow the cursor. 3. **Do you already operate Tailscale or Syncthing and enjoy gluing things together?** A clipboard hook on top of those is a reasonable weekend project. 4. **Do you want to own and operate a clipboard server?** ClipCascade is built for that. 5. **Do you want the open-source / accountless / no-server / E2EE / history combination across Mac+Win+Linux without homework?** That's the slot UniClipboard is built for. If you answered yes to anything before step 5, that earlier tool is probably the right call. ## Why the relay distinction matters If you've read this far, you've probably noticed every option has some "trust" question. - KDE Connect / KVM tools: usually LAN-only, so trust is local network access. - Tailscale: trust includes Tailscale's control plane. - ClipCascade self-hosted: trust is your own server, which you have to run correctly. - ClipCascade community server: trust is the server operator. - UniClipboard: when direct P2P succeeds, traffic doesn't touch a third party. When it falls back to relay, the relay sees ciphertext and routing metadata. For UniClipboard specifically, the relay can see: - encrypted bytes (ciphertext); - source and destination peer IDs (for routing); - byte counts and timing. It can **not** see: - clipboard content; - clipboard type (text / image / file); - device names; - the pairing passphrase. That's a property of the cryptography, not a marketing promise. The encryption layer is independent of the transport layer; the relay is treated as an untrusted hop. If you want to verify, the code is on GitHub. ## A grounded recommendation If you've genuinely tried a few of the tools above and ended up in a slightly different one for each pair of machines, you're not alone. The category is fragmented because the design centers are different. For the specific intersection — open source, Mac+Win+Linux, no cloud account, no self-hosted server, E2EE across the public internet, with encrypted clipboard history — UniClipboard is the project that was built for that exact intersection. It's not "better than KDE Connect" or "better than Synergy". It's a different shape, aimed at the requirement set above. If your requirement set is different, the other tools in this guide are honestly good at what they do. ## FAQ ### What is the best open-source clipboard sync for Mac, Windows, and Linux? There's no single winner — it depends on whether you also need mobile, whether you want a self-hosted server, and whether you're okay with a cloud account. For sync across desktops and mobile with no account and no server to host, UniClipboard fits that gap. For mobile-included with a self-hosted server, ClipCascade is a strong choice. For shared keyboard/mouse on one desk, Synergy / Deskflow is better than any clipboard-only tool. ### Does UniClipboard work without a cloud account? Yes. There is no UniClipboard account, no Apple ID requirement, no Google account, and no vendor login. You install the app on each desktop and pair the devices directly. Pairing is a passphrase between the two devices; UniClipboard's servers are not in the loop for clipboard content. ### Does UniClipboard require running my own server? No. It's not self-hosted. Devices pair peer-to-peer and connect directly when the network allows. When direct connection isn't possible, an encrypted relay forwards bytes between devices — the relay can't read clipboard content because everything is encrypted before transport. If you want LAN-only behavior, that mode exists. ### Is clipboard sync over the public internet safe? It depends on the tool. Clipboard sync is only as safe as its weakest network hop. UniClipboard's design is end-to-end encryption with the transport layer (including any relay) treated as untrusted. KDE Connect and Synergy-family tools were designed for trusted local networks, not arbitrary internet links. Self-hosted tools like ClipCascade move the trust to your own server. Pick the model whose trust assumptions match your real-world environment. ### Does UniClipboard support Android or iOS? Yes. iOS is in public beta on TestFlight and there is a native Android app (signed APK); the SyncClipboard protocol also works as a LAN-only fallback. ClipCascade and KDE Connect remain solid if you want a longer-established mobile client. ### What about clipboard history — does any sync tool actually keep one? Most sync-focused tools sync the **latest** clipboard item only and don't keep a queryable history. KVM-first tools (Synergy / Barrier / Deskflow) don't keep history. Roll-your-own setups don't unless you build it. UniClipboard keeps an encrypted local history with full-text search across what you've copied. ClipCascade focuses on sync rather than rich local history. ### What's the catch with UniClipboard? Two honest catches. First, iOS is still in public beta (Android ships as a signed APK). Second, the underlying P2P stack (iroh) is younger than libp2p or Syncthing's protocol — there's been some 0.x churn, though the API surface UniClipboard relies on is small. If those are deal-breakers for you, one of the other tools in this guide may be a better fit. ## Try UniClipboard If your requirements are open source, all three desktops, no cloud account, no self-hosted server, and end-to-end encryption across the public internet, UniClipboard is built for exactly that intersection. - Website: https://uniclipboard.app - GitHub: https://github.com/uniclipboard/uniclipboard If you find a tool that fits the same requirement set better, please tell us — we'd rather use it than market against it. --- --- > **Source**: https://www.uniclipboard.app/zh/blog/best-open-source-clipboard-sync-mac-windows-linux > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: 搜这个关键词的人，其实很少真的在找"剪贴板工具大全"。大多数人想要的是一个**同时**满足这些条件的工具： # Mac、Windows、Linux 之间最好的开源剪贴板同步工具 **搜这个关键词的人，其实很少真的在找"剪贴板工具大全"。大多数人想要的是一个**同时**满足这些条件的工具：** 搜这个关键词的人，其实很少真的在找"剪贴板工具大全"。大多数人想要的是一个**同时**满足这些条件的工具： - 在 **macOS、Windows、Linux** 三端都是一等公民； - **开源**，隐私声明可以验证，不只是相信； - 不强制你登录一个**云账号**（Apple ID、Google 账号、厂商登录都不要）； - 不要求你**自己跑服务器**才能用； - 当流量跨公网时**端到端加密**； - 有**剪贴板历史**，不只是同步"最新一条"。 把这些都摆出来，会发现这是一个比想象中窄的组合。大多数工具能满足其中三四条，但总会卡在某一条上。这篇文章按"工具类别"梳理可选项，说明每一类**什么时候真的更合适**，再说明 UniClipboard 在哪个位置。 UniClipboard 是这一类里的一个项目——这篇文章发在它的官网上，所以请相应地看待立场。这里的目标不是踩竞品。它们各自做的事都挺扎实。目标是帮你按真实需求选对工具。 ## 太长不看 - **KDE Connect**：手机 ↔ Linux 桌面 配对最强。跨桌面不是它的设计中心。 - **Synergy / Barrier / Deskflow**：所有机器在**同一张桌子上**、想用一套键鼠驱动多屏，剪贴板顺带跟着鼠标走时最强。KVM 优先，不是网络优先。 - **Syncthing 或 Tailscale + 自写脚本**：能用，尤其是你已经在跑这两个的时候。但它们本身不是剪贴板工具，剪贴板那一段你得自己接。 - **ClipCascade**：明确想要一个**自己运维的剪贴板服务器**，带 Web dashboard 和 Android 支持时最合适。 - **UniClipboard**：想要"开源 + Mac/Win/Linux + 不要云账号 + 不要自托管服务器 + 端到端加密"这个组合，再加上加密本地历史时最合适。 如果你的需求正好命中最后一条，UniClipboard 就是为这个场景做的。如果不是，上面的其它工具可能更合适。 ## 跨桌面剪贴板同步，"好"长什么样 在比较具体工具之前，先说清楚什么样的体验才算"剪贴板同步做对了"。 - **延迟是隐藏的硬要求。** 剪贴板同步如果要等几秒，就会感觉坏了。心智模型是"这边复制，alt-tab 过去，粘贴"。一旦中间有可感知的停顿，你就不再相信它，又会回去用 `scp`。 - **类型很重要。** 文本好做。图片很烦。文件引用更烦——这往往就是检验一个工具到底是为"剪贴板"做的，还是只为"文本片段"做的分水岭。 - **网络要能扛住"不漂亮"的环境。** 大多数桌面在家用路由器、NAT、公司 VPN 后面。一个只能在同一 LAN 跑、或者要求两台机器都在同一 Tailscale 上的工具，已经把自己排除在"我这儿能用"之外了。 - **剪贴板天然涉及隐私。** 人会复制密码、token、2FA、半个配置文件。如果工具明文上传这些到服务器，"开源"本身并不能解决这个问题。 - **历史和同步是两件事。** 剪贴板管理器记得你之前复制过什么，剪贴板同步把"最新一条"送到别处。好的工具两件都做，而且本地、私密。 下面进入具体类别。 ## 开源跨桌面剪贴板同步的几种类别 ### 1. 移动配对类（KDE Connect、GSConnect 等） **适合场景：** 主要需求是 手机 ↔ Linux 桌面，配套通知、文件传输，剪贴板是其中一个功能。 **优点：** - 成熟，大多数 Linux 发行版都打包了。 - 在 KDE Plasma 上集成体验非常好。 - 完全开源、免费。 - 剪贴板只是众多功能之一——如果你也想要通知、媒体控制、文件传输，很方便。 **为什么不太适合 Mac+Win+Linux：** - 跨桌面（Mac/Win/Linux）同步不是设计中心。 - Mac、Windows 的支持有 fork 但不是一等公民。 - 剪贴板是副功能，所以历史、搜索、可靠性不是主要投入方向。 如果你的三台设备是 Android 手机、Linux 笔电、另一台 Linux 机器，KDE Connect 真的很合适。如果是 MacBook、Windows 桌面、Linux 机器，你会感受到落差。 ### 2. KVM 类（Synergy、Barrier、Deskflow、Input Leap） **适合场景：** 所有机器都在同一张桌子上，想用一套键鼠驱动多屏，剪贴板跟着鼠标走。 **优点：** - 老牌开源（Barrier → Deskflow / Input Leap 这条线）。 - macOS、Windows、Linux 都有客户端。 - "鼠标在多屏间滑过去"的体验，单纯剪贴板工具做不出来。 **做得不那么好的部分：** - 剪贴板是"作为 KVM 的副产品"，不是主功能。没有剪贴板历史，没有加密本地搜索。 - 文件同步是部分支持的：经常退化成"文件名当文本"，而不是真的文件引用。Barrier 的图片剪贴板同步是有的，但大图慢。可参考 [#1507](https://github.com/debauchee/barrier/issues/1507)、[#971](https://github.com/debauchee/barrier/issues/971)。 - 它们是 **client/server** 设计：一台跑 server，其它连接它，server 必须开着。 - 跨网络使用通常需要叠一层 VPN 或隧道；天然为同一局域网设计。 如果你的日常是"两块屏在同一张桌子上，鼠标滑过去"——Synergy / Deskflow 比纯剪贴板工具更对路。如果是"工作笔电被公司 VPN 套住，家里桌面在另一个网络上，两边要共享剪贴板"，它们这套就不太能直接覆盖（除非你再搭一条 VPN 隧道）。 ### 3. 自己拼（Syncthing 或 Tailscale + 脚本） **适合场景：** 你已经因为别的原因在跑 Syncthing 或 Tailscale，并且乐意自己接剪贴板那一段胶水。 **优点：** - 这两个工具本身都很扎实。Syncthing 多年的真实同步经验都沉淀在里面，Tailscale 给你一个低门槛的设备私有网。 - 都是开源的（Syncthing 全开源，Tailscale 客户端开源）。 - 如果你已经在跑其中一个，加剪贴板钩子的边际成本很小。 **会有点别扭的地方：** - **Syncthing 是文件夹同步。** 在它上面做剪贴板，一般是"监听一个文件、读它、写它"——这对脚本是 OK 的，但引入了文件系统轮询的延迟，亚秒级同步很难。 - **Tailscale + 脚本** 能用，但那是两套基础设施（Tailscale daemon + 你的脚本），还得在每台机器装；剪贴板 API 跨平台那部分还是得你自己写；历史也得自己做。 - 这两条路都不会自带加密历史和全文搜索。要的话也得自己实现。 如果你已经住在 Tailscale 里，并且乐意维护私人脚本，这是合理路径。对大多数人来说，"在每台机器上装一个 app"还是比"部署两个 daemon 再写连接器"轻。 ### 4. 自托管剪贴板服务器（ClipCascade） **适合场景：** 你明确想要一个**自己运维的剪贴板服务器**，要 Web dashboard、要服务端配置、要 Android 客户端。 **优点：** - 开源，可通过 Docker 或 Java JAR 自托管。 - 包含 Android 客户端。 - 有一台你掌握的中心服务器，对集中账号管理或策略有价值。 - 还提供公开社区服务器，先试再决定要不要自托管。 **成本所在：** - 自托管一台剪贴板服务器，意味着容器、卷、可能的暴露端口、反代、注册策略、更新——剪贴板同步实际上变成一个小型生产服务。 - 如果你本身没在玩 homelab，为了一个功能维护这些是个非常实在的成本。 如果"自托管"本来就是需求的一部分（合规、homelab、Android 优先），ClipCascade 是合理选择。如果你的真实需求其实是"我只想我的剪贴板跟着我走，但不想信任厂商云"，看下一类。 更详细的比较见：[ClipCascade 替代方案：不用跑服务器的开源剪贴板同步](/compare/clipcascade)。 ### 5. 无账号 P2P 剪贴板（UniClipboard） **适合场景：** 你想要**同时拿到**这一组属性——开源、Mac/Win/Linux、不要云账号、不要自托管服务器、跨公网端到端加密、加上真正的本地剪贴板历史。 **它是什么：** - macOS、Windows、Linux 的开源桌面应用。 - Rust + Tauri 2 实现；P2P 与 NAT 穿透层用 [iroh](https://www.iroh.computer/)。 - 设备之间直接配对——没有 UniClipboard 云账号，不用注册，不用你自己跑服务器。 - 跨网络端到端加密。直连 P2P 失败时，流量会走加密中继；中继看到的是密文和路由元数据，看不到剪贴板内容。 - 加密本地剪贴板历史，可全文搜索你复制过的内容。 - 桌面端支持文本、图片、文件。 **诚实的局限：** - **移动端已上线。** iOS 在 TestFlight 公测，Android 提供原生 App（签名 APK）；不想装原生 App 也能走 SyncClipboard 协议在局域网内同步。想要更成熟的移动方案，ClipCascade、KDE Connect 也不错。 - **比 libp2p / Syncthing 年轻。** 底层网络栈（iroh）扎实但仍在演进——具体决策可以看 [我为什么给 UniClipboard 选了 iroh](https://uniclipboard.app/zh/blog/why-iroh-not-libp2p-webrtc)。 - **不是 KVM。** 想要"一张桌子上一套键鼠多屏"，还是用 Synergy/Deskflow，不是 UniClipboard。 UniClipboard 是这篇文章发布所在的项目，请相应地看待立场。诚实版是：它就是为上面那几类工具留下的那个具体缺口做的——三个桌面端、不要云账号、不要自托管服务器、真隐私、可查询的历史。 ## 一张对比表 | 需求 | KDE Connect | Synergy / Deskflow | Syncthing+脚本 | Tailscale+脚本 | ClipCascade | UniClipboard | |---|---|---|---|---|---|---| | 开源 | 是 | 是 | 是 | 客户端开源 | 是 | 是 | | Mac/Win/Linux 都是一等公民 | Linux 优先 | 是 | 是 | 是 | 是 | 是 | | 不需要云账号 | 是 | 是 | 是 | 需要 Tailscale 账号 | 服务端账号 | 是 | | 不需要自托管服务器 | 是 | 其中一台当服务器 | 依赖发现/中继 | Tailscale 基础设施 | 自托管或社区服务器 | 是 | | 跨公网端到端加密 | 偏 LAN | 偏 LAN | 是 | 是 | 是（按 README） | 是 | | 剪贴板历史 + 搜索 | 无 | 无 | 自己做 | 自己做 | 不是核心 | 是（加密） | | 图片 / 文件剪贴板 | 部分 | 部分 | 自己做 | 自己做 | 是 | 是 | | 当下有 Android 客户端 | 是 | 无 | 是（仅文件） | 是（不是剪贴板） | 是 | 是（原生 App） | | 最适合 | 手机 ↔ Linux | 同桌 KVM | DIY 文件夹同步 | DIY 私有网 | 自托管服务器 | 无账号桌面同步 | 注：ClipCascade 行为基于其 README（https://github.com/Sathvik-Rao/ClipCascade）总结。具体使用前请以仓库为准。 ## 怎么选 按这个顺序过一遍： 1. **现在就需要移动端吗？** 主要是 Android ↔ Linux，看 KDE Connect。需要 Android + 桌面 + 自己控制的服务器，看 ClipCascade。 2. **机器都在一张桌子上，想要一套键鼠？** 用 Synergy / Deskflow / Input Leap，剪贴板跟鼠标走。 3. **你已经在跑 Tailscale 或 Syncthing，并且乐意拼脚本？** 在它们上面接剪贴板钩子是个合理周末项目。 4. **你想要拥有并运维一台剪贴板服务器？** ClipCascade 是为这件事做的。 5. **你想要"开源 / 无账号 / 无服务器 / E2EE / 历史"这一整套，跨 Mac+Win+Linux，不想做家庭作业？** 这正是 UniClipboard 设计针对的位置。 如果你在第 5 步之前就已经 yes 了，那个更早的工具大概就是对的。 ## 中继到底能看到什么——为什么这点重要 每种方案都有自己的"信任问题"： - KDE Connect / KVM：通常 LAN-only，信任的是本地网络访问权。 - Tailscale：信任范围包含 Tailscale 控制面。 - ClipCascade 自托管：信任你自己的服务器（前提是你能正确地维护它）。 - ClipCascade 社区服务器：信任服务器运维方。 - UniClipboard：直连 P2P 成功时，流量不经过第三方；走中继时，中继只看到密文和路由元数据。 具体到 UniClipboard，中继**看得到**： - 加密字节（密文）； - 源 / 目标 peer ID（用于路由）； - 字节大小和时间。 **看不到**： - 剪贴板内容； - 剪贴板类型（文本 / 图片 / 文件）； - 设备名； - 配对口令。 这是密码学的属性，不是营销承诺。加密层独立于传输层，中继被当作不可信中间跳。代码在 GitHub 上，可以自己核验。 ## 一个有立场的推荐 如果你认真试过上面几类工具，最后每一对设备落在不同工具上——你不是一个人。这个赛道之所以分裂，是因为各家的设计中心不一样。 对"开源 + Mac+Win+Linux + 不要云账号 + 不要自托管服务器 + 跨公网 E2EE + 加密本地历史"这个具体交集，UniClipboard 就是为这个交集做的项目。它不是"比 KDE Connect 强"或者"比 Synergy 强"，是另一种形态，针对上面这组需求。 如果你的需求和这组不同，本文里其它工具老老实实就是更合适。 ## FAQ ### Mac、Windows、Linux 之间最好的开源剪贴板同步工具是哪个？ 没有单一赢家——取决于你是否也要移动端、是否想要自托管服务器、能不能接受云账号。如果要在桌面和移动端之间同步、不要账号、不要自己跑服务器，UniClipboard 命中这个缺口。需要带移动端 + 自托管服务器，ClipCascade 更合适。同一张桌子上一套键鼠多屏，Synergy / Deskflow 比任何"纯剪贴板"工具都更对路。 ### UniClipboard 真的可以不要云账号吗？ 可以。没有 UniClipboard 账号、不需要 Apple ID、不需要 Google 账号、没有厂商登录。每台桌面装好后，设备之间直接配对（用配对口令），UniClipboard 的服务器不在剪贴板内容的链路里。 ### UniClipboard 需要我自己跑服务器吗？ 不需要，它不是自托管模型。设备点对点配对，网络条件允许时直连。直连不可用时，加密中继转发字节——中继看不到剪贴板内容，因为传输前已经加密。需要 LAN-only 模式也有。 ### 跨公网做剪贴板同步安全吗？ 取决于工具。剪贴板同步的安全性取决于最弱那一跳。UniClipboard 的设计是端到端加密，把传输层（包括任何中继）当作不可信。KDE Connect 和 Synergy 系是为可信局域网设计的，不是为任意公网。ClipCascade 这类自托管工具，信任迁移到你自己的服务器。选信任假设和你真实环境最匹配的那一种。 ### UniClipboard 支持 Android 或 iOS 吗？ 支持。iOS 在 TestFlight 公测，Android 提供原生 App（签名 APK）；不想装原生 App 也可以走 SyncClipboard 协议在局域网内同步。想要更成熟的移动客户端，ClipCascade、KDE Connect 仍然可选。 ### 剪贴板历史这件事——同步类工具到底有哪些会留？ 大多数同步工具只同步**最新一条**，不存可查询的历史。KVM 类（Synergy / Barrier / Deskflow）不存历史。自己拼的方案默认也不会，要做你得自己实现。UniClipboard 自带加密本地历史和全文搜索。ClipCascade 主要在做同步，本地历史和搜索不是它的核心。 ### UniClipboard 有什么坑？ 两个诚实的坑。第一，iOS 仍在公测（Android 已提供签名 APK）。第二，底层 P2P 栈（iroh）比 libp2p 或 Syncthing 协议年轻，0.x 阶段会有变动；不过 UniClipboard 依赖的 iroh 接口很小，能吸收这些演进。如果这两条对你是 deal-breaker，本文里其它工具可能更合适。 ## 试试 UniClipboard 如果你的需求是开源、三个桌面端、不要云账号、不要自托管服务器、跨公网端到端加密，UniClipboard 就是为这个交集做的。 - 官网：https://uniclipboard.app - GitHub：https://github.com/uniclipboard/uniclipboard 如果你找到一个更命中这一组需求的工具，欢迎告诉我们——我们更愿意去用它，而不是和它对线。 --- > **Source**: https://www.uniclipboard.app/blog/planck-alternative-privacy-friendly-clipboard-sync > **Locale**: English > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: Looking for a privacy-friendly Planck alternative? UniClipboard is open-source clipboard sync for Mac, Windows, and Linux — no cloud account, peer-to-peer first, end-to-end encrypted, with encrypted local history and search. # Planck Alternative for Privacy-Friendly Clipboard Sync **If you found Planck and liked the idea — clipboard that follows you across Mac, Windows, and Linux — but you want something more privacy-leaning, more open, and not tied to a vendor cloud account, this page is for you.** If you found Planck and liked the idea — clipboard that follows you across Mac, Windows, and Linux — but you want something more privacy-leaning, more open, and not tied to a vendor cloud account, this page is for you. UniClipboard is built for the same problem (your clipboard should travel with you), but it makes a different bet on the trust model: **open source, no cloud account, peer-to-peer first, end-to-end encrypted, with encrypted local history and search**. Planck looks like a polished, well-designed cloud clipboard product. UniClipboard is the alternative for users whose privacy bar specifically requires: - source code you can read and audit; - no vendor cloud account holding your clipboard data, even encrypted; - direct device-to-device sync as the default path, not a hosted service; - a license that prevents the privacy guarantees from being quietly removed in a closed fork. If those four things are not your bar, Planck might be the better fit. This page is honest about that. ## TL;DR - **Planck (based on public messaging at planckapp.com):** cross-platform clipboard manager for Mac, Windows, Linux. Cloud sync model, AES-GCM-256 claimed end-to-end, data stored on AWS S3 in the US. Clipboard history with search and OCR. Free Community tier (100 items), paid Max tier (USD $19.99/mo, 10,000 items, file sync, image-to-text). Mobile listed as "coming soon." - **UniClipboard:** open-source clipboard sync (AGPL-3.0) for Mac, Windows, Linux. No cloud account. Peer-to-peer first via NAT hole-punching; encrypted relay fallback when direct P2P fails. End-to-end encrypted. Encrypted local clipboard history with encrypted full-text search. Text, images, files. Mobile is now shipping — iOS public beta on TestFlight and a native Android app (signed APK). - **Both projects encrypt clipboard payloads.** The honest difference is *who you have to trust* and *how much of the system is open*. - **Planck is the polished product if you accept a vendor cloud.** UniClipboard is the alternative if "no vendor cloud account" is part of your requirement. ## Why someone searches "Planck alternative" A few common reasons, based on how this kind of search usually plays out: 1. **You want open source.** Planck has not, based on public messaging, advertised itself as open source. For some users that is a hard requirement, especially for software that touches every clipboard event on their machine. 2. **You don't want a vendor cloud account or a paid tier gating sync features.** Cloud sync with a free tier capped at 100 items, and file sync behind a USD $19.99/mo subscription, is a reasonable product decision — it just isn't what every user wants from a clipboard tool. 3. **You don't want clipboard data on someone else's servers, even encrypted.** "Encrypted at rest on AWS S3" is a stronger story than plaintext, but it is still "your stuff sits in someone else's bucket." Some users want the bytes to never sit anywhere they don't operate. 4. **You want device-to-device sync.** Pair two laptops, copy on one, paste on the other. No service in the middle whose uptime you depend on. If any of those match, UniClipboard is built for that use case. ## What Planck does well It's worth saying this part out loud: Planck looks like a well-designed product. From its public messaging: - a clean cross-platform desktop client across Mac, Windows, Linux; - AES-GCM-256 encryption claimed, with the line "your data is never exposed when it's not in use, even to our servers"; - clipboard history with search and OCR for text inside images; - a free Community tier so users can try sync without paying; - file and folder sync available in the paid Max tier; - mobile listed as coming soon. If your priority is "I want a clipboard product that just works, looks polished, and I don't mind the cloud-and-account model," Planck is a reasonable choice. UniClipboard is not trying to argue that out of you. UniClipboard is the alternative if your priority list is shaped differently. ## Where UniClipboard is different UniClipboard makes the same core promise — clipboard sync across Mac, Windows, and Linux — and then changes the trust model under it. ### 1. Open source, AGPL-3.0 The full source is on GitHub: [uniclipboard/uniclipboard](https://github.com/uniclipboard/uniclipboard). You can read it, build it, audit it, fork it. The license is deliberate. AGPL-3.0 prevents anyone from quietly forking UniClipboard into a closed-source hosted service that weakens the privacy guarantees and keeps the changes private. For a product whose entire value proposition is "your clipboard is private," the license is what enforces the promise — without it, "we encrypt your data" becomes "until someone forks us and removes the encryption." ### 2. No cloud account There is no UniClipboard account. There is no signup form. You don't tell us your email. Devices pair directly with each other. Each device generates its own keypair locally, and pairing exchanges the keys you actually need. After that, the devices know each other. This is a different operational model from Planck. Planck's cloud product needs an identity to attach your clipboard items to. UniClipboard intentionally does not. ### 3. Peer-to-peer first, encrypted relay fallback The default sync path is direct device-to-device. UniClipboard uses [iroh](https://www.iroh.computer/) for NAT traversal — the same QUIC-over-NAT-holepunching family used in modern P2P stacks — so two devices can usually find each other across networks without anything in the middle. When direct P2P doesn't work (some symmetric NATs, restrictive corporate networks), traffic falls back through an encrypted relay. The important detail: - the relay can see encrypted bytes, peer IDs, byte counts and timing; - the relay **cannot** see clipboard content, clipboard type (text/image/file), device names, or the pairing passphrase. Encryption happens at the source device with a key the relay does not have. The relay is treated as untrusted transport. That property is independent of who is paying and independent of who runs the relay. ### 4. Encrypted local history and encrypted full-text search Clipboard history isn't stored in cleartext on disk. The local database is encrypted, and full-text search runs against encrypted data. If your laptop is lost or stolen, the history isn't sitting there in a SQLite file anyone can `SELECT * FROM` after pulling the drive. This is one of the main differentiators against most clipboard tools — not just Planck. ### 5. Honest desktop scope Mac, Windows, Linux desktop. Text, images, files. UniClipboard now ships mobile: iOS is in public beta on TestFlight and there is a native Android app (signed APK). Planck still lists mobile as "coming soon" on its pricing page. ## Side-by-side comparison | | UniClipboard | Planck (based on public messaging) | |---|---|---| | Source availability | **Open source (AGPL-3.0)** | Not advertised as open source | | Trust model | Peer-to-peer first; encrypted relay fallback | Cloud sync; data stored on AWS S3 (US) per pricing page | | Cloud account required | **No** | Account model implied by pricing tiers | | End-to-end encryption | Yes; relay only sees ciphertext | AES-GCM-256 claimed; "data is never exposed when it's not in use, even to our servers" | | Desktop platforms | macOS, Windows, Linux | macOS, Windows, Linux | | Mobile | iOS public beta (TestFlight) + native Android app | "Coming soon" per pricing page | | Text sync | Yes | Yes | | Image sync | Yes | Yes | | File sync | Yes | Max tier only (paid) | | Clipboard history | **Encrypted local history** | Yes; 100 items free tier, 10,000 items in Max | | Search | **Encrypted full-text search** | Yes; OCR/image-to-text in Max tier | | Pricing | Free, open source | Free Community tier (capped), USD $19.99/mo Max | | Vendor cloud lock-in | None — it's just paired devices | Sync depends on the hosted service | | Self-hosting | Not required (P2P first); LAN-only mode supported | Not advertised | A note on this table: Planck details are based on its official site (planckapp.com) and pricing page as of the date on this draft. If those change, this table should be updated rather than left to drift. ## What Planck and UniClipboard actually disagree on It's tempting to write this kind of page as "we are good, they are bad." That's not honest, and it's not interesting. The real disagreement is one design choice: **should clipboard sync depend on a hosted service?** Planck answers yes, and builds a polished cloud product around that — AES at rest, search, OCR, paid tiers, AWS infrastructure. That's a coherent design. UniClipboard answers no, and builds the product around device pairing — open source, P2P first, no account, encrypted local history. That's also a coherent design. Both encrypt your clipboard. The difference is in *who has to be trustworthy for the encryption story to hold*. With a cloud product, you trust the vendor's implementation, the vendor's infra, and the vendor's continued existence. With UniClipboard, you trust the source code (which is published) and the cryptographic primitives (which are well-known and used widely), and the relay is treated as untrusted by design. If you read that last paragraph and went "yeah, that's the bar I want," you're in the UniClipboard target audience. ## Migrating from Planck to UniClipboard You don't really *migrate* clipboard history between these two — clipboard history is short-lived, ephemeral working memory, not data you'd export. A reasonable switch looks more like this: 1. **Install UniClipboard** on each desktop you want to sync. macOS, Windows, Linux builds are on [github.com/uniclipboard/uniclipboard](https://github.com/uniclipboard/uniclipboard) and the website. 2. **Pair devices directly.** Generate a pairing code on the first device, enter it on the second. Repeat for additional machines. 3. **Test the core path.** Copy text on one device, paste on another. Try an image. Try a file path. 4. **Use it for a normal day.** Real test isn't a demo — it's whether you stop noticing it. 5. **Decide what to do with Planck.** If UniClipboard handles your normal flow, you can stop the Planck subscription and remove the client. If you find UniClipboard isn't covering some part of your workflow yet (OCR-on-image, image-to-text, etc.), keep what you need. There's no rush to delete the other app on day one. Run them in parallel for a bit. ## Verdict Use **Planck** if you want a polished, cloud-based clipboard product, you don't mind a vendor account, and OCR / image-to-text on a paid tier is useful to your workflow. Use **UniClipboard** if your privacy bar specifically requires: - open source you can read, - no vendor cloud account, - peer-to-peer first across the public internet, - end-to-end encryption that the relay cannot defeat, - encrypted local clipboard history with encrypted search. Mac, Windows, Linux. No cloud account. No self-hosting. End-to-end encrypted across the public internet. That's the specific gap UniClipboard is built for. ## FAQ ### Is UniClipboard a drop-in replacement for Planck? For the desktop sync use case across macOS, Windows, and Linux: yes, the core "copy on one machine, paste on another" flow is the same. For OCR-on-image and a polished freemium cloud experience: no — UniClipboard is open source and serverless by design and doesn't have an OCR feature today. Pick the one whose model matches your priorities. ### Is UniClipboard really not using a server? Direct device-to-device is the default path; that path uses no server. When direct P2P fails (some restrictive NATs), traffic falls back through an encrypted relay. The relay can route encrypted bytes — it cannot read clipboard content, clipboard type, device names, or the pairing passphrase. You can also run UniClipboard in LAN-only mode if you want to avoid the relay entirely. ### What can the relay actually see? The relay sees ciphertext, peer IDs (for routing), and byte counts and timing. It does **not** see clipboard content, clipboard type (text/image/file), device names, or the pairing passphrase. Encryption happens at the source device with a key the relay does not have. This is independent of whether the relay is operated by us, by you, or by anyone else. ### Is UniClipboard end-to-end encrypted in the same way Planck claims to be? Both projects say payloads are encrypted before they leave the device. The structural difference is the trust model. Planck's encryption sits on top of a hosted cloud, so the privacy story depends on the vendor's implementation, infra, and continued operation. UniClipboard's source is published, the relay is treated as untrusted by design, and the local history is also encrypted on disk. If you want to verify any of that, you can read the code. ### Does UniClipboard work without an account? Yes. There is no UniClipboard account. There is no signup. Devices pair directly with each other and exchange the keys they need to talk. We don't have your email, because we never asked for it. ### Is there a mobile version? Yes. iOS is in public beta on TestFlight and there is a native Android app (signed APK); the SyncClipboard open protocol also works as a LAN-only fallback. Planck still lists mobile as "coming soon" per its pricing page. ### Why AGPL-3.0 instead of a more permissive license? Deliberate. AGPL prevents anyone from forking UniClipboard into a closed-source hosted SaaS that quietly weakens the encryption and keeps the changes private. For a privacy-claim product, the license is what enforces the privacy claim. The cost is that some companies won't touch AGPL — that's a trade-off we accept. ### How do I trust the cryptography without a third-party audit? Honest answer: you don't have to trust us, you trust the primitives. UniClipboard uses well-known, widely reviewed crates — XChaCha20-Poly1305, Argon2id, SQLCipher for at-rest encryption, OS keychains for key storage. None of it is hand-rolled. The protocol is documented publicly, and the source is on GitHub. A paid third-party audit isn't done yet (we're a small project); if anyone wants to fund or run one, we're open to it. ## Try UniClipboard If "open source, no cloud account, peer-to-peer first, end-to-end encrypted clipboard sync across Mac/Win/Linux" is the shape of what you were looking for when you searched "Planck alternative": - **Website:** https://uniclipboard.app - **GitHub:** https://github.com/uniclipboard/uniclipboard Pair your devices once. Then forget the clipboard exists. That's the goal. --- --- > **Source**: https://www.uniclipboard.app/zh/blog/planck-alternative-privacy-friendly-clipboard-sync > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-07 > **Last updated**: 2026-06-01 > **Description**: 如果你找到 Planck，喜欢它"剪贴板跟着你跨 Mac / Windows / Linux 走"的想法，但你想要的是更隐私倾向、更开源、不绑定厂商云账号的方案——这页就是给你看的。 # Planck 的隐私友好替代方案：UniClipboard **如果你找到 Planck，喜欢它"剪贴板跟着你跨 Mac / Windows / Linux 走"的想法，但你想要的是更隐私倾向、更开源、不绑定厂商云账号的方案——这页就是给你看的。** 如果你找到 Planck，喜欢它"剪贴板跟着你跨 Mac / Windows / Linux 走"的想法，但你想要的是更隐私倾向、更开源、不绑定厂商云账号的方案——这页就是给你看的。 UniClipboard 解决的是同一个问题（剪贴板应该跟着你走），只是它在信任模型上做了不同选择：**开源、不要云账号、点对点优先、端到端加密、并且本地历史和搜索都加密**。 Planck 看起来是一个打磨得很好、设计很干净的云端剪贴板产品。UniClipboard 是另一个选项，**针对那些隐私门槛包含以下几条的用户**： - 想读、想审计源代码； - 不要厂商云账号保管你的剪贴板数据，哪怕是加密的； - 把"设备直连"作为默认路径，而不是依赖托管服务； - 用许可证防止隐私承诺被闭源 fork 悄悄削弱。 如果这四件事不是你的硬门槛，Planck 可能更适合你。这页对此实事求是。 ## 太长不看 - **Planck（基于 planckapp.com 的公开信息）：** 跨平台剪贴板，覆盖 Mac、Windows、Linux。云同步模型；声称 AES-GCM-256 加密；数据存放在美国 AWS S3。带历史和搜索，付费档有图片 OCR。免费 Community 档（100 条），付费 Max 档（19.99 美元/月，10,000 条、文件同步、图片转文本）。移动端"即将推出"。 - **UniClipboard：** 开源（AGPL-3.0），覆盖 Mac、Windows、Linux。**不要云账号**。点对点直连优先，使用 NAT 打洞（基于 iroh）；直连失败时回退加密中继。端到端加密；本地历史加密；全文搜索基于加密数据。支持文本、图片、文件。移动端已经发布——iOS 在 TestFlight 公测，Android 提供原生 App。 - **两边都加密剪贴板内容。** 真正不同的是：**你必须信任谁，整个系统有多少是开放的**。 - **Planck 是接受厂商云模型时的精致选择。** UniClipboard 是当"不要厂商云账号"本身就是要求时的替代方案。 ## 为什么有人会搜"Planck 替代方案" 常见的几种动机： 1. **想要开源。** Planck 在公开页面上没有强调自己是开源项目。对部分用户来说，"会触碰我每一次复制粘贴的软件必须开源"是硬门槛。 2. **不想要厂商云账号，也不想为基本同步付订阅。** 免费档 100 条上限、文件同步要 19.99 美元/月——这是一种合理的产品决策，但不是每个用户对剪贴板工具的期待。 3. **不想让剪贴板数据躺在别人的服务器上，哪怕加密。** "AES 加密静态存储在 AWS S3" 比明文好很多，但仍然是"你的内容放在你不运营的桶里"。有的用户希望字节根本不要落到自己运营之外的存储里。 4. **想要设备直连。** 两台笔记本配对，一台复制、一台粘贴，中间没有任何依赖某个服务在线的环节。 任何一条命中，UniClipboard 就是为这个场景做的。 ## Planck 做得好的地方 直说：Planck 看起来是个打磨过的产品。从公开信息看： - 跨 Mac / Windows / Linux 的桌面客户端干净统一； - 声称 AES-GCM-256 加密，并强调"你的数据闲置时不会暴露，对我们的服务器也是"； - 历史和搜索功能完整，付费档支持对图片里的文字搜索（OCR）； - 提供免费 Community 档让用户先用上同步； - 文件和文件夹同步在付费 Max 档； - 移动端列为即将推出。 如果你的优先级是"想要个干净、能用、不介意云账号 + 订阅模型的剪贴板产品"，Planck 是合理选择。UniClipboard 不打算把你劝走。 UniClipboard 是当你的优先级排列方式不一样时的替代方案。 ## UniClipboard 的不同之处 UniClipboard 给同样的核心承诺——Mac / Windows / Linux 的剪贴板同步——并把底下的信任模型换掉了。 ### 1. 开源，AGPL-3.0 完整源码在 GitHub：[uniclipboard/uniclipboard](https://github.com/uniclipboard/uniclipboard)。可读、可构建、可审计、可 fork。 许可证是有意选的。AGPL-3.0 防止有人 fork 一份做闭源托管 SaaS、削弱加密、再把改动留在私有库里。对于一个核心价值就是"你的剪贴板是私密的"的产品，许可证就是这个承诺的强制约束——没有它，"我们加密你的数据"就变成"直到有人 fork 我们并去掉加密为止"。 ### 2. 没有云账号 UniClipboard 没有账号系统、没有注册表单。不需要你的邮箱。 设备之间直接配对：每台设备本地生成自己的密钥对，配对时交换需要的密钥。之后两台设备彼此认得。 这跟 Planck 的云产品是不同模型。Planck 的云需要一个身份来挂载你的剪贴板项；UniClipboard 有意不要这个。 ### 3. 点对点优先，加密中继兜底 默认路径就是设备直连。UniClipboard 用 [iroh](https://www.iroh.computer/) 做 NAT 穿透——QUIC + 打洞——所以两台设备通常能跨网络直接找到彼此，中间不需要服务。 当直连不可行（某些对称 NAT、严格的公司网络），流量回退到加密中继。要点： - 中继看到加密字节、peer ID、字节数和时间戳； - 中继**看不到**剪贴板内容、剪贴板类型（文本/图片/文件）、设备名、配对口令。 加密发生在源设备上，密钥中继没有。中继被设计为不可信传输层。**这个性质独立于谁付费，也独立于谁运营中继。** ### 4. 加密本地历史 + 加密全文搜索 剪贴板历史不是明文存在硬盘上的。本地数据库加密；全文搜索跑在加密数据之上。笔记本丢了或被偷，硬盘拔出来后没有一个可以直接 `SELECT *` 的明文 SQLite 文件。 这是 UniClipboard 相对于大多数剪贴板工具（不只是 Planck）最关键的差异点之一。 ### 5. 桌面范围说真话 Mac、Windows、Linux 桌面。文本、图片、文件。 移动端 UniClipboard 已经发布：iOS 在 TestFlight 公测，Android 提供原生 App（签名 APK）。Planck 目前仍在 pricing 页把移动端写成“即将推出”。 ## 对比表 | | UniClipboard | Planck（基于公开信息） | |---|---|---| | 源代码可见性 | **开源（AGPL-3.0）** | 未公开声明开源 | | 信任模型 | 点对点优先；加密中继兜底 | 云同步；数据存放于 AWS S3（美国） | | 是否需要云账号 | **不需要** | 由计费档位推断有账号模型 | | 端到端加密 | 是；中继只看密文 | 声称 AES-GCM-256；"对我们的服务器也不暴露" | | 桌面平台 | macOS、Windows、Linux | macOS、Windows、Linux | | 移动端 | iOS 公测（TestFlight）+ Android 原生 App | “即将推出” | | 文本同步 | 支持 | 支持 | | 图片同步 | 支持 | 支持 | | 文件同步 | 支持 | 仅 Max 付费档 | | 剪贴板历史 | **加密本地历史** | 支持；免费档 100 条，Max 档 10,000 条 | | 搜索 | **加密全文搜索** | 支持；图片 OCR 在 Max 档 | | 价格 | 免费、开源 | 免费 Community 档（有上限），Max 19.99 美元/月 | | 厂商云锁定 | 无——只是配对设备 | 同步依赖托管服务 | | 自托管 | 不需要（P2P 优先）；支持仅局域网模式 | 未公开 | 注：表中 Planck 信息基于其官网（planckapp.com）和 pricing 页在本草稿写作时的内容。后续若变化，应以更新后的页面为准。 ## Planck 和 UniClipboard 真正分歧在哪 容易把这种对比页写成"我们好，他们差"。这不真诚，也没意思。 真正的分歧只有一个设计选择：**剪贴板同步是否应该依赖一个托管服务？** Planck 的答案是"是"，并围绕这个选择做了精致的云产品——AES 静态加密、搜索、OCR、付费档、AWS 基础设施。这是一个内部一致的设计。 UniClipboard 的答案是"否"，并围绕设备配对来做产品——开源、P2P 优先、不要账号、本地历史加密。这也是一个内部一致的设计。 两边都加密剪贴板。区别在于：**为了让加密承诺成立，谁必须可信。** 云产品里，你信任的是厂商的实现、厂商的基础设施、厂商持续存在。UniClipboard 里，你信任的是公开的源代码、广泛使用的密码学原语，而中继本身在设计上就是不可信的。 如果你看完上一段觉得"这就是我想要的门槛"——你就是 UniClipboard 的目标用户。 ## 从 Planck 迁移到 UniClipboard 剪贴板历史本来就是短期工作记忆，不是要导出迁移的数据。"迁移"意义不大。 合理的切换大概长这样： 1. **在每台桌面装 UniClipboard。** Mac、Windows、Linux 包都在 [github.com/uniclipboard/uniclipboard](https://github.com/uniclipboard/uniclipboard) 和官网。 2. **直接配对设备。** 第一台生成配对码，第二台输入。其他机器重复。 3. **测核心路径。** 一台复制文本、另一台粘贴；试图片、试文件路径。 4. **正常用一天。** 真测试不是 demo——而是你能不能不再注意到它的存在。 5. **决定 Planck 怎么处理。** 如果 UniClipboard 覆盖了你的日常，可以停掉 Planck 订阅、卸载客户端；如果发现还有功能没覆盖（图片 OCR、图片转文本等），那就保留你需要的。 不用第一天就删另一个 app。并行跑一段时间。 ## 结论 如果你想要**精致、稳定、云端、有账号体系、付费档支持图片 OCR** 的剪贴板产品 —— 选 **Planck**。 如果你的隐私门槛明确包含： - 可读源代码， - 不要厂商云账号， - 公网点对点优先， - 中继也无法解密的端到端加密， - 加密本地历史 + 加密搜索， —— 选 **UniClipboard**。 Mac、Windows、Linux。不要云账号、不要自部署、跨公网端到端加密。这就是 UniClipboard 在做的那个具体缺口。 ## FAQ（中文） ### UniClipboard 是 Planck 的无缝替代品吗？ 桌面同步主路径上是的：在 macOS / Windows / Linux 之间"一台复制、另一台粘贴"的流程一致。但是图片 OCR、付费档功能、精致云体验这些 —— UniClipboard 没有，它选择开源、无服务器化路线。看你优先级。 ### UniClipboard 真的没有服务器吗？ 默认路径是设备直连，不经服务器。直连失败（部分严苛 NAT）时，流量回退到加密中继。中继可以转发密文 —— 看不到剪贴板内容、类型、设备名或配对口令。你也可以开启仅局域网模式，完全不用中继。 ### 中继到底能看到什么？ 中继看到密文、peer ID（用于路由）、字节数和时间戳；**看不到**剪贴板内容、剪贴板类型（文本/图片/文件）、设备名、配对口令。加密发生在源设备上，密钥中继没有。这个性质和"中继是谁运营的"无关。 ### UniClipboard 的端到端加密和 Planck 声称的是一回事吗？ 两边都说 payload 离开设备前已加密。结构上的不同在于信任模型。Planck 把加密叠加在托管云之上，所以隐私故事依赖厂商的实现、基础设施和持续运营。UniClipboard 源码公开、中继在设计上就不可信、本地历史也加密。任一项都可以读代码验证。 ### UniClipboard 不需要账号？ 对。没有账号系统、没有注册流程。设备之间直接配对，交换它们之间需要的密钥。你的邮箱我们没有 —— 因为我们没问。 ### 有移动端吗？ 有。iOS 在 TestFlight 公测，Android 提供原生 App（签名 APK）；不想装原生 App 也可以走 SyncClipboard 开放协议在局域网内同步。Planck 目前仍把移动端写成“即将推出”。 ### 为什么是 AGPL-3.0 而不是更宽松的协议？ 故意选的。AGPL 防止有人 fork 一份做闭源托管 SaaS、削弱加密、又把改动留在私有库里。对隐私产品来说，许可证就是隐私承诺的强制约束。代价是有些公司不会用 AGPL —— 这个代价我们接受。 ### 没有第三方审计的情况下我怎么信任你的密码学？ 诚实答：你不必信任我们，你信任的是原语。UniClipboard 用的是经过广泛 review 的 crate —— XChaCha20-Poly1305、Argon2id、SQLCipher 做静态加密、系统钥匙串保存密钥。没有自造加密。协议有公开文档，源码在 GitHub。第三方付费 audit 还没做（我们项目还小），如果有人愿意资助或牵头，我们欢迎。 ## 试一下 UniClipboard 如果"开源、不要云账号、点对点优先、端到端加密、跨 Mac/Win/Linux"——就是你搜"Planck 替代"时心里在找的那个东西： - **官网：** https://uniclipboard.app - **GitHub：** https://github.com/uniclipboard/uniclipboard 设备配对一次，然后忘掉剪贴板的存在。这就是目标。 --- > **Source**: https://www.uniclipboard.app/blog/whitepaper > **Locale**: English > **Category**: Blog > **Published**: 2026-05-05 > **Last updated**: 2026-06-01 > **Description**: Technical whitepaper covering UniClipboard's encryption model, key handling, peer-to-peer transport, and the threat boundaries the design holds — and the ones it doesn't. # Encryption & Privacy Whitepaper **How UniClipboard keeps your clipboard yours — the cryptography, the transport, and the threats the design does and doesn't address.** ## 1. Why Clipboard Data Must Be Encrypted Clipboard content is uniquely sensitive. In the course of a normal workday it carries: * Passwords, one-time codes, API tokens, recovery phrases * Private keys, signing material, configuration snippets * Internal documents, draft messages, unreleased content * Files copied between devices Most clipboard tools treat this data as transient or harmless. In reality, it is one of the highest-risk data surfaces on any device — short-lived, frequently sent over the network, and rarely audited. **UniClipboard was designed around a single premise:** > Convenience should never require surrendering control over your data. Everything in this document follows from that one rule. --- ## 2. Core Security Principles UniClipboard's encryption system is built on four non-negotiable principles: 1. **User-Controlled** Encryption is initiated and owned by the user. Keys are derived from a passphrase you pick — never generated server-side, never escrowed. 2. **End-to-End Encrypted** Data is encrypted before it leaves the device and decrypted only on devices that have the matching key material. The transport layer is treated as untrusted. 3. **Zero-Knowledge by Design** UniClipboard servers cannot read your clipboard content. This is a property of the architecture, not a privacy policy. 4. **Minimal Exposure** Plaintext exists only where strictly necessary, only for the shortest possible time, and is wiped from memory on drop. --- ## 3. High-Level Architecture UniClipboard is built around the concept of a **space**: a logical group of devices that trust each other and share an encrypted clipboard history. Each space has its own master key, and devices join a space by entering a short-lived invitation code together with the space passphrase. Once a space is created, the data flow is: ``` Clipboard Content → Local Encryption (Source Device) → P2P Direct Channel ──or── Encrypted Relay Fallback → Local Decryption (Target Device) ``` Key implications: * P2P direct connections are preferred, including across home/office networks via NAT hole-punching * Relay nodes and any intermediate infrastructure only ever see authenticated ciphertext * Network transport does not affect cryptographic guarantees — payload encryption is independent of the transport * Trust boundaries remain entirely on user devices --- ## 4. Cryptographic Primitives UniClipboard intentionally uses a small, well-studied set of modern primitives. | Purpose | Primitive | | ------------------------------------ | ------------------------------------------- | | Authenticated encryption (AEAD) | XChaCha20-Poly1305 | | Key derivation from passphrase | Argon2id (memory-hard, GPU/ASIC-resistant) | | AAD fingerprint / domain separation | BLAKE3 | | Encrypted local search index | HMAC over a search key derived from MasterKey | | Random material | OS CSPRNG (`OsRng`) | ### AEAD parameters * **Cipher**: XChaCha20-Poly1305 * **Key size**: 32 bytes (256-bit) * **Nonce size**: 24 bytes, generated fresh per record from the OS CSPRNG. The 192-bit nonce space makes accidental reuse a non-issue in practice. * **Authentication tag**: 16 bytes (Poly1305) * **AAD**: bound to the data's logical identity (see §5.2) ### Argon2id parameters * **Memory cost**: 128 MB * **Iterations**: 3 * **Parallelism**: 4 threads * **Output length**: 32 bytes These parameters are calibrated to stay snappy on a typical user device while making large-scale offline cracking economically unattractive. --- ## 5. Key Management Model ### 5.1 Layered Key Hierarchy UniClipboard avoids single-point compromise by separating user-facing secrets from data-encrypting secrets. ``` User Passphrase │ Argon2id (per-space salt, 128 MB · 3 iters · 4 threads) ▼ Key Encryption Key (KEK, 32 bytes) │ XChaCha20-Poly1305 (KeySlot wrapping) ▼ MasterKey (32 bytes, random) │ XChaCha20-Poly1305 (per-record AAD) ▼ Clipboard Data / Blob Storage ``` **Roles of each layer:** * **User Passphrase** — Never leaves the device. Never used directly to encrypt data. * **KEK** — Derived from the passphrase via Argon2id. Used only to unwrap the MasterKey. Stored in the OS keyring. * **MasterKey** — Random 32 bytes, generated locally. Encrypts every clipboard entry and blob in the space. Stored on disk only in *wrapped* form (a "KeySlot" file). * **Per-space isolation** — Every space has its own MasterKey. Switching to another space re-encrypts local history under the new MasterKey. ### 5.2 Per-Record Domain Separation (AAD) Every encrypted record is bound to its identity through Additional Authenticated Data (AAD). The AAD format is versioned and namespaced: ``` uc:inline:v1|| // for inline clipboard data uc:blob:v1| // for blob storage ``` This means a ciphertext that decrypts at all only decrypts in the right place. An attacker cannot: * Replay an old record into a different slot * Move a blob ciphertext under a different blob id * Splice records between events A 16-byte BLAKE3 fingerprint of the AAD is stored alongside the ciphertext to detect mismatch errors early. ### 5.3 Secure Local Storage Wrapped key material lives in two places: * **The OS keyring** stores the KEK using platform-native secure storage: * macOS — Keychain Services * Windows — Credential Manager * Linux — Secret Service (libsecret-compatible) * **The KeySlot file** on disk stores the MasterKey *wrapped* under the KEK. Disk access alone is insufficient to recover any plaintext. Sensitive in-memory values (passphrases, master keys, plaintext buffers) are held in dedicated secret types that: * Refuse to be cloned, serialized, logged, or printed * Display as `[REDACTED]` in `Debug` and `Display` * Zero their memory on drop --- ## 6. Clipboard Data Encryption Strategy ### 6.1 What is Encrypted, What Is Not UniClipboard distinguishes between three independent layers of encryption: * **App-layer (MasterKey)** — XChaCha20-Poly1305 under the space MasterKey. Protects against anyone who can read raw bytes off disk or off any intermediary that does not also hold the MasterKey. * **Transport (QUIC)** — Provided by iroh's QUIC stack with TLS 1.3-style AEAD, authenticated by each endpoint's Ed25519 device identity. Protects against passive eavesdroppers, active MITM, and relay nodes regardless of whether the app-layer encryption is on. * **Storage at rest** — Whether the disk copy itself is ciphertext. | Content | App-layer (MasterKey) | Transport (iroh QUIC) | At rest on disk | | ---------------------- | --------------------- | --------------------- | --------------------------- | | Text (inline) | Yes | Yes | Encrypted (per-record AEAD) | | Images (blob) | Yes | Yes | Encrypted (UCBL: zstd + AEAD) | | **File payload bytes** | **No** (by design) | **Yes** | **Plaintext (BLAKE3-addressed)** | | File metadata | Yes | Yes | Encrypted (with the clipboard event) | | Search index | Yes (HMAC tags) | n/a | No plaintext tokens (see §8) | | Key material | n/a | n/a | KEK in OS keyring; MasterKey wrapped in a KeySlot file | **Why file payloads are not application-layer encrypted.** This is a deliberate scope decision, not an oversight: 1. **Provenance** — File payloads are content the user already chose to copy. Their confidentiality is bounded by the user's intent at copy time. 2. **Metadata is what leaks.** The fields most likely to expose what a file is — its name, the directory it came from, its MIME type, and any preview thumbnail — are *not* in the file body. They are part of the clipboard event itself, and are encrypted under the space MasterKey through the same per-record AEAD as text. 3. **Performance.** Treating files as raw, content-addressed bytes lets large transfers use BLAKE3 outboard hashing, reflink-based imports on APFS / Btrfs / XFS, external-handle imports on Windows, and iroh-blobs' streaming download path. Wrapping every byte in an extra AEAD pass would erase those gains without adding meaningful confidentiality on top of what the transport already provides. **What this means in practice.** * On the wire — even for files — there is no point at which raw plaintext is exposed. The QUIC layer authenticates and encrypts every packet end-to-end between the two devices. Wi-Fi sniffers, ISPs, and the iroh relay see only QUIC ciphertext; the relay does not hold the keys to decrypt either the QUIC stream or the BlobTicket that addresses the transfer. * On disk, however — only on the user's own paired devices — file payloads land as plaintext in the content-addressed cache. Anyone with read access to that directory (or to a logged-in, unlocked desktop session) can recover the file bytes, exactly as if they had been copied to the file system. * The clipboard event referencing those files (filename, path, MIME, thumbnail, etc.) is still encrypted at rest, and is unreadable without unlocking the space. * For text and images, the bytes themselves are encrypted at rest under the space MasterKey, in addition to QUIC transport encryption on the wire. ### 6.2 Storage Layout at Rest * **Clipboard event database** — Encrypted SQLite store. Inline text and structured representation data are encrypted per record. * **Encrypted blob store (UCBL format)** — Used for image payloads and other application-managed blobs. Each blob is zstd-compressed, then encrypted with XChaCha20-Poly1305 under a per-blob AAD; the file header is `[UCBL magic | version | nonce]`. * **Content-addressed file cache** — Backed by iroh-blobs. File payloads are stored as raw bytes, addressed by the BLAKE3 hash of their plaintext. **This cache is not encrypted at the application layer** (see §6.1). * **Search index** — Inverted index keyed by HMAC term tags (see §8). No plaintext tokens. * **Key material** — KEK in the OS keyring; wrapped MasterKey in a KeySlot file on disk. --- ## 7. Sync Security Model UniClipboard's transport is built on QUIC-based P2P networking ([iroh](https://www.iroh.computer)). Two independent layers of encryption sit on top of each other: * **iroh QUIC (transport)** — Every connection — clipboard events, blob fetches, presence, pairing — runs over QUIC with TLS 1.3-style AEAD, authenticated by each endpoint's long-term Ed25519 identity. This protects all bytes on the wire, regardless of what they carry. Relays only forward already-encrypted QUIC datagrams; they hold no key material that would let them decrypt anything. * **MasterKey (application)** — On top of QUIC, clipboard events and image blobs are *additionally* encrypted with XChaCha20-Poly1305 under the space MasterKey, so that even an endpoint that participates in the iroh network without holding the MasterKey cannot read them. As described in §6.1, file payloads do not get this second layer; they rely solely on QUIC transport encryption while in flight. ### 7.1 Pairing & Device Identity * Each device generates a long-term key pair locally on first run. * Joining a space requires an invitation code (short-lived, valid for several minutes) plus the space passphrase. There is no email, account, or cloud signup. * Pairings are stored locally; revoking a device from any paired peer immediately stops including it in future syncs. ### 7.2 Local Network Sync * Devices on the same Wi-Fi connect directly without traversing any external infrastructure. * Payloads are encrypted under the space MasterKey before they reach the wire. * Packet capture yields only ciphertext. ### 7.3 Cross-Network Sync When devices cannot reach each other directly, UniClipboard performs NAT hole-punching to establish a P2P connection. If hole-punching fails: * The iroh relay forwards QUIC datagrams between peers. * The relay sees only QUIC ciphertext and connection metadata (peer IDs, timing). It does not hold the QUIC session keys, and a fortiori does not hold any space MasterKey. * The relay cannot derive keys, decrypt traffic, or modify content without detection — AEAD authentication tags at both the QUIC layer (always) and the MasterKey layer (text and images) catch tampering. * The relay is **self-hostable**: you can point UniClipboard at your own relay node and confirm it with a built-in connectivity test, so cross-network sync never has to touch infrastructure you do not control. * **LAN-only mode** disables the relay and every public-network path entirely — paired devices are then restricted to local-network discovery and direct connections, and nothing leaves your LAN. ### 7.4 Wire Format for Clipboard Events Clipboard events use a chunked, application-layer wire format that: * Splits the payload into bounded chunks (large events do not have to fit in memory) * Compresses each chunk with zstd before encryption * Authenticates each chunk under a per-chunk AAD `(transfer_id ‖ chunk_index)` so chunks cannot be reordered, dropped, or replayed * Carries a versioned header (`UC3\0`) so future format changes can be rolled out safely Large file payloads use a different, transport-native path: the sender adds the file to its iroh-blobs store and issues a `BlobTicket`; the ticket is delivered inside the encrypted clipboard event; the receiver fetches the blob over a QUIC stream tagged with the `BLOBS_ALPN` protocol. The QUIC stream is encrypted (§7.3); the blob bytes inside that stream are not additionally re-encrypted under the MasterKey (§6.1). ### 7.5 Resilience Connections recover automatically after Wi-Fi switches, sleep/wake, and brief disconnects, without requiring re-pairing. --- ## 8. Local Encrypted Search UniClipboard supports millisecond-level full-text search across tens of thousands of entries while keeping the index encrypted on disk. * **Search key derivation** — A dedicated search key is derived from the unlocked MasterKey, separating search from content encryption. * **Term tags** — Each token is replaced by `HMAC(search_key, normalized_token)` before being written to the inverted index. The disk never holds plaintext search terms. * **Lock-aware** — The daemon does not capture or index clipboard content while the session is locked, and search is unavailable until the user unlocks. Index rebuilds only run in the unlocked state. * **Normalization** — Stable, versioned rules (Unicode NFKC, lowercasing, whitespace collapsing, HTML stripping, URL/path segmentation). The index carries an `index_version` so future rule changes can trigger a safe rebuild. * **Tokenization** — Hybrid: word-level for Latin text, numbers, paths, URLs, file names; bigram for CJK. This matches the mixed nature of clipboard content (prose, shell commands, code, URLs, file paths). The search subsystem trades off only what is necessary: it does not try to hide local access patterns or local query frequency, since those are observable to anyone who already has access to the unlocked machine. --- ## 9. Local Daemon API The desktop GUI and `uniclip` CLI both talk to a local background daemon over HTTP and WebSocket. The daemon is hardened against local misuse: * **Loopback-only** — The daemon binds only to `127.0.0.1`; traffic never leaves the machine. * **Bearer-to-session exchange** — A bearer token stored in a `chmod 600` file is exchanged for a short-lived session JWT (5-minute TTL, signed with HS256 over a 32-byte secret). * **PID whitelist** — Each session is tied to the calling process's PID; mismatched callers are rejected. * **Rate limiting** — 100 requests per minute per client, sliding window. * **No persistent client storage** — Session tokens live only in memory; nothing sensitive is written to `localStorage`, `sessionStorage`, or cookies. * **Defense in depth** — Authentication runs before rate limiting, and dangerous endpoints (e.g. cache reset) require an explicit `confirmed: true` flag. These properties were validated as part of an internal phase-level security audit. --- ## 10. Threat Model ### 10.1 What UniClipboard Protects Against | Threat | Protected | | --------------------------------------------------- | --------- | | Network eavesdropping on the local Wi-Fi | Yes | | Eavesdropping on relay traffic | Yes | | Server / relay compromise | Yes | | Cloud or third-party storage compromise | Yes | | Active man-in-the-middle on the relay | Yes | | Disk theft of an inactive device | Yes | | Replaying or splicing records between slots | Yes | | Local non-privileged process talking to the daemon | Yes | ### 10.2 Explicit Non-Goals UniClipboard does not claim to defend against: * Fully compromised devices (root malware, key-loggers, hostile administrators) * User-leaked passphrases * Forensic recovery from a device while it is unlocked and the user is logged in * Side-channels visible to anyone with full local access (e.g. raw access patterns) * **Reading raw bytes out of the local file cache.** Per §6.1, file payloads are stored as content-addressed raw bytes; they are not encrypted at the application layer. Their associated metadata (filename, path, MIME, thumbnail) *is* encrypted as part of the clipboard event. Security is strongest when threat boundaries are stated honestly. We list our non-goals so users can make informed decisions. --- ## 11. User Control & Transparency Users can: * Enable or disable encryption initialization on first run, and rotate it later * Switch to a different space; existing local history is re-encrypted under the new space's MasterKey * Pause syncing instantly * Revoke a lost or stolen device from any other paired device — the space stops including it on the next sync * Opt out of anonymous telemetry at any time. Telemetry never carries clipboard content or personal data. The full source — including every cryptographic operation described here — is published on GitHub under AGPL-3.0. Trust the code, not the marketing. --- ## 12. Conclusion Encryption in UniClipboard is not an optional feature, a marketing checkbox, or a “Pro” upsell. It is the foundation of the product. We believe: * Your data belongs to you * Sync does not imply custody * Privacy should not be traded for convenience Every architectural decision in this document follows from those three sentences. --- > **Source**: https://www.uniclipboard.app/zh/blog/whitepaper > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-05 > **Last updated**: 2026-06-01 > **Description**: 技术白皮书：UniClipboard 的加密模型、密钥管理、点对点传输，以及设计能守住的边界和守不住的部分。 # 加密与隐私白皮书 **UniClipboard 如何让剪贴板始终是你的：加密、传输、以及设计能守住和守不住的边界。** ## 1. 为什么剪贴板数据必须加密 剪贴板内容的敏感程度被严重低估。在一个普通的工作日里，它会承载： * 密码、一次性验证码、API token、助记词 * 私钥、签名材料、配置片段 * 内部文档、未发布稿件、私下沟通的草稿 * 跨设备复制的文件 大多数剪贴板工具把这些数据当作"短暂的、无关紧要的"。但事实上，剪贴板是任何设备上风险最高的数据面之一——存在时间短、频繁通过网络传输、几乎不被审计。 **UniClipboard 围绕一个原则构建：** > 便利不应当以放弃数据的控制权为代价。 本白皮书描述的所有设计，都直接来自这一条原则。 --- ## 2. 核心安全原则 UniClipboard 的加密体系建立在四条不可妥协的原则之上： 1. **由用户掌控** 加密由用户发起、由用户拥有。密钥从用户口令派生，永远不会由服务端代为生成或托管。 2. **端到端加密** 数据在离开设备前完成加密，只在持有匹配密钥的设备上解密。传输层被视为不可信。 3. **架构层面的零知识** UniClipboard 的服务端无法读取你的剪贴板内容——这是架构上的事实，不是隐私策略上的承诺。 4. **最小暴露面** 明文只在严格必要的位置出现，停留时间尽可能短，并在内存释放时清零。 --- ## 3. 总体架构 UniClipboard 围绕**空间（space）**这个概念展开：一组互相信任、共享一段加密剪贴板历史的设备。每个空间拥有独立的主密钥；新设备通过短期有效的邀请码 + 空间口令加入。 空间建立后，数据流如下： ``` 剪贴板内容 → 本地加密（源设备） → P2P 直连通道 ──或── 加密中继回退 → 本地解密（目标设备） ``` 由此带来的几个直接结论： * 优先使用 P2P 直连，跨家庭/办公室网络也通过 NAT 打洞实现 * 中继节点和任何中间设施只看得到经过认证的密文 * 网络传输路径不会改变密码学保证——载荷加密与传输独立 * 信任边界完全位于用户的设备上 --- ## 4. 密码学原语 UniClipboard 刻意只采用一组小而成熟的现代原语。 | 用途 | 原语 | | -------------------------- | ------------------------------------------------- | | 认证加密（AEAD） | XChaCha20-Poly1305 | | 从口令派生密钥 | Argon2id（memory-hard，抗 GPU/ASIC） | | AAD 指纹 / 域分离 | BLAKE3 | | 本地加密搜索索引 | 基于 MasterKey 派生的搜索密钥上的 HMAC | | 随机数 | 操作系统级 CSPRNG（`OsRng`） | ### AEAD 参数 * **算法**：XChaCha20-Poly1305 * **密钥长度**：32 字节（256 位） * **nonce 长度**：24 字节，每条记录由 OS CSPRNG 重新生成。192 位的 nonce 空间使得碰撞在工程意义上完全不必担心。 * **认证标签**：16 字节（Poly1305） * **AAD**：与数据的逻辑身份绑定（见 §5.2） ### Argon2id 参数 * **内存成本**：128 MB * **迭代次数**：3 * **并行度**：4 线程 * **输出长度**：32 字节 这组参数在普通用户设备上仍能维持流畅体验，同时让大规模离线爆破在经济上变得不划算。 --- ## 5. 密钥管理模型 ### 5.1 分层密钥结构 UniClipboard 通过把"用户秘密"和"加密数据用的秘密"分离开，避免单点泄露。 ``` 用户口令（Passphrase） │ Argon2id（每空间独立 salt，128 MB · 3 iter · 4 threads） ▼ 密钥加密密钥（KEK，32 字节） │ XChaCha20-Poly1305（KeySlot 包装） ▼ 主密钥（MasterKey，32 字节，随机生成） │ XChaCha20-Poly1305（每条记录绑定 AAD） ▼ 剪贴板内容 / Blob 存储 ``` **各层的职责：** * **用户口令** —— 永不离开设备，也永不直接用于加密数据。 * **KEK** —— 由口令通过 Argon2id 派生，仅用于解包 MasterKey。存放在系统 keyring 中。 * **MasterKey** —— 本地随机生成的 32 字节密钥，用于加密该空间内所有的剪贴板条目和 blob。磁盘上只以**已包装**的形式（KeySlot 文件）存在。 * **每空间隔离** —— 每个空间持有独立的 MasterKey；切换到另一个空间时，本地历史会在新 MasterKey 下重新加密。 ### 5.2 每条记录的域分离（AAD） 每条加密记录都通过 Additional Authenticated Data（AAD）绑定到自己的身份。AAD 格式带有命名空间和版本号： ``` uc:inline:v1|| // 内联剪贴板数据 uc:blob:v1| // blob 存储 ``` 这意味着一段密文要么在原本属于它的位置上解密成功，要么完全不能解密。攻击者无法： * 把旧记录重放到另一个槽位 * 把一段 blob 密文挪到另一个 blob id 下 * 在事件之间拼接记录 存储侧还会保留一段 16 字节的 BLAKE3 AAD 指纹，用于尽早发现身份不匹配的错误。 ### 5.3 安全本地存储 被包装后的密钥材料分两处存放： * **系统 keyring** 保存 KEK，使用平台原生的安全存储： * macOS —— Keychain * Windows —— Credential Manager * Linux —— Secret Service（兼容 libsecret） * **KeySlot 文件** 在磁盘上保存被 KEK 包装后的 MasterKey。仅有磁盘访问权限不足以恢复任何明文。 进程内的敏感值（口令、主密钥、明文缓冲区）都装在专用的"秘密容器"类型里： * 不能被 clone、序列化、打印或写入日志 * `Debug` 与 `Display` 输出固定为 `[REDACTED]` * drop 时自动将内存清零 --- ## 6. 剪贴板数据加密策略 ### 6.1 哪些会被加密、哪些不会 UniClipboard 把加密区分成三个相互独立的层次： * **应用层（基于 MasterKey）** —— 在空间 MasterKey 之下的 XChaCha20-Poly1305。防的是"任何能从磁盘读到原始字节、或经手数据但又不持有 MasterKey 的角色"。 * **传输层（QUIC）** —— 由 iroh 的 QUIC 栈提供，TLS 1.3 风格的 AEAD，由两端各自的长期 Ed25519 设备身份认证。无论里面装什么，线路上的字节都受这层保护。中继也包含在内。 * **静态存储** —— 落到磁盘的那一份是不是密文。 | 内容 | 应用层（MasterKey） | 传输层（iroh QUIC） | 落盘形式 | | --------------------- | --------------------- | ------------------- | ------------------------------------- | | 文本（inline） | 加密 | 加密 | 密文（每条 AEAD） | | 图片（blob） | 加密 | 加密 | 密文（UCBL：zstd + AEAD） | | **文件载荷字节** | **不加密（策略性决定）** | **加密** | **明文（按 BLAKE3 寻址）** | | 文件元数据 | 加密 | 加密 | 密文（与剪贴板事件一同加密） | | 搜索索引 | 加密（HMAC 标签） | 不适用 | 无明文 token（详见 §8） | | 密钥材料 | 不适用 | 不适用 | KEK 在系统 keyring；MasterKey 在 KeySlot 文件中以包装态保存 | **为什么文件载荷不在应用层加密。** 这是一项有意为之的范围决定，不是疏忽： 1. **来源**——文件载荷是用户主动复制的内容，其机密性由用户在复制时的意图决定。 2. **真正会泄露身份的是元数据。** 最可能暴露"这是什么文件"的字段——文件名、所在目录、MIME 类型、预览缩略图——并不在文件本体里，而是剪贴板事件本身的一部分；它们和文本一样、在同一空间 MasterKey 之下被加密。 3. **性能。** 把文件视为原始的、内容寻址的字节，可以让大文件传输走 BLAKE3 outboard、APFS / Btrfs / XFS 上的 reflink、Windows 上的外部句柄导入、以及 iroh-blobs 的流式下载路径。再套一层 AEAD 会把这些收益抹平，而对机密性几乎没有额外提升（传输层本身已经有保护）。 **实际含义。** * 在线路上——即便是文件——任何时候都不会暴露原始明文。QUIC 层会对每个 packet 在两端之间做端到端的认证与加密。Wi-Fi 嗅探者、ISP、iroh 中继看到的都只是 QUIC 密文；中继既不持有 QUIC 会话密钥，也不持有任何空间 MasterKey，无法解开 BlobTicket 所指向的内容。 * 在磁盘上——只有用户自己已配对的设备上——文件载荷会以明文落到内容寻址的本地缓存中。任何能读到该目录的人，或者能进入已登录、已解锁桌面会话的人，都可以恢复出文件字节，本质上跟把文件复制到文件系统是一样的。 * 引用这些文件的剪贴板事件（文件名、路径、MIME、缩略图等）仍然以加密形式落盘，不解锁空间就读不出来。 * 对文本和图片来说，字节本身在空间 MasterKey 之下加密落盘，且在线路上叠加 QUIC 传输层加密。 ### 6.2 静态存储布局 * **剪贴板事件数据库** —— 加密 SQLite 存储；内联文本与结构化 representation 数据按记录加密。 * **加密 blob 存储（UCBL 格式）** —— 用于图片载荷及其它应用层管理的 blob。每个 blob 先经 zstd 压缩，再用 XChaCha20-Poly1305 在 per-blob AAD 下加密；文件头为 `[UCBL magic | version | nonce]`。 * **内容寻址的文件缓存** —— 由 iroh-blobs 提供。文件载荷以原始字节存放，按 plaintext 的 BLAKE3 哈希寻址。**该缓存不在应用层加密**（见 §6.1）。 * **搜索索引** —— 以 HMAC term 标签为键的倒排索引（见 §8），不含明文 token。 * **密钥材料** —— KEK 存于系统 keyring；包装后的 MasterKey 写入磁盘上的 KeySlot 文件。 --- ## 7. 同步安全模型 UniClipboard 的传输基于 QUIC P2P 网络（[iroh](https://www.iroh.computer)）。在它之上叠加了两层互相独立的加密： * **iroh QUIC（传输层）** —— 所有连接（剪贴板事件、blob 拉取、在线状态、配对）都跑在 QUIC 之上，使用 TLS 1.3 风格的 AEAD，由两端各自的长期 Ed25519 身份认证。无论里面装什么，线路上的所有字节都受这层保护。中继只转发已经加密的 QUIC 数据报，不持有任何能解密的密钥材料。 * **MasterKey（应用层）** —— 在 QUIC 之上，剪贴板事件与图片 blob 还会**额外**用 XChaCha20-Poly1305 在空间 MasterKey 下再加密一遍，这样即便一台已经接入 iroh 网络但不持有 MasterKey 的端点，也读不出内容。如 §6.1 所述，文件载荷不享有这第二层保护——在传输中只依赖 QUIC 端到端加密。 ### 7.1 配对与设备身份 * 每台设备首次启动时在本地生成长期的密钥对。 * 加入空间需要邀请码（短期有效，几分钟内过期）+ 空间口令。没有邮箱、没有账号、没有云端注册。 * 配对信息保存在本地；从任意一台已配对设备上撤销某台设备后，下次同步立刻不再包含它。 ### 7.2 局域网同步 * 同一 Wi-Fi 下的设备直接互联，不经过任何外部基础设施。 * 载荷在到达网线之前就已用空间 MasterKey 加密。 * 抓包只能拿到密文。 ### 7.3 跨网络同步 当两台设备无法直连时，UniClipboard 通过 NAT 打洞建立 P2P 连接。如果打洞失败： * iroh 中继在双方之间转发 QUIC 数据报。 * 中继只看得到 QUIC 密文以及连接元数据（peer ID、时间戳）。它既不持有 QUIC 会话密钥，也无从持有空间 MasterKey。 * 中继无法派生密钥、无法解密、也无法在不被发现的情况下篡改内容——QUIC 层（始终）和 MasterKey 层（文本与图片）的 AEAD 认证标签都会捕获篡改。 * 中继是**可自建的**：你可以让 UniClipboard 指向自己的中继节点，并用内置的连通性测试确认配置可用——跨网络同步因此无需经过任何你不掌控的基础设施。 * **仅局域网（LAN-only）模式**会彻底关闭中继和所有公网路径——已配对设备此时只走局域网发现与直连，任何数据都不会离开你的局域网。 ### 7.4 剪贴板事件的 wire format 剪贴板事件使用分块的应用层 wire format： * 把载荷切分为有界的 chunk（大事件不必整个装入内存） * 每个 chunk 在加密前用 zstd 压缩 * 每个 chunk 在 `(transfer_id ‖ chunk_index)` 的 AAD 下被认证，因此 chunk 不能被乱序、丢弃或重放 * 头部带有版本号（`UC3\0`），以便未来格式升级可以平滑过渡 大型文件载荷走的是另一条传输层原生路径：发送端把文件加入自己的 iroh-blobs 存储并签发一张 `BlobTicket`；ticket 通过加密的剪贴板事件发给接收端；接收端在带 `BLOBS_ALPN` 协议标识的 QUIC 流上拉取 blob。该 QUIC 流本身被加密（见 §7.3），但流内的 blob 字节不会再被 MasterKey 二次加密（见 §6.1）。 ### 7.5 韧性 切换 Wi-Fi、休眠唤醒、短暂断网后，连接会自动恢复，无需重新配对。 --- ## 8. 本地加密搜索 UniClipboard 在历史规模达到数万条时仍能在毫秒级完成全文搜索，并保持索引在磁盘上加密。 * **搜索密钥派生** —— 解锁后，从 MasterKey 派生出专用的搜索密钥，与内容加密用的密钥分离。 * **Term 标签** —— 每个 token 在写入倒排索引前会被替换为 `HMAC(search_key, normalized_token)`。磁盘上不会出现明文搜索词。 * **会话锁感知** —— daemon 在锁定状态下不会捕获或索引新的剪贴板内容；解锁之前搜索功能不可用。索引重建只发生在解锁状态下。 * **规范化** —— 稳定且带版本的规则（Unicode NFKC、转小写、合并空白、剥离 HTML 标签、URL 与路径切分）。索引中保存 `index_version`，以便未来规则变化能触发安全的重建。 * **分词** —— 混合策略：拉丁文字、数字、路径段、URL 片段、文件名采用词级切分；中文使用 bigram。这与剪贴板内容常见的混合形态（自然语言、shell 命令、代码、URL、文件路径、中英混排）相匹配。 搜索子系统只做必要的取舍：它不试图隐藏本地访问模式或本地查询频率——这些信息对已经能访问到解锁机器的人来说本就是可观察的。 --- ## 9. 本地 Daemon API 桌面 GUI 和 `uniclip` 命令行都通过 HTTP + WebSocket 与本地后台 daemon 通信。daemon 经过专门加固以抵御本地误用： * **仅 loopback** —— daemon 仅监听 `127.0.0.1`，流量永远不离开本机。 * **Bearer → Session 交换** —— 一个保存在 `chmod 600` 文件中的 bearer token 用于换取短期会话 JWT（5 分钟有效，HS256 签名，密钥 32 字节）。 * **PID 白名单** —— 每个会话与调用方进程的 PID 绑定；PID 不匹配会被拒绝。 * **限流** —— 每客户端每分钟 100 次，滑动窗口。 * **不在客户端持久化** —— 会话 token 仅存在于内存中；不会写入 `localStorage`、`sessionStorage` 或 cookie。 * **纵深防御** —— 鉴权先于限流执行；危险端点（如清空缓存）必须显式带上 `confirmed: true`。 以上属性已在内部 phase 级别的安全审计中得到验证。 --- ## 10. 威胁模型 ### 10.1 UniClipboard 抵御的威胁 | 威胁 | 是否抵御 | | ------------------------------------------ | -------- | | 局域网的 Wi-Fi 嗅探 | 是 | | 中继链路上的窃听 | 是 | | 服务端 / 中继节点被攻陷 | 是 | | 云端或第三方存储被攻陷 | 是 | | 中继上的主动 MITM | 是 | | 失窃设备的磁盘被读取（非活跃状态） | 是 | | 在不同槽位之间重放或拼接记录 | 是 | | 本地非特权进程访问 daemon | 是 | ### 10.2 明确的非目标 UniClipboard 不声称能够抵御以下场景： * 设备已被完全攻陷（root 级恶意软件、键盘记录、有恶意权限的管理员） * 用户主动泄露口令 * 在用户已登录、设备已解锁的情况下被取证 * 拥有完整本地权限的人能观察到的旁路（例如原始访问模式） * **直接读取本地文件缓存中的文件原始字节。** 见 §6.1：文件载荷以内容寻址的原始字节形式落盘，不在应用层加密；与之相关的元数据（文件名、路径、MIME、缩略图）仍作为剪贴板事件的一部分被加密。 只有把威胁边界讲清楚，安全声明才有意义。我们把非目标也列出来，是为了让用户能够做出明智的判断。 --- ## 11. 用户控制与可验证性 用户可以： * 在首次启动时启用或不启用加密初始化，并在之后轮换 * 切换到另一个空间；本地历史会在新空间的 MasterKey 下重新加密 * 立即暂停同步 * 在任意一台已配对设备上撤销丢失或被盗的设备——下次同步起空间不再包含它 * 随时关闭匿名遥测。遥测从不携带剪贴板内容或个人数据。 完整源代码——包括本文描述的每一项密码学操作——已在 GitHub 以 AGPL-3.0 协议开源。请相信代码本身，而不是市场宣传。 --- ## 12. 结语 UniClipboard 中的加密不是一个可选功能、不是一项市场宣传项、也不是收费版的卖点。 它是产品的地基。 我们的信念是： * 你的数据属于你 * 同步不等于托管 * 隐私不应当用便利来交换 本文中的每一项架构决策，都直接来自这三句话。 --- > **Source**: https://www.uniclipboard.app/blog/why-iroh-not-libp2p-webrtc > **Locale**: English > **Category**: Blog > **Published**: 2026-05-05 > **Last updated**: 2026-05-06 > **Description**: Why we picked iroh over libp2p, WebRTC, syncthing's BEP, magic-wormhole, and Tailscale for UniClipboard's P2P layer — with the tradeoffs that matter for a small desktop app. # Why iroh, not libp2p or WebRTC: Building a P2P clipboard **A year of building a serverless, cross-device clipboard came down to one interesting decision: which P2P stack. Here's the long version of that answer.** I’ve been building UniClipboard for about a year now. It’s a clipboard sync app for macOS, Windows, and Linux. The boring part turned out to be most of the work. Clipboard APIs are weird in different ways on every OS. Images are annoying. Files are more annoying. Packaging a Tauri app for three platforms is its own little punishment. But one part was actually interesting: picking the P2P layer. I wanted UniClipboard to work without an account and without a central server holding clipboard data. Pair two devices, copy something on one, paste it on the other. Ideally before you even think about it. That sounds simple until you remember home routers exist. So I tried a few options: libp2p, WebRTC, Syncthing’s protocol, magic-wormhole, and eventually iroh. This is why I ended up with iroh. ## What the network layer had to do For UniClipboard, I did not need a global peer network. There is no “clipboard swarm”. No public discovery. No DHT. No content-addressed storage. Most users have two to five devices: - a MacBook - maybe a Windows desktop - maybe a Linux box somewhere - maybe another laptop later Those devices are paired explicitly. After that they need to keep talking. The network layer had to handle a few things: - small messages, most of the time - occasional images or files - long-lived connections between known devices - NAT traversal that works in normal ugly networks - a relay fallback when direct connection fails - no browser requirement The latency target is also different from file sync. Clipboard sync feels broken if it takes a few seconds. If I copy a command on one machine and move my hand to paste it on another, the entry should already be there. Not “eventually consistent”. Just there. ## libp2p was the obvious first try I started with libp2p because, well, it’s libp2p. It is mature. It has a Rust implementation. It powers IPFS and a lot of other real systems. If you search “Rust P2P”, it is probably one of the first things you find. And it works. The problem is that it works like a framework for building a protocol stack. I needed something closer to “dial this peer and give me a connection”. With libp2p I had to think about transports, secure channels, multiplexing, peer identity, identify protocol, relay client, hole punching, swarm behavior, DHT choices, and a bunch of version/configuration details before I could send the first real application message. That is not libp2p being bad. That is libp2p being what it is. For a bigger peer network, or a protocol where you actually need that flexibility, it makes sense. For a clipboard app, it felt like building a small operating system before I could copy “hello”. I had a prototype after a couple of weeks. It mostly worked. But “mostly” is the dangerous word here. NAT edge cases were hard to reason about, and when something failed, I was not always sure which layer was the problem. That was the point where I started looking for something smaller. ## WebRTC felt wrong pretty quickly WebRTC is great if one side is a browser, or if you are doing audio/video. UniClipboard is not that. I do not need media tracks. I do not need browser support. I do not want to drag a giant WebRTC stack into a desktop app just to send clipboard entries. The other issue is signaling. WebRTC gives you a lot, but peers still need to find each other somehow. So now I would have to run signaling infrastructure anyway, or build my own pairing/signaling story around it. And if I need relay fallback, TURN can do it, but then I’m paying bandwidth and operating another service-shaped thing. Could it be made to work? Sure. Would I enjoy maintaining it for a desktop clipboard app? No. ## Syncthing is great, but it syncs folders I also looked at Syncthing’s BEP protocol because Syncthing is honestly impressive. It already does encrypted sync between known devices. It has a relay network. It has years of real-world NAT pain baked into it. But Syncthing syncs folder state. That sounds obvious, but it matters. Its loop is basically: 1. file changes 2. filesystem watcher fires 3. Syncthing scans 4. hashes blocks 5. sends index updates 6. peers request blocks 7. blocks transfer That is a good shape for “keep this music folder synced”. It is a bad shape for “I copied a token and want it on the other machine now”. I could have stuffed every clipboard entry into a temp file and waited for it to sync. That would probably work in a demo. It would also be cursed. And the first time latency felt bad, I’d be debugging around a protocol that was never trying to solve this problem. So I dropped that path. ## magic-wormhole is beautiful, but too one-shot I like magic-wormhole a lot. The human-readable codes are great. The PAKE design is nice. The “no account, send something to another device” experience is very close to the kind of thing I like. But magic-wormhole is a one-shot transfer tool. You create a code, the other side enters it, something gets transferred, and then the session is done. UniClipboard needs paired devices that keep a relationship. They reconnect tomorrow. They send tiny messages all day. They survive network changes. They need a channel, not a one-time handoff. You could use magic-wormhole for pairing, derive keys, then build a long-lived encrypted transport somewhere else. But then I’m building the transport anyway. ## iroh was the first one that felt like the right shape iroh gave me the API shape I wanted. Not a pile of protocol components. More like: ```rust let endpoint = Endpoint::builder() .secret_key(secret_key) .alpns(vec![ALPN.to_vec()]) .discovery_n0() .bind() .await?; let conn = endpoint.connect(peer_node_addr, ALPN).await?; let (mut send, mut recv) = conn.open_bi().await?; ``` That is much closer to the mental model I wanted: > I have a peer. I know its address/key. Give me a connection. Under the hood, iroh uses QUIC through Quinn. NAT traversal is handled inside iroh-net. Relay fallback is part of the model. Direct connection upgrade is automatic when it works. From the app side, I do not need to care whether the first packets went through a relay and then upgraded to direct. I still have a connection. That matters a lot for a small app. The P2P part of UniClipboard ended up being roughly a few hundred lines of Rust: endpoint setup, ALPN, connection lifecycle, message framing, some peer discovery glue. The libp2p version was much larger and still felt less boring. And boring is exactly what I want from this layer. ## The relay question A relay is still infrastructure. There is no magic here. If direct P2P fails, traffic needs to go somewhere. With iroh, it can fall back to relay. The relay sees peer IDs and encrypted bytes. It does not see clipboard contents. That distinction matters, especially for a clipboard app. Sometimes the clipboard is just a URL. Sometimes it is a password, an API key, or half a config file you definitely did not want sitting in some random service forever. So I care a lot about what the relay can see. Right now, iroh’s default relay/discovery infra makes the app much easier to use. Users do not have to host anything. They pair devices and it works. But there is a tradeoff: if you are strict about self-hosting every piece of infrastructure, hosted relay fallback is still hosted relay fallback. Even if it only sees ciphertext. That is one of the reasons UniClipboard has LAN-only mode, and why a self-hosted relay story matters. ## What about Tailscale? I use Tailscale. It is excellent. But I did not want UniClipboard to require it. If UniClipboard required Tailscale, then every user would need: - a Tailscale account - every device in the same tailnet - Tailscale’s control plane as part of the trust/setup story For some users, that is totally fine. If you already live inside Tailscale, you could probably build 80% of a clipboard sync setup with a small daemon and some private networking. But that is not the product I wanted. I wanted “install on two machines, pair them, done”. No account. No tailnet. No “first go set up another thing”. Which is not always easy, but it is the point. ## The risk with iroh iroh is younger than libp2p. That is the main downside. Smaller ecosystem. More API churn. I have already had to do a couple of 0.x migrations that were not just search-and-replace. So the bet is not “iroh will never change”. It will. The bet is that the part I depend on is small: - Endpoint - Connection - SecretKey - NodeAddr - QUIC streams - relay fallback If those primitives stay sane, I can absorb some churn around them. And if iroh disappeared tomorrow, the underlying pieces are not exotic. QUIC, STUN-ish discovery, DERP-style relay. Rebuilding the exact SDK shape on top of Quinn would be annoying, but bounded. Maybe a few weeks. Not fun, but not existential. For me, that risk was worth it. I would rather spend those weeks later if I have to, instead of spending every week now maintaining a networking stack I barely need. ## How I’d choose today If I were picking again in 2026, I’d roughly think about it like this: Use iroh if you are building a desktop app and want a small set of known devices to talk to each other. Use libp2p if you are actually building a protocol or a large peer network, and you need the flexibility. Use WebRTC if browsers or media are central to the product. Use Syncthing if the thing you want is folder sync. It is very good at that. Clipboard sync is not folder sync. Use magic-wormhole for one-shot transfers or pairing flows. Use Tailscale if your users already live in Tailscale and you are okay making that a requirement. For UniClipboard, iroh still feels like the right tradeoff. Small payloads. Known devices. Desktop only. P2P when possible. Relay fallback when needed. No account. That is the shape of the problem, and iroh fits it better than the other options I tried. ## About UniClipboard UniClipboard is an open-source clipboard sync app for macOS, Windows, and Linux. It syncs text, images, and files. Devices pair without an account. They try direct P2P first, and fall back to encrypted relay traffic when that does not work. The relay cannot read clipboard contents. Repo: https://github.com/uniclipboard/uniclipboard Site: https://uniclipboard.app If you disagree with the networking choice, I’d actually like to hear why. --- > **Source**: https://www.uniclipboard.app/zh/blog/why-iroh-not-libp2p-webrtc > **Locale**: Simplified Chinese > **Category**: Blog > **Published**: 2026-05-05 > **Last updated**: 2026-05-06 > **Description**: 我们为什么在 UniClipboard 的 P2P 层上选择 iroh,而不是 libp2p、WebRTC、syncthing BEP、magic-wormhole 或 Tailscale —— 一个小型桌面应用真正在乎的取舍。 # 为什么选 iroh,而不是 libp2p 或 WebRTC:构建一个 P2P 剪贴板 **做一个无服务器跨设备剪贴板一整年,最有意思的决定就一个:P2P 栈选谁。这是那个问题的长版回答。** 过去一年我一直在做 [UniClipboard](https://github.com/uniclipboard/uniclipboard) —— 一个不依赖服务器的跨平台剪贴板同步工具。大部分工作其实都很无聊:操作系统之间剪贴板 API 的差异、加密人体工学的各种坑、Tauri 应用打包到三个平台的痛苦。 但有一个决定确实有意思,而且总是被人问到:为什么 P2P 层选了 [iroh](https://iroh.computer), 而不是看起来更显然的 [libp2p](https://libp2p.io)、WebRTC、syncthing 的 BEP,或者 magic-wormhole? 这篇文章是那个回答的长版本。如果你也在做需要两台终端设备直接对话——跨越互联网、 穿过 NAT、还不想自己跑基础设施——的事情,这里的取舍大概率也适用于你的项目。 ## 问题的形状 一个剪贴板同步工具对网络层有四个要求: 1. **长连接、已认证的通道**,在一小撮已知设备之间(通常是同一个人名下的 2–5 台), 并且能挺过网络切换。 2. **小载荷的低延迟**。绝大多数剪贴板内容小于 1 KB。所谓"好"的体验,意味着新条目 要在用户手还没移开之前就出现在另一台设备上——大概 200ms 的端到端预算。 3. **偶发的较大载荷**——图片(几 MB)和偶尔的文件(~100 MB)。 4. **NAT 穿透**要在消费级 ISP、强制门户登录、运营商级 NAT、企业代理这种乱糟糟的现实里 都能用,fallback 还不能让我(开发者)自己跑一套随用户量线性扩张的基础设施。 我**不**需要的: - DHT 或内容寻址存储。这里没有"剪贴板网络"可发现——设备是显式配对的。 - Pubsub。fan-out 是个位数。 - 浏览器支持。UniClipboard 是桌面应用。 最后一条悄悄判了 WebRTC 死刑,这个稍后再说。 ## 候选 1:libp2p 最显然的选择。libp2p 成熟、有 Rust 实现([rust-libp2p](https://github.com/libp2p/rust-libp2p))、 驱动着 IPFS 和加密生态的一大块,而且明确把自己定位成"P2P 工具箱"。 我先用 libp2p 做了原型。能跑。但 libp2p 的*形状*对一个小应用而言是错的: ```rust // 一个 libp2p hello-world 大致长这样 let local_key = identity::Keypair::generate_ed25519(); let local_peer_id = PeerId::from(local_key.public()); let transport = tcp::tokio::Transport::default() .upgrade(Version::V1) .authenticate(noise::Config::new(&local_key)?) .multiplex(yamux::Config::default()) .boxed(); let behaviour = MyBehaviour { kademlia: kad::Behaviour::new(local_peer_id, MemoryStore::new(local_peer_id)), identify: identify::Behaviour::new(...), ping: ping::Behaviour::new(...), relay_client: relay::client::Behaviour::new(local_peer_id, relay_client_transport), dcutr: dcutr::Behaviour::new(local_peer_id), }; let mut swarm = SwarmBuilder::with_existing_identity(local_key) .with_tokio() .with_other_transport(|key| ...) .with_behaviour(|_| behaviour)? .build(); // ……到这里,你才终于可以开始写应用代码 ``` 这正是 libp2p 设计的样子——让你自由组装一个传输层、一个安全通道、一个多路复用器、 一个 peer 识别协议、一个用于路由的 DHT、一个用于 NAT 穿透的 relay client、一个 hole-punching behaviour。可组合性是它的卖点。 但对一个剪贴板应用而言,我是在发出第一个字节之前先组装并配置一个小型操作系统。 每一块都有自己的版本兼容性、自己的 bug、自己的配置旋钮。上面八个模块里,有三个跟 NAT hole-punching 之间有非显然的相互作用。两周后我有一个大体能跑的 libp2p 原型, 后面跟着一长串我没法自信调试的边角 case。 根本性的错配是:**libp2p 是一个用来构建协议的框架。我需要的是一个使用某个协议的 SDK。** ## 候选 2:WebRTC WebRTC 是浏览器 P2P 的显然选择,而且也有完全实打实的桌面实现 ([webrtc-rs](https://github.com/webrtc-rs/webrtc)、对 [libwebrtc](https://webrtc.googlesource.com/src/) 的绑定)。 排除它的理由: 1. **栈太重**。webrtc-rs 大概 50 个 crate 的依赖,大量是为我永远用不到的多媒体管线服务的。 libwebrtc 的绑定更糟——不管你要不要,它都会拉进来 Chromium 衍生的音视频处理。 2. **Signaling 是你自己的事**。WebRTC 出名地把 DTLS+SRTP 和线协议给你,但两个 peer 怎么找到彼此是留给你的练习。结果你还是得跑一套 signaling 基础设施,这就把意义砍掉一半。 3. **NAT 穿透止步于标准层**。STUN 经常能用,TURN 总是能用但带宽贵。没有像 iroh 的 home-relay 系统那样把两者透明地揉在一起的等价物。 WebRTC 是"浏览器之间视频聊天"的对的工具,是"两个想要长连接加密通道的桌面应用"的错的工具。 ## 候选 3:syncthing 的 BEP 协议 [Syncthing](https://syncthing.net) 实际上做了我需要的大部分事情——已知设备之间的加密 P2P 同步、通过他们的 relay 网络做 NAT 穿透、成熟的代码库。我真花了一个周末试着把 syncthing 当后端用。 它在一个具体且发人深省的方向上,形状不对。 Syncthing 优化的是**文件夹状态的最终一致性**。最小循环大概是这样: 1. 文件在磁盘上变更 2. Inotify/FSEvent 触发 3. Syncthing 扫描、计算 block 哈希 4. 索引更新传播给 peers 5. Peers 请求变化的 block 6. Block 传输 这是"让两个音乐库保持同步"的好架构,是"我刚复制了一段字符串,我希望在我切窗口之前 它已经到了另一台笔记本上"的烂架构。即便把 `fsScanIntervalS` 调到很低,这个 round-trip 还是好几秒。 而且,BEP 是一个文件夹同步协议——没有"对一个 peer 开一条全双工通道"的库版本,只有 "把这个文件夹和那个 peer 同步"。把它改造来传短消息,意味着把每个剪贴板条目塞进一个 临时文件再等同步。当 hackathon 凑合可以,当地基就糟糕了。 ## 候选 4:magic-wormhole [magic-wormhole](https://github.com/magic-wormhole/magic-wormhole.rs) 概念上很美: 人类可发音的码(`7-crossover-clockwork`)、基于 PAKE 的认证密钥协商、不要账号、 用户也不需要去想任何基础设施。我很喜欢它。 但它是一个**一次性**协议。你生成一个码,对面输入,内容传完,通道关闭。它没有 "这两台设备有持续关系并希望无限期来回收发消息"的概念。 能不能在 magic-wormhole 之上构建那种东西?能——从一次 wormhole 交换里推导出一个长期共享密钥, 用它在……什么之上 bootstrap 一个 Noise 通道。但到那一步,你已经在重新造 iroh 已经提供的那一层, 只不过造在一个不是为这个用途设计的原语之上。 ## iroh 做对了什么 [iroh](https://iroh.computer) 是 [Number Zero](https://www.n0.computer)(里面有早期 IPFS 的一些人)做的,目标明确就是**一个用于 P2P 的 Rust SDK,而不是框架**。光从 API 的形状你就 能看出它的哲学: ```rust use iroh::{Endpoint, SecretKey}; const ALPN: &[u8] = b"uniclipboard/0"; // 绑定一个 P2P endpoint let endpoint = Endpoint::builder() .secret_key(secret_key) .alpns(vec![ALPN.to_vec()]) .discovery_n0() // 可选:用 n0 的发现服务 .bind() .await?; // 连一个 peer(跨互联网,NAT 穿透在内部已经处理好) let conn = endpoint.connect(peer_node_addr, ALPN).await?; let (mut send, mut recv) = conn.open_bi().await?; send.write_all(b"hello from device A").await?; send.finish()?; let response = recv.read_to_end(1024).await?; ``` 整套搭建就这些。背后: - 传输层是 **QUIC**(经由 [Quinn](https://github.com/quinn-rs/quinn))——建立连接比 TCP+TLS 更快,多路复用是内建的,网络切换(Wi-Fi → 蜂窝)时连接迁移也开箱即用。 - **NAT hole-punching** 内建在 `iroh-net` 里,组合了 STUN 类的反射地址发现和一个 DERP 风格的 relay 系统作为 fallback。 - **直连升级是自动的**。最初的包可能走 relay;一旦 hole-punching 成功,连接会透明地 升级到直连。从应用的角度,还是同一个 `Connection` 对象。 - **Relay 是开放的**。默认的 relay 是 n0 跑的,但 relay 协议是有文档的,你也可以自己搭 ——和 Tailscale 让你自带 DERP 是一样的方式。 对 UniClipboard 而言,这意味着什么: - 整个 P2P 层大概是 **300 行 Rust**(连接生命周期、ALPN 协商、消息分帧、peer 发现的钩子)。 libp2p 版本是 1200+ 行,可靠性还更差。 - 上线之后我没再操心过传输层。系统的每个其他部分我都遇到过 bug;iroh 没有过。 - 一个在双层 NAT 后面(典型的移动运营商)的用户报告 hole-punching 成功率大概在 80–85%。 剩下的 15–20% 透明地降级到 relay,用户感受不到。 ## "iroh 不会哪天死掉/在你脚下变化吗?" 诚实的回答是:有可能。iroh 比 libp2p 年轻,团队更小,break change 更多。我在 0.x 期间已经 做过两次非平凡的迁移。 我下注的是:我所依赖的 API 表面(`Endpoint`、`Connection`、`SecretKey`、`NodeAddr`) 是小且稳定的。只要这些原语继续工作,我就能吸收下层的变动。到目前为止这个赌注成立。 万一 iroh 哪天不再被维护的应急方案:底下那些原语(QUIC + DERP 风格的 relay + STUN 风格的 hole-punching)都是标准件。在 raw Quinn 之上重新实现这套 SDK 形状会很不爽,但是有界的—— 大概 2–3 周的工作量。考虑到生产力收益,这是个可接受的风险。 ## 关于"用 Tailscale 不就行了吗" 任何 P2P 帖子在 HN 上都会收到的常见回复是:"为什么不直接放到 Tailscale 上?" Tailscale 很棒,我自己也在用。但是把它做成 UniClipboard 的硬依赖意味着: - 每个用户都要注册 Tailscale(账号、SSO 步骤、一个不属于他们的控制平面) - 每对设备都要在同一个 tailnet 里 - "没有第三方能看到任何东西"的故事现在依赖于信任 Tailscale 的控制平面 (它做得非常好,但它毕竟是个第三方) 对已经在跑 Tailscale 的用户来说,确实——他们大概可以用 `tailscale serve` + 一个小 daemon 合成出 UniClipboard 80% 的功能。选择不强制要 Tailscale 是有意为之的:卖点是"装到两台机器上, 就能用,不用在任何地方有账号"。 ## 总结 如果你在 2026 年挑选一个 Rust P2P 栈,我会这样想这些选项: | 库 | 适合 | 不适合 | |---|---|---| | **iroh** | 桌面应用、2-N 设备的小网格、"我想 dial 一个 peer" | 你需要浏览器支持、需要最大化的协议灵活性 | | **libp2p** | 自定义协议、大型 peer 网络、IPFS 周边 | 小应用,你不需要 80% 的可配置性 | | **WebRTC** | 浏览器 P2P、视频/音频 | 纯桌面、小载荷、不要多媒体 | | **syncthing/BEP** | 文件夹同步 | 任何不是文件夹同步的事情 | | **magic-wormhole** | 一次性传输、人类可读的码 | 长连接通道 | | **Tailscale + 自研** | 你本来就要求 Tailscale | 你想要零账号 | 具体到 UniClipboard——小载荷、持久的设备配对、不要基础设施、纯桌面——iroh 是干净的契合。 一年下来,我还会做同样的选择。 --- ## 关于 UniClipboard UniClipboard 是一款端到端加密、P2P 的剪贴板同步工具,支持 macOS、Windows 和 Linux。 开源协议 AGPL-3.0。没有账号,没有服务器(只有 relay fallback,而且只看得到密文)。 - GitHub: - Site: - 当前版本:0.6.0 如果这篇文章对你有用,整个项目会感激你给个 star,但更有用的是一份 bug report、 一份打包贡献,或者对上面任何一个技术决定的有理有据的反对意见。 # Changelog --- > **Source**: https://www.uniclipboard.app/changelog/1.6.1 > **Locale**: English > **Version**: v1.6.1 > **Released**: 2026-11-03 ## 1.6.1 - 2026-11-03 ### Features - Ask for confirmation before resending starts a new transfer, and show sending progress for each device (#2129) - Show each file’s receiving progress and save status in history details (#2172) - Add compact transfer status indicators with expandable details in history (#2179) - Use image thumbnails for lighter, faster history browsing while keeping original images available (#2145) - Make settings easier to use in narrow windows with a collapsible category menu (#2126) - Let you choose Normal or Lightweight desktop mode independently of starting in the background at login (#2114) - Add a signed package repository for installing and updating UniClipboard with pacman on Arch Linux (#2132) ### Fixes - Prevent received text, images, and files from repeatedly syncing back to other devices (#2190) - Keep deliberate copies of the same content from being ignored on macOS (#2196) - Keep new history entries visible when you are at the top of the list (#2191) - Preserve the selected history entry and prevent scrollbar jumps when browsing older items (#2159) - Fix history scrolling and keyboard navigation in large windows (#2150) - Show sending progress and receiving progress before file details become available (#2161) - Remove duplicate transfer progress displays from history (#2192) - Keep the Quick Panel action menu visible while navigating between items (#2194) - Apply Quick Panel settings without restarting and recheck macOS Accessibility permission when returning from System Settings (#2171) - Complete translations for Quick Panel screen reader labels (#2184) - Show upgrade progress while the background service starts (#2149) - Restore the app’s live connection after the background service restarts (#2162) - Keep the Linux tray icon visible on KDE panels and update it when the theme changes (#2158) - Correct the size of macOS menu bar icons (#2157) - Show UniClipboard as the application name in the macOS Dock (#2193) - Avoid repeated macOS keychain password prompts when switching between the desktop app and command-line app (#2160) - Reduce memory use during update downloads and direct package-managed installations to their package manager for updates (#2114) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.6.1 > **Locale**: Simplified Chinese > **Version**: v1.6.1 > **Released**: 2026-11-03 ## 1.6.1 - 2026-11-03 ### Features - 重新发送需要启动新传输时先请求确认，并显示各设备的发送进度 (#2129) - 在历史详情中显示每个文件的接收进度和保存状态 (#2172) - 在历史记录中提供紧凑的传输状态提示，并可展开查看详情 (#2179) - 使用图片缩略图提升历史浏览速度、减少资源占用，同时保留原图操作 (#2145) - 窄窗口中的设置分类菜单可收起，让设置内容更易查看 (#2126) - 可独立选择普通或轻量桌面模式，以及是否在登录时后台启动 (#2114) - 新增签名软件包仓库，支持在 Arch Linux 上通过 pacman 安装和更新 UniClipboard (#2132) ### Fixes - 防止收到的文本、图片和文件在设备间反复回传 (#2190) - 修复 macOS 上主动再次复制相同内容时可能被忽略的问题 (#2196) - 浏览历史列表顶部时，保持新记录可见 (#2191) - 浏览较早的历史记录时保留选中项，并防止滚动条跳动 (#2159) - 修复大窗口中的历史滚动和键盘导航问题 (#2150) - 正确显示发送进度，以及文件详情尚未就绪时的接收进度 (#2161) - 移除历史记录中重复的传输进度显示 (#2192) - 在快捷面板中切换条目时保持操作菜单可见 (#2194) - 快捷面板设置无需重启即可生效，并在从系统设置返回时重新检查 macOS 辅助功能权限 (#2171) - 补全快捷面板屏幕阅读器标签的翻译 (#2184) - 在后台服务启动期间显示升级进度 (#2149) - 后台服务重启后恢复应用的实时连接 (#2162) - 修复 KDE 面板上托盘图标不清晰的问题，并在主题变化时更新图标 (#2158) - 修正 macOS 菜单栏图标的大小 (#2157) - 在 macOS 程序坞中正确显示 UniClipboard 应用名称 (#2193) - 避免在桌面应用与命令行应用之间切换时反复提示输入 macOS 钥匙串密码 (#2160) - 减少下载更新时的内存占用，并引导通过软件包管理器安装的用户使用对应的管理器更新 (#2114) --- > **Source**: https://www.uniclipboard.app/changelog/1.5.0 > **Locale**: English > **Version**: v1.5.0 > **Released**: 2026-10-26 ## 1.5.0 - 2026-10-26 ### Breaking Changes - Linux .deb, .rpm, and AppImage downloads now require glibc 2.39 or newer, and the installer selects Snap on Ubuntu 20.04/22.04 and Debian 11/12 (#2094) ### Features - See individual file receive results in history details and retry failed files without downloading successfully saved files again (#2108) ### Fixes - Show image previews for individual image files in the native Quick Panel (#2105) - Keep the native Quick Panel unlocked when closing the main window or entering lightweight mode, and dismiss it when switching to another window on Windows (#2103) - Unlock directly in the Quick Panel without opening the main window, and correctly shrink the panel window and text below 100% on Linux (#2102) - Make Windows Quick Panel fonts consistent with the main window, including Chinese text (#2098) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.5.0 > **Locale**: Simplified Chinese > **Version**: v1.5.0 > **Released**: 2026-10-26 ## 1.5.0 - 2026-10-26 ### Breaking Changes - Linux 的 .deb、.rpm 和 AppImage 安装包现在要求 glibc 2.39 或更新版本，安装脚本在 Ubuntu 20.04/22.04 和 Debian 11/12 上改用 Snap (#2094) ### Features - 在历史详情中查看各个文件的接收结果，并仅重试失败的文件，无需重新下载已保存的文件 (#2108) ### Fixes - 修复原生快捷面板无法预览单个图片文件的问题 (#2105) - 关闭主窗口或进入轻量模式后，原生快捷面板保持解锁，并在 Windows 上切换到其他窗口时自动收起 (#2103) - 支持直接在快捷面板内解锁，无需打开主窗口，并修复 Linux 上面板窗口和文字无法缩小到 100% 以下的问题 (#2102) - 统一 Windows 快捷面板与主窗口的字体显示，包括中文字体 (#2098) --- > **Source**: https://www.uniclipboard.app/changelog/1.4.0 > **Locale**: English > **Version**: v1.4.0 > **Released**: 2026-10-23 ## 1.4.0 - 2026-10-23 ### Features - Simplify connecting phones and switching spaces with step-by-step panels that keep setup, connection details, and retry actions together (#2086) - Apply theme colors more consistently across the app and quick panel, with native default palettes and optional Omarchy theme following (#2071) - Include desktop preferences in configuration backups and offer clearer recovery guidance and confirmation before replacing an unfinished import (#2061) ### Fixes - Remember the main window's size and maximized state across restarts (#2074) - Release window resources when closing the main window while keeping background sync running, and keep automatic update checks from reopening closed windows (#2078) - Retry temporary secure-storage startup failures on Linux and let you retry startup once secure storage becomes available (#2081) - Show release notes for changes since your installed version when checking for updates (#2070) - Prevent Windows quick panel crashes when a requested font is unavailable (#2072) - Stop continuous progress-bar animation on Windows when reduced motion is enabled (#2066) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.4.0 > **Locale**: Simplified Chinese > **Version**: v1.4.0 > **Released**: 2026-10-23 ## 1.4.0 - 2026-10-23 ### Features - 优化连接手机和切换空间的分步操作，将设置、连接信息和重试操作集中在同一面板中 (#2086) - 统一应用和快捷面板的主题配色，支持各平台默认配色，并可选择跟随 Omarchy 主题 (#2071) - 配置备份现在包含桌面偏好设置，并为未完成的导入提供更清晰的恢复指引及替换前确认 (#2061) ### Fixes - 修复重启后主窗口尺寸和最大化状态无法保留的问题 (#2074) - 关闭主窗口后释放窗口资源并保持后台同步，自动检查更新也不会重新打开已关闭的窗口 (#2078) - 修复 Linux 上安全存储暂时不可用导致的启动失败，支持自动重试并在安全存储恢复后手动重试启动 (#2081) - 检查更新时显示自当前已安装版本以来的更新内容 (#2070) - 修复 Windows 快捷面板在所需字体不可用时崩溃的问题 (#2072) - 修复 Windows 上启用减少动态效果后进度条仍持续播放动画的问题 (#2066) --- > **Source**: https://www.uniclipboard.app/changelog/1.3.1 > **Locale**: English > **Version**: v1.3.1 > **Released**: 2026-10-22 ## 1.3.1 - 2026-10-22 ### Fixes - Fixed a Windows startup crash when reduced motion is enabled. Indeterminate progress bars now remain static when animations are disabled. --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.3.1 > **Locale**: Simplified Chinese > **Version**: v1.3.1 > **Released**: 2026-10-22 ## 1.3.1 - 2026-10-22 ### 修复 - 修复 Windows 启用减少动态效果时的启动崩溃。禁用动画时，不确定进度条保持静止。 --- > **Source**: https://www.uniclipboard.app/changelog/1.2.1 > **Locale**: English > **Version**: v1.2.1 > **Released**: 2026-10-21 ## 1.2.1 - 2026-10-21 ### Features - Add experimental installation through Nix on x86_64 and ARM64 Linux (#2036) ### Fixes - On macOS, hide the Dock icon while the main window is closed or after silent startup, and restore it when the window opens (#2042) - Fix a possible freeze when reopening the main window from the menu bar on macOS (#2043) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.2.1 > **Locale**: Simplified Chinese > **Version**: v1.2.1 > **Released**: 2026-10-21 ## 1.2.1 - 2026-10-21 ### Features - 新增通过 Nix 在 x86_64 和 ARM64 Linux 上安装的实验性支持 (#2036) ### Fixes - 修复 macOS 上主窗口关闭或静默启动后 Dock 图标仍然显示的问题，并在打开窗口时恢复图标 (#2042) - 修复 macOS 上从菜单栏重新打开主窗口时可能卡住的问题 (#2043) --- > **Source**: https://www.uniclipboard.app/changelog/1.2.0 > **Locale**: English > **Version**: v1.2.0 > **Released**: 2026-10-20 ## 1.2.0 - 2026-10-20 ### Features - Browse clipboard history in a redesigned macOS interface with a sidebar and detail pane (#1963) - Browse clipboard history in a redesigned Windows 11-style interface (#1962) - Use a Linux-style interface across history, settings, setup and unlock screens (#1989) - Use redesigned settings pages that match the look of macOS (#1977) - Use redesigned settings pages that match the look of Windows 11 (#1987) - Manage paired devices and sync preferences without leaving your history view (#2010) - Select multiple history entries to pin, send or delete them together (#1844) - Organize history with custom colored tags and inspect, save or open images from the detail pane (#1848) - Search with suggestions, multiple tags and shortcuts for content types and source devices (#1846) - See matching item counts for search filters and remove suggested filters when no results are found (#1842) - Unlock your clipboard directly from the quick panel (#1975) - Use the native quick panel on Windows (#1950) ### Fixes - Keep history detail previews stable and scrollable when switching between entries (#2035) - Prevent the quick panel from briefly showing text from a different entry (#1991) - Keep the quick panel and its preview together on the same display (#1975) - Allow search filters to be added after ordinary search text (#1974) - Allow history to load beyond 200 matching entries (#1964) - Prevent history from repeatedly refreshing while loading more entries (#1973) - Correctly record shortcuts that combine Option with letter or number keys (#1986) - Improve the reliability of opening the quick panel with a modifier-key double tap on macOS (#1988) - Improve Windows startup, quitting and tray menu refresh reliability (#1928) - Make smaller quick-panel window sizes take effect on Linux desktops using X11 (#1883) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.2.0 > **Locale**: Simplified Chinese > **Version**: v1.2.0 > **Released**: 2026-10-20 ## 1.2.0 - 2026-10-20 ### Features - 在 macOS 上使用重新设计的剪贴板历史界面，通过侧边栏和详情面板浏览记录 (#1963) - 在 Windows 上使用全新 Windows 11 风格的剪贴板历史界面 (#1962) - 在 Linux 上使用统一的系统风格界面，涵盖历史记录、设置、首次设置和解锁页面 (#1989) - 使用更贴合 macOS 风格的全新设置页面 (#1977) - 使用更贴合 Windows 11 风格的全新设置页面 (#1987) - 无需离开历史记录页面即可管理已配对设备和同步偏好 (#2010) - 一次选择多条历史记录，批量置顶、发送或删除 (#1844) - 使用自定义彩色标签整理历史记录，并在详情面板中查看、保存图片或用其他应用打开图片 (#1848) - 通过搜索建议、多个标签以及内容类型和来源设备的快捷筛选查找记录 (#1846) - 查看搜索筛选条件的匹配数量，并在没有结果时按建议移除筛选条件 (#1842) - 直接在快捷面板中输入口令解锁剪贴板 (#1975) - 在 Windows 上使用原生快捷面板 (#1950) ### Fixes - 修复切换历史记录时详情预览不稳定或无法滚动的问题 (#2035) - 修复快捷面板短暂显示其他记录文本的问题 (#1991) - 修复快捷面板与预览窗口出现在不同显示器上的问题 (#1975) - 修复在普通搜索文字后无法添加筛选条件的问题 (#1974) - 修复历史记录加载到 200 条后无法继续显示更多记录的问题 (#1964) - 修复加载更多历史记录时反复刷新的问题 (#1973) - 修复无法正确录入 Option 与字母键或数字键组合的快捷键的问题 (#1986) - 修复 macOS 上双击修饰键唤出快捷面板不可靠的问题 (#1988) - 修复 Windows 上启动、退出和托盘菜单刷新不可靠的问题 (#1928) - 修复 Linux X11 桌面上调小快捷面板窗口后尺寸不生效的问题 (#1883) --- > **Source**: https://www.uniclipboard.app/changelog/1.1.2 > **Locale**: English > **Version**: v1.1.2 > **Released**: 2026-10-09 ## 1.1.2 - 2026-10-08 ### Fixes - Fix the data upgrade failing on every launch with "backup failed" after a first upgrade attempt was interrupted: the pre-upgrade backup is now recaptured on retry, and the earlier backup is kept (#1833) - Fix Engine diagnostic logs going silent once the local log quota was full: the oldest log file is now removed to make room instead of dropping new records (#1833) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.1.2 > **Locale**: Simplified Chinese > **Version**: v1.1.2 > **Released**: 2026-10-09 ## 1.1.2 - 2026-10-08 ### Fixes - 修复数据升级在第一次尝试被中断后，之后每次启动都提示“备份失败”的问题：重试时会重新生成升级前备份，并保留之前的备份 (#1833) - 修复本地日志配额写满后 Engine 诊断日志不再记录的问题：现在会删除最旧的日志文件腾出空间，而不是丢弃新记录 (#1833) --- > **Source**: https://www.uniclipboard.app/changelog/1.1.1 > **Locale**: English > **Version**: v1.1.1 > **Released**: 2026-10-04 ## 1.1.1 - 2026-10-04 ### Fixes - Fix the quick panel staying in Chinese instead of following the app or system language, ignoring language and theme settings while locked, and showing tag and device suggestions while locked (#1834) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.1.1 > **Locale**: Simplified Chinese > **Version**: v1.1.1 > **Released**: 2026-10-04 ## 1.1.1 - 2026-10-04 ### Fixes - 修复快捷面板始终显示中文而不跟随应用或系统语言、锁定时不遵循语言和主题设置，以及锁定后仍显示标签和设备建议的问题 (#1834) --- > **Source**: https://www.uniclipboard.app/changelog/1.1.0 > **Locale**: English > **Version**: v1.1.0 > **Released**: 2026-10-03 ## 1.1.0 - 2026-10-03 ### Features - Redesign the macOS quick panel with search suggestions, filters for tags, devices, content types and dates, and separate content previews (#1786) - Show built-in relay servers and whether the current relay settings have taken effect in network settings (#1813) - Add a command to change the passphrase of an unlocked, single-device space without losing local history (#1802) - Show file transfer progress in the command line and let users set how long sending waits for a device to connect (#1765) ### Fixes - Remember the desktop window's size, position where supported, and maximized state across restarts (#1772) - Reduce excessive memory use when browsing images in the macOS quick panel (#1806) - Make the macOS quick panel close promptly when pressing Esc (#1817) - Fix blank windows and startup crashes with AppImage on some newer Linux systems (#1815) - Fix startup failures on Linux systems whose password storage rejects the app's key format (#1819) - Keep the app usable after a space factory reset and automatically restart it if recovery requires a restart (#1820) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.1.0 > **Locale**: Simplified Chinese > **Version**: v1.1.0 > **Released**: 2026-10-03 ## 1.1.0 - 2026-10-03 ### Features - 重新设计 macOS 快捷面板，提供搜索建议、按标签、设备、内容类型和日期筛选的功能，以及独立的内容预览 (#1786) - 在网络设置中显示内置中继服务器，以及当前中继设置是否已生效 (#1813) - 新增命令，可为已解锁且只有一台设备的空间修改口令，同时保留本地历史记录 (#1802) - 在命令行中显示文件传输进度，并支持设置发送时等待设备连接的时长 (#1765) ### Fixes - 重启后保留桌面窗口的大小、最大化状态，以及系统支持时的窗口位置 (#1772) - 减少在 macOS 快捷面板中浏览图片时的过量内存占用 (#1806) - 按下 Esc 后，macOS 快捷面板可及时关闭 (#1817) - 修复 AppImage 在部分较新的 Linux 系统上出现空白窗口或启动崩溃的问题 (#1815) - 修复部分 Linux 系统因密码存储服务拒绝应用的密钥格式而无法启动的问题 (#1819) - 修复空间恢复出厂设置后应用无法继续使用的问题，并在恢复需要重启时自动重启应用 (#1820) --- > **Source**: https://www.uniclipboard.app/changelog/1.0.1 > **Locale**: English > **Version**: v1.0.1 > **Released**: 2026-09-29 ## 1.0.1 - 2026-09-29 > [!WARNING] > 1.0 is a breaking upgrade: you cannot downgrade to 0.19 afterwards, and every device must be updated to 1.0 and paired again before syncing resumes. Read the [upgrade guide](https://docs.uniclipboard.app/migration/upgrade-0-19-to-v1) before upgrading. ### Fixes - Remember each settings category’s scroll position when switching categories within the same window (#1762) - Fix startup failures on some Linux installations upgraded from versions before 1.0 (#1753) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.0.1 > **Locale**: Simplified Chinese > **Version**: v1.0.1 > **Released**: 2026-09-29 ## 1.0.1 - 2026-09-29 > [!WARNING] > 1.0 是一次破坏性升级：升级后无法降级回 0.19，所有设备都需升级到 1.0 并重新配对后才能继续同步。升级前请先阅读[升级指南](https://docs.uniclipboard.app/migration/upgrade-0-19-to-v1)。 ### Fixes - 在同一窗口内切换设置分类时，记住并恢复各分类的滚动位置 (#1762) - 修复部分 Linux 用户从 1.0 之前的版本升级后无法启动应用的问题 (#1753) --- > **Source**: https://www.uniclipboard.app/changelog/1.0.0 > **Locale**: English > **Version**: v1.0.0 > **Released**: 2026-09-28 ## 1.0.0 - 2026-09-28 > [!WARNING] > 1.0 is a breaking upgrade: you cannot downgrade to 0.19 afterwards, and every device must be updated to 1.0 and paired again before syncing resumes. Read the [upgrade guide](https://docs.uniclipboard.app/migration/upgrade-0-19-to-v1) before upgrading. ### Breaking Changes - Local data is upgraded to a new storage and protection format; downgrading back to 0.19 afterwards is not possible (#1424) - All devices must be updated to 1.0 and paired again to keep syncing with each other; 1.0 cannot sync with devices still on an older version (#1483) (#1586) - Quick panel commands now require UniClipboard to be running and exit with an error when it is not (#1702) ### Features - Choose which content types this device sends to and receives from each paired device (#1461) - Control all syncing and automatic clipboard syncing separately, and still send content manually while automatic sync is off (#1546) - Turn syncing on or off for all devices or a single paired device directly from the tray menu (#1638) - When a device comes back online, it automatically receives the latest clipboard item it missed (#1517) - Incoming transfers continue after an app restart, show combined progress for multiple items, and can be cancelled from the receiving entry (#1399) - Refresh the transfer activity display on macOS (#1603) - Add, replace, or remove access tokens for custom relay servers directly in network settings (#1447) - Device invitations are now the main way to add devices, with clearer invite code and passphrase input and status for pairings that are awaiting confirmation, expired, or replaced (#1532) (#1506) (#1675) - Choose regular sync or experimental invite code pairing from a single Connect Phone dialog on the Devices page (#1439) (#1666) - The Devices page shows each device's connection progress and update requirements, supports refreshing connections manually, and retries automatically when you return to the app or wake the computer (#1484) (#1518) (#1641) (#1656) - Remove devices from a space with visible progress, plus recovery options when other devices are permanently unavailable (#1457) (#1504) - When a device group change needs confirmation, see which devices will keep or pause syncing and choose which ones to keep (#1552) (#1628) - Joining or switching spaces shows progress and failure reasons, and lets you wait for or cancel requests that need another device's approval (#1573) - When this is the only device in a space, reset the space passphrase while keeping local history (#1672) - Rebuild a space while keeping local history, received files, and settings (#1626) - Redesigned navigation and history search, with search suggestions, keyboard completion, and animated menus, dialogs, and notifications (#1587) (#1580) - Code previews use theme-matched colors and show line counts (#1580) - Add Smooth Mode, which adjusts visual effects to the device automatically or lets you prefer effects or smoothness (#1636) - The quick panel always shows content type and tag filters and keeps your selected filters (#1496) - Add a Traditional Chinese interface (#1413) - Add an option to skip confirmation when deleting a single history item (#1564) - Choose an automatic, app, system, or no title bar on Windows and Linux (#1566) (#1646) - The main window can be resized smaller, with more consistent text sizes and spacing across pages (#1657) (#1659) - Unify the startup, setup, and unlock screens, with inline passphrase entry and a show/hide toggle (#1731) - Open the quick panel with a desktop shortcut on Linux desktops where global shortcuts are unavailable (#1568) - The Linux quick panel can show history and preview side by side, resize the window and text independently, and follow the Omarchy theme automatically (#1664) - Local data is backed up automatically before upgrades, with visible progress, and backups can be viewed or deleted in storage settings (#1647) (#1671) - Retry startup, check for updates, or contact support directly from the startup failure screen (#1643) - Recover data with the original encryption passphrase when the system-stored key is missing or unavailable (#1710) - When corrupted local data prevents startup, existing data is kept and recovery guidance is shown (#1734) - Send existing files with `uniclip send ./file`, target specific devices, and pipe multiple file paths in one command (#1701) (#1720) - Wait for the next synced item with `uniclip get --wait`, with file receive progress, and copy it to the terminal computer's clipboard with `uniclip get --copy` (#1711) (#1725) (#1696) - View or cancel join requests, handle device trust changes, and adjust per-device sync preferences from the command line (#1579) - Command-line output is easier to use in scripts, without extra status messages mixed into retrieved content or file paths (#1695) ### Fixes - Fix copied folders on Windows not being synced (#1399) - Show a clear transfer status when sending folders instead of a percentage that resets for every file (#1408) - Fix pasting file paths from the quick panel changing the system clipboard (#1476) - Improve history list scrolling responsiveness on Linux (#1663) - Fix the background service being interrupted when opening the app or running commands while it is temporarily slow to respond (#1704) - Fix diagnostic log exports on Windows missing logs that were still being written (#1741) --- > **Source**: https://www.uniclipboard.app/zh/changelog/1.0.0 > **Locale**: Simplified Chinese > **Version**: v1.0.0 > **Released**: 2026-09-28 ## 1.0.0 - 2026-09-28 > [!WARNING] > 1.0 是一次破坏性升级：升级后无法降级回 0.19，所有设备都需升级到 1.0 并重新配对后才能继续同步。升级前请先阅读[升级指南](https://docs.uniclipboard.app/migration/upgrade-0-19-to-v1)。 ### Breaking Changes - 本地数据会升级为新的存储和保护格式，升级后无法再降级回 0.19 (#1424) - 所有设备都需升级到 1.0 并重新配对后才能继续互相同步，1.0 无法与仍在旧版本的设备同步 (#1483) (#1586) - 快捷面板命令现在要求 UniClipboard 已在运行，应用未启动时会报错退出 (#1702) ### Features - 可分别设置本机向每台已配对设备发送和接收哪些内容类型 (#1461) - 可分别控制全部同步和剪贴板自动同步，关闭自动同步后仍可手动发送内容 (#1546) - 可直接从托盘菜单开启或关闭所有设备或单台设备的同步 (#1638) - 设备重新上线后，自动补送它错过的最新一条剪贴板内容 (#1517) - 接收中的传输在应用重启后仍可继续，多项内容显示汇总进度，并可直接从接收条目取消 (#1399) - 更新 macOS 上的传输活动显示界面 (#1603) - 可直接在网络设置中添加、更换或移除自定义中继节点的访问令牌 (#1447) - 邀请设备成为添加设备的主要方式，邀请码和口令输入更清晰，并显示配对等待确认、已过期或被新配对取代等状态 (#1532) (#1506) (#1675) - 在设备页的“连接手机”对话框中统一选择常规同步或实验性邀请码配对 (#1439) (#1666) - 设备页显示各设备的连接进度和更新要求，支持手动刷新连接，并在返回应用或唤醒电脑时自动重试 (#1484) (#1518) (#1641) (#1656) - 支持从空间中移除设备并显示移除进度，其他设备永久不可用时提供恢复选项 (#1457) (#1504) - 设备组发生需要确认的变更时，可查看哪些设备将继续或暂停同步，并选择要保留的设备 (#1552) (#1628) - 加入或切换空间时显示进度和失败原因，需要其他设备确认时可等待或取消 (#1573) - 当本机是空间中唯一的设备时，可重设空间口令并保留本地历史记录 (#1672) - 支持重建空间，同时保留本地历史记录、已接收的文件和设置 (#1626) - 重新设计导航和历史记录搜索，新增搜索建议和键盘补全，菜单、对话框和通知加入过渡动效 (#1587) (#1580) - 代码预览使用与主题一致的配色并显示行数 (#1580) - 新增流畅模式，可根据设备自动调整视觉效果，也可手动选择效果优先或流畅优先 (#1636) - 快捷面板始终显示内容类型和标签筛选项，并保留已选筛选条件 (#1496) - 新增繁体中文界面 (#1413) - 新增删除单条历史记录时跳过确认的选项 (#1564) - Windows 和 Linux 的标题栏可选择自动、应用、系统或无 (#1566) (#1646) - 主窗口可以缩小到更小的尺寸，各页面的文字大小与间距更统一 (#1657) (#1659) - 统一启动、设置和解锁界面的布局，可直接在页面输入加密口令并切换显示或隐藏 (#1731) - 在无法使用全局快捷键的 Linux 桌面环境中，可通过桌面快捷键打开快捷面板 (#1568) - Linux 快捷面板支持历史与预览并排显示、分别调整窗口大小和文字缩放，并可自动跟随 Omarchy 主题 (#1664) - 升级本地数据前自动备份并显示进度，可在存储设置中查看或删除备份 (#1647) (#1671) - 启动失败时可直接在页面上重试启动、检查更新或联系支持 (#1643) - 系统保存的密钥丢失或不可用时，可使用原加密口令恢复数据 (#1710) - 本地数据损坏导致无法启动时，保留现有数据并显示恢复指引 (#1734) - 支持通过 `uniclip send ./file` 直接发送文件并指定接收设备，也可通过管道一次发送多个文件 (#1701) (#1720) - 支持通过 `uniclip get --wait` 等待下一条同步内容并显示文件接收进度，通过 `uniclip get --copy` 复制到终端所在电脑的剪贴板 (#1711) (#1725) (#1696) - 支持通过命令行查看或取消加入请求、处理设备信任变更，以及调整单台设备的同步偏好 (#1579) - 命令行结果更便于在脚本中使用，取回内容和文件路径不再混入额外提示 (#1695) ### Fixes - 修复 Windows 上复制的文件夹无法被同步的问题 (#1399) - 发送文件夹时显示明确的传输状态，不再显示随每个文件重置的百分比 (#1408) - 修复从快捷面板粘贴文件路径时会改变系统剪贴板的问题 (#1476) - 改善 Linux 上历史列表的滚动响应 (#1663) - 修复后台服务暂时响应缓慢时，打开应用或执行命令可能导致后台服务中断的问题 (#1704) - 修复 Windows 上导出诊断日志时遗漏正在写入的日志的问题 (#1741) --- > **Source**: https://www.uniclipboard.app/changelog/0.19.4 > **Locale**: English > **Version**: v0.19.4 > **Released**: 2026-09-22 ## 0.19.4 - 2026-09-22 ### Features - Require explicit confirmation before major updates are downloaded or installed ### Fixes - Release audio hardware after interaction sounds have been idle, preventing the app from affecting other audio playback - Declare and bundle the required GTK Layer Shell runtime for Linux packages --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.19.4 > **Locale**: Simplified Chinese > **Version**: v0.19.4 > **Released**: 2026-09-22 ## 0.19.4 - 2026-09-22 ### Features - 下载或安装重大版本更新前，现会要求用户明确确认 ### Fixes - 交互提示音空闲后会释放音频设备，避免影响其他应用的声音播放 - 为 Linux 安装包补充 GTK Layer Shell 运行依赖，并在便携包中包含所需文件 --- > **Source**: https://www.uniclipboard.app/changelog/0.19.3 > **Locale**: English > **Version**: v0.19.3 > **Released**: 2026-08-30 ## 0.19.3 - 2026-08-30 ### Features - Add Japanese language support throughout the desktop app and tray menu - Add an option on Windows and Linux to use the system title bar and window controls ### Fixes - Make long links easier to read and open in clipboard previews (#1411) - Prevent visual artifacts when switching pages or toggling settings (#1414) - Restore support for macOS Monterey 12.5 and later (#1431) - Prevent temporary port conflicts from stopping the app during startup (#1474) - Show a clear fallback instead of failing when a text preview is unavailable (#1556) - Keep the history list at a readable width on wide screens (#1582) - Keep the app connected to its local background service when a system proxy is configured - Improve Linux window rendering and prevent AppImage startup failures on affected systems --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.19.3 > **Locale**: Simplified Chinese > **Version**: v0.19.3 > **Released**: 2026-08-30 ## 0.19.3 - 2026-08-30 ### Features - 桌面应用和托盘菜单现已支持日语 - Windows 和 Linux 现可选择使用系统标题栏和窗口控件 ### Fixes - 优化剪贴板链接预览，使较长链接更易阅读和打开 (#1411) - 修复切换页面或开关设置时出现的画面残影 (#1414) - 恢复对 macOS Monterey 12.5 及更高版本的支持 (#1431) - 修复临时端口冲突导致应用启动失败的问题 (#1474) - 修复文本预览不可用时无法正常显示的问题，并提供明确提示 (#1556) - 限制宽屏下的历史记录列表宽度，使内容更易阅读 (#1582) - 修复配置系统代理后应用无法连接本地后台服务的问题 - 改善 Linux 窗口显示，并修复部分环境下 AppImage 无法启动的问题 --- > **Source**: https://www.uniclipboard.app/changelog/0.19.2 > **Locale**: English > **Version**: v0.19.2 > **Released**: 2026-08-29 ## 0.19.2 - 2026-08-29 ### Fixes - Prevent the Windows app from closing unexpectedly while syncing large images with multiple formats - Correctly match image and file entries when retrieving clipboard content by type from the command line (#1436) - Load the complete text when opening a truncated search result (#1415) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.19.2 > **Locale**: Simplified Chinese > **Version**: v0.19.2 > **Released**: 2026-08-29 ## 0.19.2 - 2026-08-29 ### Fixes - 修复 Windows 应用在同步包含多种格式的大图片时意外退出的问题 - 修复通过命令行按类型获取剪贴板内容时无法正确匹配图片和文件的问题 (#1436) - 修复打开被截断的搜索结果时无法加载完整文本的问题 (#1415) --- > **Source**: https://www.uniclipboard.app/changelog/0.19.1 > **Locale**: English > **Version**: v0.19.1 > **Released**: 2026-07-18 ## 0.19.1 - 2026-07-18 ### Features - Android users can now receive stable and beta app releases and download the matching APK update (#1401) ### Fixes - Make first-time setup clearly distinguish a space being ready from a successful device pairing, and leave the invitation screen as soon as pairing succeeds (#1402) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.19.1 > **Locale**: Simplified Chinese > **Version**: v0.19.1 > **Released**: 2026-07-18 ## 0.19.1 - 2026-07-18 ### Features - Android 用户现在可以接收稳定版和测试版应用发布，并下载对应的 APK 更新 (#1401) ### Fixes - 首次设置现在会明确区分“空间已就绪”和“设备配对成功”，并在配对成功后立即离开邀请码页面 (#1402) --- > **Source**: https://www.uniclipboard.app/changelog/0.18.0 > **Locale**: English > **Version**: v0.18.0 > **Released**: 2026-07-04 ## 0.18.0 - 2026-07-04 ### Features - Show image thumbnails in the Quick Panel list and switch the Image filter to a three-column thumbnail wall for faster visual browsing (#1266) - Add Startup mode controls, including Lightweight mode and an option to restore the last clipboard entry when the app starts (#1275) - Let you choose a folder where received files are saved directly instead of keeping them only in app-managed storage (#1271) - Reduce automatic update pop-ups during busy release periods while keeping manual update checks available anytime (#1287) - Move device and mobile-sync details into inline panels so pairing credentials, device facts, and sync controls are easier to use from the Devices page (#1291) ### Fixes - Show release notes in the update window, honor your selected update channel, and check for a newer release again before installing (#1280) - Prevent search and history content from being returned while the app is locked, so locked sessions no longer expose searchable previews (#1292) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.18.0 > **Locale**: Simplified Chinese > **Version**: v0.18.0 > **Released**: 2026-07-04 ## 0.18.0 - 2026-07-04 ### Features - 快捷面板列表现在会显示图片缩略图，选择图片筛选后会切换为三列缩略图墙，方便快速浏览图片记录 (#1266) - 新增启动方式设置，包含轻量模式，以及应用启动时恢复最近一条剪贴板记录的选项 (#1275) - 现在可以选择接收文件的保存文件夹，让收到的文件直接保存到指定位置，而不是只放在应用托管存储中 (#1271) - 在版本发布密集时减少自动更新弹窗打扰，同时手动检查更新仍可随时使用 (#1287) - 设备页改为内嵌面板展示设备与移动端同步详情，让配对凭据、设备信息和同步开关更容易操作 (#1291) ### Fixes - 更新窗口现在会显示版本说明，遵循你选择的更新频道，并在安装前再次检查是否已有更新版本 (#1280) - 应用锁定时不再返回搜索和历史内容，避免锁定会话暴露可搜索的预览信息 (#1292) --- > **Source**: https://www.uniclipboard.app/changelog/0.17.1 > **Locale**: English > **Version**: v0.17.1 > **Released**: 2026-07-02 > **⚠️ Important notice for users on 0.14.0-alpha.9 – 0.14.0**: these versions have a bug that prevents automatic updates from completing. Please open `https://uniclipboard.app/download` in your browser, download the latest installer, and reinstall manually. ## 0.17.1 - 2026-07-02 ### Fixes - Prevent the app from staying offline until restart after launch or update when the network is already available, and make connection checks refresh their network state before reporting failure (#1261, #1264) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.17.1 > **Locale**: Simplified Chinese > **Version**: v0.17.1 > **Released**: 2026-07-02 > **⚠️ 重要公告（0.14.0-alpha.9 ~ 0.14.0 用户）**：这些版本存在自动更新缺陷，点击安装后无法完成更新。请在浏览器中打开 `https://uniclipboard.app/download`，手动下载最新安装包覆盖安装。 ## 0.17.1 - 2026-07-02 ### Fixes - 修复启动或更新后网络已可用但应用仍显示离线、必须重启才恢复的问题，并让连接检查在报告失败前刷新网络状态 (#1261, #1264) --- > **Source**: https://www.uniclipboard.app/changelog/0.17.0 > **Locale**: English > **Version**: v0.17.0 > **Released**: 2026-07-01 > **⚠️ Important notice for users on 0.14.0-alpha.9 – 0.14.0**: these versions have a bug that prevents automatic updates from completing. Please open `https://uniclipboard.app/download` in your browser, download the latest installer, and reinstall manually. ## 0.17.0 - 2026-07-01 ### Features - The History page now uses a searchable card grid with richer previews and easier browsing (#1165) - Browse and search now share one live result view, so filters, favorites, and new clipboard items stay in sync across history surfaces (#1171) - The History page now has a three-pane layout with tag search and clearer entry details (#1180) - Clipboard previews now include a favorite action and shortcut (#1182) - History cards now have a context menu, and the quick panel search can combine multiple filters (#1185) - The Windows History page now places search in the title bar for quicker access (#1187) - History and quick panel filters now recognize Rich Text as its own content type and show link or code tags separately (#1197) - Shortcut settings now support two-step shortcuts and double-tap shortcuts (#1148) - Storage settings now include an Unlimited max history items option, and automatic cleanup follows the configured retention rules while protecting favorites (#1225) - The `uniclip search` command can now filter results by source device (#1208) - Scrollbars now follow the app theme (#1212) - The About settings page now has a clearer update area and sponsor section (#1214) - Sponsor information now shows a placeholder while it loads (#1232) ### Fixes - Mobile clients now receive readable file previews instead of raw HTML when syncing clipboard files (#1220) - File previews in clipboard history now use the actual file list instead of showing the copied file path text (#1217) - File clipboard entries now render as files instead of `file://` text (#1205) - New clipboard items no longer steal focus from the first active history card (#1204) - Code previews now scroll more smoothly and consistently (#1196) - Clipboard image previews now load reliably instead of failing with authorization errors (#1192) - Chinese, Japanese, and Korean text now uses a more consistent system font across the app and code cards (#1190) - Search index rebuilds now resume after an interrupted startup instead of leaving search stuck (#1179) - Copying the same files through multiple clipboard formats no longer creates duplicate history entries (#1173) - The Open File Location action now opens the folder for received files (#1158) - Restart from the tray now restarts both the window and background service (#1157) - Linux image clipboard bursts, especially from shared clipboard tools, are now less likely to create repeated image entries (#1154) - Lightweight Mode now makes it clearer that UniClipboard is still running in the background, and weak-GPU Windows devices should see smoother clipboard and device pages (#1149) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.17.0 > **Locale**: Simplified Chinese > **Version**: v0.17.0 > **Released**: 2026-07-01 > **⚠️ 重要公告（0.14.0-alpha.9 ~ 0.14.0 用户）**：这些版本存在自动更新缺陷，点击安装后无法完成更新。请在浏览器中打开 `https://uniclipboard.app/download`，手动下载最新安装包覆盖安装。 ## 0.17.0 - 2026-07-01 ### Features - 历史记录页改为可搜索的卡片网格，预览更丰富，浏览更方便 (#1165) - 浏览和搜索现在共用同一个实时结果视图，筛选、收藏和新剪贴板内容会在历史记录相关界面中保持同步 (#1171) - 历史记录页新增三栏布局、标签搜索和更清晰的条目详情 (#1180) - 剪贴板预览现在可以直接收藏条目，并支持对应快捷键 (#1182) - 历史记录卡片新增右键菜单，快捷面板搜索现在可以组合多个筛选条件 (#1185) - Windows 上的历史记录页现在把搜索放到标题栏，访问更快 (#1187) - 历史记录和快捷面板筛选现在会把富文本识别为独立内容类型，并单独显示链接或代码标签 (#1197) - 快捷键设置现在支持两段式快捷键和双击式快捷键 (#1148) - 存储设置新增“不限制”最大历史条数选项，自动清理会按已配置的保留规则执行并保护收藏条目 (#1225) - `uniclip search` 命令现在可以按来源设备筛选结果 (#1208) - 滚动条现在会跟随应用主题 (#1212) - “关于”设置页现在有更清晰的更新区域和赞助者区域 (#1214) - 赞助者信息加载时现在会显示占位状态 (#1232) ### Fixes - 移动端同步剪贴板文件时，现在会收到可读的文件预览，而不是原始 HTML (#1220) - 剪贴板历史中的文件预览现在会使用实际文件列表，而不是显示复制的文件路径文本 (#1217) - 文件类剪贴板条目现在会按文件渲染，而不是显示为 `file://` 文本 (#1205) - 新剪贴板条目加入列表时，不会再抢走第一个历史卡片的当前焦点 (#1204) - 代码预览的滚动现在更顺畅、更一致 (#1196) - 剪贴板图片预览现在能更可靠地加载，不再因为授权错误而失败 (#1192) - 中日韩文字现在会在应用界面和代码卡片中使用更一致的系统字体 (#1190) - 搜索索引重建如果在启动时被中断，现在会继续恢复，不会让搜索卡住 (#1179) - 通过多种剪贴板格式复制同一批文件时，不会再生成重复历史记录 (#1173) - “打开文件位置”现在可以打开已接收文件所在的文件夹 (#1158) - 托盘中的重启现在会同时重启窗口和后台服务 (#1157) - Linux 上短时间内连续出现的图片剪贴板事件，尤其是共享剪贴板工具产生的事件，现在不易生成重复图片条目 (#1154) - 轻量模式现在会更清楚地提示 UniClipboard 仍在后台运行，弱显卡 Windows 设备上的剪贴板和设备页面也应更流畅 (#1149) --- > **Source**: https://www.uniclipboard.app/changelog/0.16.0 > **Locale**: English > **Version**: v0.16.0 > **Released**: 2026-06-22 > **⚠️ Important notice for users on 0.14.0-alpha.9 – 0.14.0**: these versions have a bug that prevents automatic updates from completing. Please open `https://uniclipboard.app/download` in your browser, download the latest installer, and reinstall manually. ## 0.16.0 - 2026-06-22 ### Features - Add Debug mode and one-click log export so troubleshooting information can be collected from Settings or the command line (#1087) - Add official Homebrew cask support for installing and updating UniClipboard on macOS (#1086) - Add package-manager packaging for Chocolatey, winget, Scoop, Flathub, and Nix (#1088) - Add configuration backup and import so you can move an existing UniClipboard setup to another device from Settings or first-run setup (#1118) - Add a Sync on restore option that can make restored history items become the active clipboard on your other devices (#1117) - Add a Network setting for choosing the transfer behavior, with CUBIC recommended for local networks and BBR3 available for long-distance or lossy links (#1121) ### Fixes - Fix Snap packaging so the installed app includes the expected binaries (#1075) - Reduce repeated Linux/X11 image capture loops that could flood clipboard history after copying an image (#1083) - Fix command-line text output so `uniclip get` ends cleanly on a terminal line (#1091) - Fix Linux clipboard image handling to prefer usable image data and avoid selecting unsupported image targets (#1089) - Fix Linux/X11 clipboard reads that could give up before the clipboard owner finished serving the copied content (#1096) - Fix repeated Linux image captures caused by alpha-channel-only differences in shared clipboard images (#1105) - Keep the restart dialog open while Debug mode is applying so users can see that the restart is still in progress (#1102) - Fix macOS clipboard history so copying the same text again can bring that item back to the top (#1112) - Fix file sync identity matching so the same copied file is recognized across devices instead of being repeatedly pulled (#1126) - Show offline peers as unreachable instead of failed when a clipboard item cannot be delivered because the peer is offline (#1131) - Prevent concurrent file transfers from turning cached files into empty files on macOS and Windows (#1132) - Prevent duplicate file entries and duplicate downloads when the same copied file arrives through overlapping sync paths (#1133) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.16.0 > **Locale**: Simplified Chinese > **Version**: v0.16.0 > **Released**: 2026-06-22 > **⚠️ 重要公告（0.14.0-alpha.9 ~ 0.14.0 用户）**：这些版本存在自动更新缺陷，点击安装后无法完成更新。请在浏览器中打开 `https://uniclipboard.app/download`，手动下载最新安装包覆盖安装。 ## 0.16.0 - 2026-06-22 ### Features - 新增 Debug 模式和一键导出日志，可从设置或命令行收集排障信息 (#1087) - 新增官方 Homebrew cask 支持，方便在 macOS 上安装和更新 UniClipboard (#1086) - 新增 Chocolatey、winget、Scoop、Flathub 和 Nix 的包管理器安装支持 (#1088) - 新增配置备份与导入，可从设置或首次启动流程把已有 UniClipboard 配置迁移到另一台设备 (#1118) - 新增“恢复时同步”选项，可在从历史记录恢复内容时把它同步为其他设备的当前剪贴板 (#1117) - 新增网络传输行为设置，局域网推荐使用 CUBIC，也可为远距离或丢包较多的链路选择 BBR3 (#1121) ### Fixes - 修复 Snap 包安装后缺少预期二进制文件的问题 (#1075) - 减少 Linux/X11 复制图片后可能反复捕获、刷屏剪贴板历史的问题 (#1083) - 修复命令行 `uniclip get` 在终端输出文本时不会换到新行的问题 (#1091) - 修复 Linux 剪贴板图片读取会优先选择不可用图片目标的问题 (#1089) - 修复 Linux/X11 剪贴板读取可能在剪贴板所有者尚未完成提供内容前就放弃的问题 (#1096) - 修复 Linux 共享剪贴板图片因仅 alpha 通道变化而被反复捕获的问题 (#1105) - 修复开启 Debug 模式重启时对话框过早关闭、用户看不到仍在重启的问题 (#1102) - 修复 macOS 上再次复制相同文本时，剪贴板历史不会把该项目重新置顶的问题 (#1112) - 修复跨设备文件同步的识别方式，避免同一个复制文件被反复拉取 (#1126) - 当对端离线导致剪贴板条目无法送达时，现在显示为不可达而不是失败 (#1131) - 修复 macOS 和 Windows 上并发文件传输可能把缓存文件变成空文件的问题 (#1132) - 修复同一个复制文件通过重叠同步路径到达时产生重复条目和重复下载的问题 (#1133) --- > **Source**: https://www.uniclipboard.app/changelog/0.15.0 > **Locale**: English > **Version**: v0.15.0 > **Released**: 2026-06-14 > **⚠️ Important notice for users on 0.14.0-alpha.9 – 0.14.0**: these versions have a bug that prevents automatic updates from completing. Please open `https://uniclipboard.app/download` in your browser, download the latest installer, and reinstall manually. ## 0.15.0 - 2026-06-14 ### Features - Add an edit flow for mobile sync devices so you can change a device label, username, or password and scan the refreshed credentials when needed (#1065) - Make mobile sync QR codes include all reachable desktop addresses so phones can connect more reliably across LAN, Tailscale, or a configured public entry (#1026) - Add `uniclip get` to read already-synced clipboard entries from the CLI without waiting for the next incoming item (#1032) - Make the CLI available through npm for easier installation in terminal and scripting workflows (#1028) ### Fixes - Keep long dialogs usable by scrolling the body while the header and footer stay visible (#1067) - Fix Linux synced text so it can be pasted into apps such as Firefox and GTK apps, and avoid paste delays after receiving clipboard updates (#1061) - Prevent the app from getting stuck after an update or restart when the previous background service is still shutting down (#1038, #1063) - Avoid startup hangs on Linux sessions where the system keyring is unavailable or locked (#1058) - Improve Linux X11 clipboard capture so quick or slow clipboard owners no longer cause copied content to be missed (#1054) - Allow headless hosts to start without a system clipboard instead of failing during daemon startup (#1055) - Hide container virtual network interfaces from the mobile sync address picker (#1036) - Allow a device to pair again cleanly when an older stale record still exists (#1033) - Avoid a Wayland rendering crash or blank window caused by the WebKit DMABUF renderer (#1062) - Fix the Windows npm CLI package so nested paths are handled correctly (#1031) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.15.0 > **Locale**: Simplified Chinese > **Version**: v0.15.0 > **Released**: 2026-06-14 > **⚠️ 重要公告（0.14.0-alpha.9 ~ 0.14.0 用户）**：这些版本存在自动更新缺陷，点击安装后无法完成更新。请在浏览器中打开 `https://uniclipboard.app/download`，手动下载最新安装包覆盖安装。 ## 0.15.0 - 2026-06-14 ### Features - 新增移动同步设备编辑流程，可修改设备标签、用户名或密码，并在需要时扫码更新后的凭据 (#1065) - 移动同步二维码现在会包含桌面端所有可访问地址，让手机在局域网、Tailscale 或已配置公网入口下更容易连上 (#1026) - 新增 `uniclip get`，可通过 CLI 直接读取已经同步到历史记录里的剪贴板内容，无需等待下一次传入 (#1032) - CLI 现在可通过 npm 安装，方便终端和脚本场景使用 (#1028) ### Fixes - 较长的对话框现在会滚动正文，同时保持标题栏和底部按钮可见 (#1067) - 修复 Linux 上已同步文本无法粘贴到 Firefox、GTK 等应用的问题，并避免收到剪贴板更新后粘贴卡顿 (#1061) - 修复更新或重启后旧后台服务仍在退出时可能导致应用卡住的问题 (#1038, #1063) - 避免 Linux 会话中系统密钥环不可用或未解锁时导致启动卡住 (#1058) - 改进 Linux X11 剪贴板捕获，快速切换或响应较慢的剪贴板来源不再容易漏同步内容 (#1054) - 无头主机现在可以在没有系统剪贴板的情况下启动，而不是在后台服务启动时失败 (#1055) - 移动同步地址选择器不再显示容器虚拟网卡 (#1036) - 当旧的过期设备记录仍存在时，设备现在可以重新配对成功 (#1033) - 避免 Wayland 下 WebKit DMABUF 渲染器导致崩溃或窗口空白 (#1062) - 修复 Windows npm CLI 包对嵌套路径的处理 (#1031) --- > **Source**: https://www.uniclipboard.app/changelog/0.14.1 > **Locale**: English > **Version**: v0.14.1 > **Released**: 2026-06-10 > **⚠️ Important notice for users on 0.14.0-alpha.9 – 0.14.0**: these versions have a bug that prevents automatic updates from completing. Please open `https://uniclipboard.app/download` in your browser, download the latest installer, and reinstall manually. ## 0.14.1 - 2026-06-10 ### Fixes - Fix the Windows portable build failing to start because its zip was missing the `uniclipd` background service (#1012) - Stop the background service from flashing console windows on Windows while installing updates (#1012) - Stop the upgrade notice from being re-detected on every launch (#1012) - Open manual updates, release-note links, and download buttons in the system browser and point them at the UniClipboard download page, including Windows portable builds that previously attempted an in-app install or did nothing - Fix Windows update installs failing on non-English-language systems after the background service is stopped - Record update download and install outcomes in local logs so failing auto-updates can be diagnosed even with telemetry off (#1012) - Strengthen local connection security so another process on the same computer cannot infer the background service token from repeated failed connection attempts --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.14.1 > **Locale**: Simplified Chinese > **Version**: v0.14.1 > **Released**: 2026-06-10 > **⚠️ 重要公告（0.14.0-alpha.9 ~ 0.14.0 用户）**：这些版本存在自动更新缺陷，点击安装后无法完成更新。请在浏览器中打开 `https://uniclipboard.app/download`，手动下载最新安装包覆盖安装。 ## 0.14.1 - 2026-06-10 ### Fixes - 修复 Windows 便携版因 zip 缺少后台服务 `uniclipd` 而完全无法启动的问题 (#1012) - 修复 Windows 上安装更新时后台服务闪出控制台窗口的问题 (#1012) - 修复每次启动都重复检测到升级提示的问题 (#1012) - 更新窗口中的手动更新、发布说明链接和下载按钮现在统一在系统浏览器中打开并指向 UniClipboard 下载页，Windows 便携版也走此入口，不再尝试应用内安装或无响应 - 修复 Windows 在非英文系统上停止后台服务后安装更新失败的问题 - 更新的下载与安装结果现在会记录到本地日志，即使关闭遥测也能排查自动更新失败的原因 (#1012) - 加强本机连接安全性，避免同一台电脑上的其他进程通过反复失败的连接尝试推断后台服务令牌 --- > **Source**: https://www.uniclipboard.app/changelog/0.14.0 > **Locale**: English > **Version**: v0.14.0 > **Released**: 2026-06-10 ## 0.14.0 - 2026-06-10 ### Breaking Changes - The sync engine now ships as a separate `uniclipd` program: the `uniclip daemon` subcommand is removed and `uniclip start` launches `uniclipd` automatically, so scripts or server setups that invoked `uniclip daemon` directly need updating (#960) ### Features - Clipboard sync now runs as a standalone background service, with a new Lightweight Mode in the tray menu: the app window can fully exit while syncing keeps running in the background, and choosing Quit in the tray stops both the app and the sync service (#960) - The `uniclip` command line now talks to the same background service as the desktop app, so both always see the same clipboard state, and CLI commands work even when the desktop app is not running (#975) - Add a quick panel setting for opening at the screen center or near the cursor, and make filtering from the search bar easier to use by mouse or keyboard (#936) - Add a compact update dialog with options to skip a version, be reminded later, install the update, and toggle future automatic downloads (#992) - Apply network setting changes by restarting the background service while keeping the app window open, with clearer progress and success feedback (#994) - Sending content from mobile that already exists on the desktop now makes it immediately available to paste again (#1003) ### Fixes - Make UniClipboard appear correctly in Linux application menus instead of being hidden or grouped under Other (#934) - Fix the macOS Dock icon so it no longer appears blank, oversized, or surrounded by an unwanted white ring (#935) - Restore the Linux AppImage download for users who install UniClipboard that way (#944) - Prevent repeated image captures from creating duplicate history entries, repeated syncs, or unbounded cache growth (#959) - Load large image previews in history on demand so browsing image-heavy history no longer drives memory usage up (#960) - Restore Snap package availability for Linux users (#968) - Prevent the background service from appearing as a bouncing app icon in the macOS Dock (#969) - Fix mobile sync device removal and password rotation so they no longer fail with a not-found error (#972) - Show an actionable error screen instead of a blank loading screen when the app cannot connect to the background service (#973) - Stop the old background service before installing an update so the installer can replace it cleanly, especially on Windows (#977) - Recover startup when an incompatible background service is running but its process record is missing (#980) - Use a monochrome menu bar icon on macOS so the tray icon matches light and dark menu bar appearances (#974) - Show the saved mobile device name for clipboard items received from a phone instead of a technical device ID (#984) - Restore the normal full-color tray icon on Windows and Linux (#983) - Fix VPS Docker deployments so the headless server can start instead of crash-looping (#986) - Prevent the app from getting stuck on the loading screen after the computer wakes or reconnects, and let users retry without restarting (#999) - Restarting the desktop background service after settings changes no longer leaves clipboard history locked or blocks follow-up actions (#1002) - Prevent iPhone sync from repeatedly pulling the same image or file as new content (#1007) - Show a clear error when the app cannot finish startup instead of leaving setup stuck loading (#1009) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.14.0 > **Locale**: Simplified Chinese > **Version**: v0.14.0 > **Released**: 2026-06-10 ## 0.14.0 - 2026-06-10 ### Breaking Changes - 同步引擎现在作为独立的 `uniclipd` 程序发布：`uniclip daemon` 子命令已移除，`uniclip start` 会自动拉起 `uniclipd`；如有脚本或服务器部署直接调用过 `uniclip daemon`，需要相应更新 (#960) ### Features - 剪贴板同步现在由独立的后台服务承担，并在托盘菜单新增「轻量模式」：应用窗口可以完全退出，同步继续在后台运行；在托盘选择「退出」则会连同后台服务一起停止 (#960) - `uniclip` 命令行改为与桌面应用共用同一个后台服务，两边看到的剪贴板状态始终一致，不打开桌面应用也能直接使用命令行 (#975) - 新增快捷面板展示位置设置，可选择在屏幕中央或鼠标附近打开，并让搜索栏筛选更适合鼠标和键盘操作 (#936) - 新增更紧凑的更新对话框，可跳过某个版本、稍后提醒、安装更新，并可直接切换今后是否自动下载更新 (#992) - 网络设置变更现在会重启后台服务来生效，同时保持应用窗口打开，并提供更清晰的进度和成功反馈 (#994) - 从手机发送桌面端已存在的内容时，现在会让这条内容重新变成可直接粘贴的内容 (#1003) ### Fixes - 修复 UniClipboard 在 Linux 应用菜单中可能被隐藏或归到“其他”分类的问题 (#934) - 修复 macOS Dock 图标空白、过大或带有异常白色圆环的问题 (#935) - 恢复面向通过 AppImage 安装 UniClipboard 的 Linux 用户的下载包 (#944) - 修复重复图片捕获可能造成剪贴板历史重复、反复同步或缓存持续增长的问题 (#959) - 历史记录中的大图预览改为按需加载，浏览大量图片时内存占用不再持续升高 (#960) - 恢复 Linux 用户可用的 Snap 软件包发布 (#968) - 修复后台服务在 macOS Dock 中显示为持续跳动图标的问题 (#969) - 修复移动同步中移除设备和轮换密码会返回未找到错误的问题 (#972) - 当应用无法连接后台服务时，显示可操作的错误页面，而不是停在空白加载界面 (#973) - 安装更新前会先停止旧的后台服务，确保安装器能顺利替换文件，尤其是在 Windows 上 (#977) - 修复已有不兼容后台服务在缺少进程记录时导致应用启动无法恢复的问题 (#980) - macOS 菜单栏图标改为单色样式，使托盘图标能匹配浅色和深色菜单栏外观 (#974) - 从手机接收的剪贴板内容现在会显示已保存的移动设备名称，而不是技术性的设备 ID (#984) - 恢复 Windows 和 Linux 上正常的全彩托盘图标 (#983) - 修复 VPS Docker 部署中无界面服务无法启动、容器反复崩溃的问题 (#986) - 修复电脑唤醒或重新联网后应用可能卡在加载页的问题，并允许用户无需重启即可重试 (#999) - 修改设置后重启桌面后台服务，不会再导致剪贴板历史保持锁定或后续操作被阻止 (#1002) - 修复 iPhone 同步时会把同一张图片或同一个文件反复当作新内容拉取的问题 (#1007) - 当应用无法完成启动时显示清晰错误，不再让设置流程一直停在加载中 (#1009) --- > **Source**: https://www.uniclipboard.app/changelog/0.13.1 > **Locale**: English > **Version**: v0.13.1 > **Released**: 2026-06-05 ## 0.13.1 - 2026-06-04 ### Fixes - Fix excessive disk usage on Linux, where copying a single image could flood the clipboard cache with hundreds of near-duplicate captures, and re-copying existing content now reuses the existing history entry instead of piling up duplicates (#957) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.13.1 > **Locale**: Simplified Chinese > **Version**: v0.13.1 > **Released**: 2026-06-05 ## 0.13.1 - 2026-06-04 ### Fixes - 修复 Linux 上磁盘占用过大的问题：此前复制单张图片可能在剪贴板缓存中产生数百份近似重复的副本；同时，再次复制已有内容现在会复用历史中已存在的条目，而不再堆积重复项 (#957) --- > **Source**: https://www.uniclipboard.app/changelog/0.13.0 > **Locale**: English > **Version**: v0.13.0 > **Released**: 2026-06-01 ## 0.13.0 - 2026-06-01 ### Breaking Changes - Simplified the `uniclip mobile-sync` CLI by replacing the old `devices`, `settings`, and `lan` command groups with task-focused commands, so scripts using the old names need updating (#914) ### Features - Mobile device pairing now opens on a scan-first QR flow, includes app download options, lets you switch the advertised address from the QR screen, and manages each paired device from one dialog (#883) - First-time device pairing can now work on the same local network even when the internet pairing service is unreachable or LAN-only mode is enabled (#896) - The tray menu now includes Check for Updates and Restart actions (#893) - Mobile sync can now advertise a full public URL, making it possible to use a self-hosted server or secure proxy for cross-network phone access (#906) - Advanced users can now run UniClipboard as a headless server node and deploy it on a VPS with the included Docker and Caddy setup (#910) - Invite codes entered through the CLI are now case-insensitive and do not require hyphens (#917) - Windows now offers portable x64 and arm64 downloads, with portable data stored beside the app and guided manual updates (#921) ### Fixes - Fixed Linux keyring failures that could crash or block secure storage on some systems (#882) - Windows no longer crashes when reading rich text copied from some Chinese-language Office or chat apps, and screenshot copying from modern apps is faster (#894) - Update popups now behave as independent native windows instead of being minimized with the main window (#916) - Launch at startup now actually registers with the operating system and repairs stale startup entries after moving or updating the app (#925) - Update popups now come to the front on macOS even when the app was started silently or hidden in the background (#926) - Fixed a Windows startup crash that could happen when the app was launched at login (#929) - Automatic update checks now keep running while the app is idle in the background or resumes from sleep, so new-version prompts no longer wait until the main window is opened (#931) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.13.0 > **Locale**: Simplified Chinese > **Version**: v0.13.0 > **Released**: 2026-06-01 ## 0.13.0 - 2026-06-01 ### Breaking Changes - 简化了 `uniclip mobile-sync` 命令行用法，旧的 `devices`、`settings` 和 `lan` 命令组已替换为按任务组织的新命令，因此使用旧命令的脚本需要更新 (#914) ### Features - 移动设备配对现在默认进入扫码流程，内置客户端下载入口，可在二维码界面切换对外地址，并可在同一个对话框里管理每台已配对设备 (#883) - 首次设备配对现在即使在互联网配对服务不可用或启用 LAN-only 模式时，也可以在同一局域网内完成 (#896) - 托盘菜单新增检查更新和重启入口 (#893) - 移动端同步现在可以对外提供完整公开 URL，便于通过自托管服务器或安全代理实现跨网络手机访问 (#906) - 高级用户现在可以将 UniClipboard 作为无界面的服务器节点运行，并使用内置 Docker 与 Caddy 配置部署到 VPS (#910) - 通过命令行输入的邀请码现在不区分大小写，也不再要求必须带连字符 (#917) - Windows 现在提供 x64 和 arm64 便携版下载，便携版数据会保存在应用旁边，并提供手动更新引导 (#921) ### Fixes - 修复部分 Linux 系统上钥匙串故障可能导致崩溃或安全存储不可用的问题 (#882) - Windows 读取部分中文 Office 或聊天软件复制的富文本时不再崩溃，并提升了从现代应用复制截图的速度 (#894) - 更新弹窗现在是独立的原生窗口，不会再跟随主窗口一起最小化 (#916) - 开机启动开关现在会真正注册到操作系统，并会在应用移动或更新后修复失效的启动项 (#925) - macOS 上即使应用静默启动或隐藏在后台，更新弹窗也能正常显示到前台 (#926) - 修复 Windows 登录后自动启动时可能崩溃的问题 (#929) - 自动检查更新现在会在应用后台空闲或从睡眠恢复后继续运行，新版本提示不再等到打开主窗口后才出现 (#931) --- > **Source**: https://www.uniclipboard.app/changelog/0.12.0 > **Locale**: English > **Version**: v0.12.0 > **Released**: 2026-05-26 ## 0.12.0 - 2026-05-26 ### Features - Show a dedicated in-app update window for new releases, with release notes and install actions that are easier to notice (#854) - Add a two-step mobile pairing flow that first helps users open the mobile app download page, then shows the pairing QR code (#855) - Show incoming file transfers on macOS in a floating progress panel with a cancel button (#848) ### Fixes - Open the update window immediately when a new version is found after returning to the main window, and make that window follow the user's theme (#865) - Preserve cross-platform clipboard content more reliably, including rich text copied on Windows, non-English URLs copied on Linux, and UTF-8 text synced to macOS (#862) - Avoid repeated waits when copying while a paired device is offline (#863) - Recover interrupted space changes during unlock so users do not reopen the app to missing history or an unpaired device (#857) - Improve same-network file transfer stability and reduce copy delays when a paired device silently goes offline (#852) - Ignore empty placeholder files from other clipboard tools so they no longer trigger useless remote file-sync notifications (#849) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.12.0 > **Locale**: Simplified Chinese > **Version**: v0.12.0 > **Released**: 2026-05-26 ## 0.12.0 - 2026-05-26 ### Features - 新版本可用时会显示独立的应用内更新窗口，更醒目地展示更新说明和安装操作 (#854) - 移动端配对改为两步流程，先引导用户打开移动 App 下载页，再显示配对二维码 (#855) - macOS 接收文件时会显示带取消按钮的悬浮进度面板 (#848) ### Fixes - 回到主窗口后若检测到新版本，会立即打开更新窗口，并让该窗口跟随用户的主题设置 (#865) - 提升跨平台剪贴板内容保真度，包括 Windows 富文本、Linux 非英文 URL，以及同步到 macOS 的 UTF-8 文本 (#862) - 复制内容时如果配对设备离线，不再反复等待失败的重连尝试 (#863) - 解锁时会恢复中断的空间变更，避免重新打开应用后出现历史记录缺失或设备未完成配对 (#857) - 提升同一网络内文件传输的稳定性，并减少配对设备静默离线时造成的复制卡顿 (#852) - 忽略其他剪贴板工具产生的空占位文件，避免触发无意义的远端文件同步通知 (#849) --- > **Source**: https://www.uniclipboard.app/changelog/0.11.1 > **Locale**: English > **Version**: v0.11.1 > **Released**: 2026-05-24 ## 0.11.1 - 2026-05-24 ### Features - Show cumulative release notes in the update dialog when upgrading across skipped versions, capped to the most recent 5 versions (#836) ### Fixes - Fix startup failures on Linux KDE/KWallet systems that could leave the app unable to resume a saved session (#841) - Show clearer guidance for used, expired, or rejected invitation codes and ask users to enter a new code instead of retrying the same one (#837) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.11.1 > **Locale**: Simplified Chinese > **Version**: v0.11.1 > **Released**: 2026-05-24 ## 0.11.1 - 2026-05-24 ### Features - 跨多个版本升级时，更新对话框会展示累计发布说明，最多包含最近 5 个版本 (#836) ### Fixes - 修复 Linux KDE/KWallet 环境下应用可能无法启动并恢复已保存会话的问题 (#841) - 邀请码已使用、过期或被拒绝时显示更清楚的提示，并引导用户重新输入新的邀请码 (#837) --- > **Source**: https://www.uniclipboard.app/changelog/0.11.0 > **Locale**: English > **Version**: v0.11.0 > **Released**: 2026-05-24 ## 0.11.0 - 2026-05-24 ### Features - Add a Resend action for local clipboard history items so users can retry delivery to devices that missed an item (#806) - Add custom relay settings with a reachability test for users who run their own relay nodes (#674) - Add background update checks with desktop notifications for new releases and auto-download when enabled (#823) - Improve mobile device setup with a scan-to-add QR code that auto-fills connection details and a separate Shortcut install flow (#811) - Let the Linux quick installer choose better install paths for more distributions, including Snap on Ubuntu 20.04 and COPR on Fedora/RHEL/openSUSE (#793) - Add cancellable file transfers, clearer cancelled states, and CLI commands for sending or receiving files (#833) - Refresh the desktop app icon (#832) ### Fixes - Prevent copied files from Finder from sometimes missing clipboard history (#821) - Send plain text to mobile clients when a clipboard item also contains rich text, instead of exposing raw formatting markup (#808) - Show mobile sync registration and settings errors inside their dialogs so users can fix problems without closing the modal (#792) - Let users discard a newly added mobile device from the credentials dialog without confirming that credentials were saved (#788) - Prevent startup crashes on Linux systems where the system tray dependency is missing or broken (#817) - Keep large file transfer status accurate until the real receive finishes and reduce progress-update slowdowns during big transfers (#833) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.11.0 > **Locale**: Simplified Chinese > **Version**: v0.11.0 > **Released**: 2026-05-24 ## 0.11.0 - 2026-05-24 ### Features - 为本机剪贴板历史增加“重发”操作，用户可以把未送达的内容重新发送给设备 (#806) - 增加自定义中继设置和连通性测试，方便使用自建中继节点的用户确认配置可用 (#674) - 增加后台更新检查，新版本可用时发送桌面通知，并在启用后自动下载 (#823) - 改进移动设备设置流程，新增可自动填入连接信息的扫码添加二维码，并单独提供快捷指令安装流程 (#811) - 改进 Linux 一键安装脚本，让更多发行版自动选择合适安装路径，包括 Ubuntu 20.04 使用 Snap、Fedora/RHEL/openSUSE 使用 COPR (#793) - 增加可取消的文件传输、独立的已取消状态，以及用于发送或接收文件的 CLI 命令 (#833) - 更新桌面应用图标 (#832) ### Fixes - 修复从 Finder 复制文件时偶尔不会出现在剪贴板历史中的问题 (#821) - 修复移动端同步在剪贴板同时包含纯文本和富文本时可能收到原始格式标记的问题 (#808) - 修复移动同步注册和设置错误在弹窗内不可见的问题，用户现在无需关闭弹窗即可看到并修正错误 (#792) - 修复移动设备凭据弹窗的放弃流程，用户可以丢弃刚添加的设备，而不必误确认已保存凭据 (#788) - 修复部分 Linux 系统缺少或损坏系统托盘依赖时应用启动崩溃的问题 (#817) - 修复大文件传输状态可能过早显示完成的问题，并降低大文件传输进度更新造成的卡顿 (#833) --- > **Source**: https://www.uniclipboard.app/changelog/0.10.0 > **Locale**: English > **Version**: v0.10.0 > **Released**: 2026-05-17 ## 0.10.0 - 2026-05-17 ### Features - Add a reset-and-start-over option on the unlock screen for users who forgot their passphrase (#690) - Add background update downloads with clearer sidebar states for available, downloading, and ready-to-install updates (#691) - Turn background update downloads on by default so supported installers can be ready after an update check (#771) - Redesign the Devices page with clearer paired-device and mobile-sync tabs, card grids, and centered settings dialogs (#726) - Show where each clipboard item came from and whether it has synced to paired devices, with live updates in the detail view and quick panel (#732, #736, #746, #749) - Support previewing and syncing large image files copied from Finder without showing Finder thumbnails (#748) - Add one-line install and uninstall commands for Linux and macOS (#750) - Show package-manager upgrade instructions for users who installed the Linux deb or rpm package (#752) - Add a Quick Panel setting so the panel can be turned on or off immediately (#764) - Add one-click copying for the current mobile sync address in the mobile sync settings dialog (#775) - Add a button in General settings to open the app log folder from the file manager (#778) ### Fixes - Improve Windows quick panel paste reliability in apps where the previous input field did not regain focus correctly (#692) - Make the main window feel more native by preventing accidental selection of interface text and hiding the browser-style right-click menu while keeping clipboard content selectable (#700) - Improve pairing reliability when the same device is reachable in multiple ways, preventing later pairing attempts from hanging or timing out after an initial success (#696) - Prevent tooltips from reopening by themselves after returning to the app on Windows (#707) - Allow text in clipboard previews to be selected and copied (#727) - Show a clearer error when copying a file entry whose original source file was moved or deleted (#729) - Remove shortcut settings that looked configurable but had no effect (#730) - Keep the macOS window controls aligned with the custom title bar (#738) - Close the update dialog immediately after choosing to download an update in the background (#743) - Improve the visibility of the update button and device status colors across themes (#766) - Prevent a crash that could happen when synced file history pointed to cache files that were already missing (#767) - Prevent a crash that could happen when receiving an image from another device (#772) - Fix Snap startup issues that could show a localhost connection error or fail when the system keyring is unavailable (#774) - Keep the clipboard selection on the newest item when it becomes first in the list (#777) - Show all available mobile sync addresses when Bind IP is set to Auto, so phone setup no longer depends on guessing the right network address (#783) --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.10.0 > **Locale**: Simplified Chinese > **Version**: v0.10.0 > **Released**: 2026-05-17 ## 0.10.0 - 2026-05-17 ### Features - 在解锁页面新增“重置并重新开始”入口，方便忘记口令的用户重新设置本机 (#690) - 新增后台下载更新能力，并在侧边栏中更清楚地区分可更新、下载中和可安装状态 (#691) - 默认开启后台下载更新，检查到新版本后支持的安装包会提前准备好 (#771) - 重新设计设备页面，提供更清晰的配对设备和移动同步标签页、卡片网格以及居中的设置对话框 (#726) - 在剪贴板条目中显示来源和配对设备同步状态，并在详情视图和快捷面板中实时更新 (#732, #736, #746, #749) - 支持预览和同步从 Finder 复制的大型图片文件，不再显示 Finder 缩略图 (#748) - 为 Linux 和 macOS 增加一行命令安装与卸载方式 (#750) - 对通过 Linux deb 或 rpm 包安装的用户，显示系统包管理器升级指引 (#752) - 新增快捷面板开关，可立即启用或停用快捷面板 (#764) - 在移动端同步设置弹窗中新增当前同步地址的一键复制功能 (#775) - 在通用设置中新增按钮，可直接从文件管理器打开应用日志文件夹 (#778) ### Fixes - 提升 Windows 快捷面板在部分应用中的自动粘贴可靠性，修复返回原输入框后焦点未正确恢复的问题 (#692) - 主窗口更贴近原生应用体验，避免误选界面文字并隐藏浏览器式右键菜单，同时保留剪贴板内容可选中 (#700) - 提升同一设备可通过多种方式连接时的配对可靠性，避免首次成功后后续配对卡住或超时 (#696) - 修复 Windows 上切回应用后工具提示可能自动重新弹出的问题 (#707) - 允许选中并复制剪贴板预览中的文本 (#727) - 当文件条目的原始源文件被移动或删除时，显示更清楚的复制失败提示 (#729) - 移除看起来可配置但实际不生效的快捷键设置 (#730) - 保持 macOS 窗口控制按钮与自定义标题栏对齐 (#738) - 选择后台下载更新后，立即关闭更新对话框 (#743) - 改进不同主题下更新按钮和设备状态颜色的可见性 (#766) - 修复同步的文件历史指向已丢失缓存文件时可能导致应用崩溃的问题 (#767) - 修复从其他设备接收图片时应用可能崩溃的问题 (#772) - 修复 Snap 启动时可能显示 localhost 连接错误，或在系统钥匙串不可用时启动失败的问题 (#774) - 当最新剪贴板内容出现在列表首位时，保持当前选择跟随到该内容 (#777) - 当绑定 IP 设置为自动时，直接显示所有可用的移动同步地址，手机设置时不再需要猜测正确的网络地址 (#783) --- > **Source**: https://www.uniclipboard.app/changelog/0.9.0 > **Locale**: English > **Version**: v0.9.0 > **Released**: 2026-05-14 ## 0.9.0 - 2026-05-14 ### Breaking Changes - Paired desktop devices should be upgraded together because older versions may not receive new clipboard items from devices running 0.9.0. ### Features - Add a plain-text paste shortcut in the quick panel: hold Option/Alt when pressing Enter, clicking an item, or using Command/Ctrl plus a number to paste without formatting. - Expand appearance settings with separate light and dark theme presets, direct Light/Dark/System preview selection, and custom colors for accent, background, foreground, and borders. - Add separate privacy controls for diagnostics and usage analytics. - Improve Android mobile sync compatibility, including clipboard history access and image or file uploads. - Show the active connection address in the paired devices list so it is easier to see how each online device is connected. - Ask for confirmation before switching the update channel to Alpha. ### Fixes - Let users unlock with their space passphrase when automatic unlock cannot recover the saved key. - Make device pairing more reliable on Tailscale and other overlay networks. - Fix a Windows issue where choosing paste as plain text from the quick panel could reopen the panel instead of pasting into the previous app. - Restore the saved interface scale as soon as the app starts, so zoom shortcuts stay in sync after a restart. - Make keyboard shortcut changes take effect immediately after saving, including the global shortcut for opening the quick panel. - Improve Linux responsiveness and layout so the main window and settings page fit the system title bar more cleanly. - Check for updates on the newly selected channel immediately after changing update channels. --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.9.0 > **Locale**: Simplified Chinese > **Version**: v0.9.0 > **Released**: 2026-05-14 ## 0.9.0 - 2026-05-14 ### Breaking Changes - 已配对的桌面设备应一起升级，因为旧版本可能无法接收运行 0.9.0 的设备发送的新剪贴板内容。 ### Features - 快捷面板支持按住 Option/Alt 以纯文本粘贴，适用于回车、点击条目以及 Command/Ctrl 加数字快捷键。 - 外观设置现在可分别配置浅色和深色主题预设，并支持通过浅色、深色、跟随系统预览直接切换，以及自定义强调色、背景色、前景色和边框色。 - 新增单独的诊断数据与使用情况分析隐私开关。 - 改进 Android 移动同步客户端兼容性，包括剪贴板历史访问以及图片或文件上传。 - 已配对设备列表现在会显示当前连接地址，方便确认在线设备的连接方式。 - 切换更新频道到内测版前会先要求确认。 ### Fixes - 当自动解锁无法恢复已保存密钥时，用户现在可以输入空间口令手动解锁。 - 提升在 Tailscale 和其他覆盖网络上的设备配对可靠性。 - 修复 Windows 上从快捷面板选择纯文本粘贴时可能重新打开面板，而不是粘贴到原应用的问题。 - 应用启动时会立即恢复已保存的界面缩放，重启后的缩放快捷键也会保持同步。 - 键盘快捷键保存后会立即生效，包括用于打开快捷面板的全局快捷键。 - 改进 Linux 响应速度和布局，让主窗口与设置页更自然地适配系统标题栏。 - 更改更新频道后，会立即按新选择的频道检查更新。 --- > **Source**: https://www.uniclipboard.app/changelog/0.8.0 > **Locale**: English > **Version**: v0.8.0 > **Released**: 2026-05-11 ## 0.8.0 - 2026-05-11 ### Features - Mobile companion setup can now start from the device panel and continue without opening settings or restarting the app. - Mobile sync enable, disable, and port changes now take effect immediately. - Files and images sent from mobile devices now show clearer receiving progress and completed states. - Clipboard content uploaded from a phone now syncs to all paired desktop devices, including text, images, and files. - Linux clipboard support is more reliable on Wayland and X11, including large clipboard content and rapid clipboard changes. ### Fixes - Pasting invitation codes with a hyphen no longer drops the final character. - Saving automatic history cleanup rules in Storage settings no longer fails. - Mobile sync now reports listener start failures immediately instead of continuing into device setup. - Prevent rapid duplicate clipboard updates from being applied more than once. - Reduce repeated clipboard write failures when another app temporarily blocks clipboard access on Windows. - Larger files uploaded from a phone can now complete instead of failing at the previous size limit. --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.8.0 > **Locale**: Simplified Chinese > **Version**: v0.8.0 > **Released**: 2026-05-11 ## 0.8.0 - 2026-05-11 ### Features - 可以直接从设备面板开始设置移动端同步，不再需要先打开设置或重启应用。 - 移动端同步的启用、停用和端口修改会立即生效。 - 移动端发送文件和图片时，接收进度和完成状态显示得更清楚。 - 手机上传的剪贴板内容现在会继续同步到所有已配对的桌面设备，包括文本、图片和文件。 - Linux 下的剪贴板支持更加可靠，覆盖 Wayland 和 X11，包括大内容和快速连续变化。 ### Fixes - 粘贴带连字符的邀请码时，不会再丢失最后一个字符。 - 存储设置中的自动清理历史规则现在可以正常保存。 - 移动端同步监听启动失败时会立即提示，不再继续进入设备添加流程。 - 避免快速重复同步的剪贴板内容被重复写入。 - 降低 Windows 上其他应用临时占用剪贴板时反复写入失败的问题。 - 手机上传较大文件时不再因为之前的大小限制而失败。 --- > **Source**: https://www.uniclipboard.app/changelog/0.7.0 > **Locale**: English > **Version**: v0.7.0 > **Released**: 2026-05-10 ## 0.7.0 - 2026-05-10 ### Features - New LAN-only Mode in Network settings keeps clipboard sync entirely on the local network. The settings page shows a restart notice and lists exactly what can still reach the internet while it is on, and the system tray reflects whether LAN-only Mode is active. - Device cards now show how each paired device is reachable: directly, relayed, disconnected, or out of reach on the local network when LAN-only Mode is on. - Per-device sync gates: choose whether each paired device sends, receives, and which content types (text, images, files) are allowed. - Mobile sync via iPhone Shortcut over the local network, with QR-code pairing, separate iOS and Android setup instructions, and a credentials view that supports username display and password rotation without removing the device. - History items whose underlying content is gone are now greyed out as unavailable in both the main history and the Quick Panel, with a clear unavailable-content message instead of a generic copy failure. - VPN users can opt in to using virtual network addresses when both devices reach each other through the same virtual network. - Experimental network settings now carry a clear Experimental badge and tooltip. - Linux now ships RPM packages with a Fedora COPR install channel (`dnf install uniclipboard`), plus a strict Snap package that covers older distributions. - Paired desktops return to Online sooner after reconnecting, while unreachable peers are checked less aggressively. ### Fixes - Existing trusted devices are preserved when upgrading from 0.6.x to 0.7.x — pairing carries over without a manual re-pair. - Settings files written by earlier versions no longer prevent the app from starting after an upgrade. - LAN-only Mode now truly keeps already-paired devices on local-network discovery and direct connections instead of still reaching them through public network services. - Search now matches partial terms inside copied addresses and code-style text such as `localhost`, IP addresses, and mixed-case identifiers. - Quick Panel paste on macOS now reliably returns focus to the previous app before pasting the selected item. - Rich text and HTML clipboard history entries restore without falling back to plain text or truncated content. - Reduced repeated macOS Keychain prompts during startup, setup, and unlock. - The macOS Dock icon once again restores the main window after it has been closed to the tray. - The Network settings page keeps restart notices and error messages in sync with the actual saved value. - The telemetry switch now controls all optional diagnostics immediately, without requiring an app restart. - Entering the wrong passphrase while joining a space no longer breaks the existing setup or forces a reset. - Per-device sync switches save instead of reverting, and the per-device send / receive / content-type filters now actually take effect. - Clipboard copies made right after unlocking are no longer missed while peers reconnect. - Large clipboard captures finish saving before being added to history, so they can be reused after a restart instead of producing a generic copy error. - Older broken history items are detected on startup and marked unavailable up front. - Images sent from mobile clients now arrive as images even when the client does not provide a specific image type. - Incoming clipboard items no longer leave a stuck receiving placeholder after the content has arrived. - Window spacing, dialog overlays, and minimum sizes fit better with the redesigned title bar. --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.7.0 > **Locale**: Simplified Chinese > **Version**: v0.7.0 > **Released**: 2026-05-10 ## 0.7.0 - 2026-05-10 ### Features - 网络设置新增「仅局域网」模式，开启后剪贴板同步完全限制在局域网内。设置页带重启提示，并明确列出此模式下仍会访问公网的项；系统托盘也会显示当前是否处于「仅局域网」状态。 - 设备卡片现在会显示每台已配对设备的连接通道：直连、中继、离线，或在仅局域网模式下「超出局域网范围」。 - 每设备同步开关：可以分别选择某台设备是否发送、接收，以及允许哪些内容类型（文本 / 图片 / 文件）。 - 通过 iPhone Shortcut 进行局域网剪贴板同步，支持二维码配对、iOS 与 Android 分别的接入指引，以及无需重新配对即可查看用户名和重置密码的凭据视图。 - 历史中底层内容已丢失的条目会在主列表和快捷面板中置灰为「不可用」，并给出清晰提示，不再表现为通用的复制失败。 - 同时使用 VPN 时，可选择允许使用虚拟网络地址，让两端走同一虚拟网络互通。 - 实验性的网络设置统一带 Experimental 徽章和提示，避免误触。 - Linux 新增 RPM 安装包和 Fedora COPR 渠道（`dnf install uniclipboard`），并补齐 strict Snap 包以覆盖更老的发行版。 - 已配对的桌面端在重连后能更快回到 Online，无法连通的对端也不再被频繁探测。 ### Fixes - 从 0.6.x 升级到 0.7.x 时，原有的已信任设备会被保留，无需重新配对。 - 旧版本写入的设置文件不会再导致升级后启动失败。 - 「仅局域网」模式下，已配对设备会真正限制在局域网发现和直连上，不再绕回公网服务。 - 搜索现在能按前缀命中复制内容中的地址和代码风格文本，比如 `localhost`、IP 地址、混合大小写的标识符。 - macOS 上从快捷面板粘贴时会先稳定切回原应用再粘贴所选条目，避免内容丢失。 - 富文本和 HTML 类型的剪贴板历史能恢复成原本格式，不再降级成纯文本或截断的内容。 - 减少 macOS 启动、初次设置和解锁时重复弹出的 Keychain 授权窗口。 - 主窗口被收到托盘后，点击 macOS Dock 图标能再次唤起主窗口。 - 网络设置页保存后，重启提示与错误信息会和当前实际保存的设置保持一致。 - 遥测开关现在会立即控制所有可选诊断上报，不再需要重启 App。 - 加入空间时输错口令不会再破坏已有 setup，也不会强制重置。 - 每设备同步开关会真正保存而不是回弹；按设备的发送 / 接收 / 内容类型过滤现在能实际生效。 - 解锁 App 后立刻复制的内容不会再因对端正在重连而丢失。 - 较大的剪贴板内容会先完成持久化再加入历史，避免重启后该条目无法再次使用、只能回提通用错误。 - 启动时会检出更早版本遗留的损坏历史条目并直接标记为不可用，避免反复尝试触发通用错误。 - 移动端发来的图片即便没有携带具体图片类型，现在也会以图片形式送达。 - 接收完成后不会再留下卡住的「接收中」占位条目。 - 配合标题栏重设计，整体调整了窗口边距、对话框遮罩和最小窗口尺寸。 --- > **Source**: https://www.uniclipboard.app/changelog/0.6.0 > **Locale**: English > **Version**: v0.6.0 > **Released**: 2026-05-02 ## 0.6.0 - 2026-05-02 ### Breaking Changes - This release rebuilds how devices connect to each other. After upgrading from 0.5.0, existing pairings are invalidated and every device must be paired again before syncing can resume. ### Features - More reliable cross-network sync: connection success rates are noticeably higher across different Wi-Fi networks, home, and office setups, and recovery is faster on flaky or briefly degraded networks. - Instant resume after sleep or network changes: after sleep/wake, switching Wi-Fi, or a brief disconnect, syncing continues without a fresh handshake — no more "I copied something but it took a while to arrive." - Clearer first-run setup: on first launch you can create a new personal space, or join an existing one with an invitation code and passphrase. - Improved Devices page: generate a short-lived invitation code in one click, copy or regenerate it, and see in real time whether the other device joined successfully. - Join another space without losing history: you can join a different space from the Devices page, and your local clipboard history is preserved and migrated. - Better local-network discovery so pairing and transfers are more reliable when devices are on the same Wi-Fi. - Upgrade notice: when upgrading to this version, a dedicated prompt tells you that re-pairing is required, so the upgrade no longer fails silently. - Expanded CLI: new `uniclip init` to create a space, `uniclip invite` to generate an invitation code, `uniclip join` to join a space, `uniclip members` to list paired devices and presence, `uniclip send` / `uniclip watch` to send or observe clipboard content directly from the terminal, `uniclip switch-space` to switch an already-paired device to another space (with local history migrated automatically), and `uniclip upgrade status / ack` to inspect and acknowledge upgrade prompts. The full setup, pairing, and sync flow can now be completed from the terminal without opening the GUI. ### Fixes - Fixed the paired-devices list and count so the current device is no longer counted as a paired device. - Fixed invitation-code entry so pasted codes are accepted even when separators are missing. - Fixed duplicate clipboard-history entries that could appear after receiving content from another device. - Fixed cases where file lists, PNG images, and rich clipboard content could lose formats when written to the system clipboard on Windows or macOS. - Fixed occasional hangs when quitting or restarting the app. - Prevented the add-device dialog from replacing the success state with a new invitation after pairing completes. - Removing a device now fully clears it so it no longer receives sync attempts and can be paired again cleanly. - New installs no longer show an incorrect re-pair prompt after the first setup is completed. - Avoid unusable virtual network addresses so device connections and transfers are less likely to fail on VPN or proxy setups. - Prevent clearing cache on Windows from removing saved setup, settings, and history data. - Keep file and image clipboard history more stable when cached files are deleted or expire. - Resume clipboard sync automatically after the background service restarts. - Show paired devices with their real online state and update offline status sooner while the Devices page is open. - Fix the quick panel opening to a blank window. - Improved overall sync reliability after cold starts, brief device offline periods, and network changes. --- > **Source**: https://www.uniclipboard.app/zh/changelog/0.6.0 > **Locale**: Simplified Chinese > **Version**: v0.6.0 > **Released**: 2026-05-02 ## 0.6.0 - 2026-05-02 ### Breaking Changes - 这一版重做了设备之间的联网方式，从 0.5.0 升级后，原有的设备配对会失效。所有设备都需要重新配对一次，之后即可继续同步。 ### Features - 更稳的跨网同步：在不同 Wi-Fi、家庭和办公室网络之间，设备连接成功率明显提升；网络较差或临时抖动时，恢复也更快。 - 休眠 / 切网后秒同步：电脑睡眠唤醒、切换 Wi-Fi 或断网恢复后，无需重新握手即可继续同步，不会再出现"复制后等很久才到"的情况。 - 更清晰的首次设置：首次启动时，可以创建一个新的"个人空间"，也可以通过邀请码 + 口令加入已有空间。 - 设备页升级：在"设备"页可以一键生成短期邀请码，邀请新设备加入；也可以复制、重新生成邀请码，并实时看到对方加入成功或失败。 - 加入其他空间不丢历史：从"设备"页可以加入其他空间，本地的剪贴板历史会被保留并迁移过去。 - 改进同一局域网内的设备发现，让配对和传输更可靠。 - 升级提醒：升级到本版本时会有专门的提示，告诉你需要重新配对，不会再静默失败。 - 命令行（CLI）增强：新增 `uniclip init` 创建空间、`uniclip invite` 生成邀请码、`uniclip join` 加入空间、`uniclip members` 查看已配对设备和在线状态、`uniclip send` / `uniclip watch` 直接通过命令行发送或监听剪贴板内容、`uniclip switch-space` 在已配对设备上切换到另一个空间（自动迁移本地历史）、`uniclip upgrade status / ack` 查看与确认升级提示。无需打开 GUI，也能在终端完成完整的设置、配对与同步流程。 ### Fixes - 修复"已配对设备"列表和数量会把本机也算进去的问题。 - 修复粘贴不带分隔符的邀请码时识别不出的问题。 - 修复从其他设备接收剪贴板内容后，本地历史可能出现重复记录的问题。 - 修复在 Windows 或 macOS 上写入系统剪贴板时，文件列表、PNG 图片和富文本内容偶尔丢失格式的问题。 - 修复退出或重启 App 时偶尔卡顿不响应的问题。 - 修复添加设备时，配对完成后成功状态被新邀请覆盖的问题。 - 移除设备后现在会完整清理该设备，避免继续尝试同步，并支持之后重新配对。 - 全新安装完成首次设置后，不再错误显示重新配对提示。 - 避开不可用的虚拟网络地址，降低 VPN 或代理环境下设备连接和传输失败的概率。 - 修复 Windows 上清理缓存可能删除已保存的设置、初始化状态和历史记录的问题。 - 提高文件和图片剪贴板历史的稳定性，避免缓存文件被删除或过期后引发异常。 - 修复后台服务重启后剪贴板同步不会自动恢复的问题。 - 修复已配对设备在线状态显示不准确的问题，并在打开设备页面时更快更新离线状态。 - 修复快捷面板打开后显示空白窗口的问题。 - 整体提升了冷启动、设备短暂离线、以及网络变化场景下的同步可靠性。