Syzygy 1.0.0: shipping a local-first clipboard workbench

Syzygy 1.0.0 is our first stable release. From the first line of code in the repository on January 4, 2026 to the version bump from 1.0.0-rc.0 on July 22, there were 1,388 commits; the final window after rc.0 alone added 134. macOS, Windows, and Android have installers ready to download. The iOS build is done and sitting in the App Store review queue. Linux runs in theory; we have not done full compatibility testing on it yet.

What a version number promises comes down to what it puts on the main path. For 1.0.0, that answer is: local clipboard history, multi-format preview and editing, on-demand P2P sync, and encryption with pairing authorization, all completed on a local data plane. The server exists in this architecture, but as an optional sidecar that handles accounts, activation codes, seats, and pair authorization. It never touches the day-to-day sync hot path. When the server is unreachable, copy and paste between paired devices keeps working.

#The first thing that syncs is always the summary

We call the sync model summary-first. When device A copies anything, what crosses the network first is a lightweight summary: content type, preview information, creation time, source device. The record shows up in device B's list almost immediately: searchable, taggable, visibly "something exists here."

When the full body follows is decided by the receiving device's sync mode. Each paired device is configured independently as realtime or on-demand: realtime auto-materializes bodies up to about 50 MiB by default, on-demand up to about 5 MiB. Anything beyond the effective threshold stays pending. You judge from the summary whether it is worth pulling, then download explicitly. All bodies transfer over iroh-blobs by content hash; what gets verified is the hash, not the network path.

The layered model behaves predictably on weak networks and with large files: a phone on cellular receives the summary of a 4K screenshot, the list stays browsable and searchable, and the body waits for Wi-Fi. Offline catch-up is bounded too: a device coming back online pulls the most recent summaries from each trusted peer instead of replaying the entire offline gap, and the foreground catch-up validates a maximum summary count. The July window added several engineering details on top: correlation reuse and health classification for peer catch-up, and counting queued admissions as success so the UI stops thrashing.

#Discovery, encryption, and rotating trust-domain keys

On a LAN, peers find each other through mDNS. Across networks there are two optional routes: PKARR (discovery via DHT and relays) and a relay. The 1.0.0 default ships with the relay off: same-LAN works out of the box, and anyone who needs cross-network sync turns the relay or PKARR on in settings. We write this default down plainly because it is a trade between privacy and reachability, and that trade belongs to the user.

The transport layer is iroh's encrypted, authenticated connection, and pairing responses travel over a channel negotiated with ephemeral keys. With security mode on (security_mode=on), the protection goes two layers deeper: text, image, and file bodies are encrypted before they enter the local blob store, and header announcements upgrade to an encrypted HeaderAnnounceEncryptedV1, sealed with an owner-scoped trust-domain key. Private announcements stop reusing the public topic and move to a separate topic derived from the owner identity, the key epoch, and a local random salt.

The trust-domain key is not static. It rotates on a 6-hour period by default, and trust changes, blocks, device forgets, and neighbor repairs trigger rotation immediately. Key delivery keeps a ledger: a peer counts as converged only after it confirms the key is installed. Offline devices catch up on decryption capability through neighbor repair and periodic maintenance when they return. Clipboard data is highly sensitive, so we chose to make "who can decrypt future announcements" a verifiable key-management problem rather than a toggle plus a promise.

#A workbench where every format gets its own tools

What you can do with an item once it is inside Syzygy is decided by its content plan. The rc window migrated the entire preview system onto this structure: the system generates the text, preview choice, available capabilities, and size evidence from the item's document family, and the UI renders from that instead of guessing from file extensions.

Plain text lands in the text workbench: word count, whitespace cleanup, Base64 encoding and decoding, JSON formatting. Code gets syntax highlighting automatically; Markdown renders live. SVG code and Figma nodes render as real images, so "copy as image" can drop a vector graphic straight into a chat app, while pasting in source mode yields the original SVG. Images ship with built-in OCR, models distributed locally with the installer, no network involved. Office coverage includes content preview for .xlsx, .docx, and .pptx documents plus .zip archives. Remote web images load with a fallback strategy and a no-referrer policy, so remote fetches never leak the referring page.

The entry point for all of this is the Quick Panel: alt+v for the vertical layout, alt+shift+v for horizontal. Each layout persists its own window size, and the runtime clamps windows to the monitor work area, so a panel dragged off-screen can always be recovered. When the main window is focused, alt+v navigates within the page instead of stacking a panel on top of itself. Select an item in the panel and press Shift+↑ for a native-style preview; from there, Popup tears the item out into an independent floating window with adjustable opacity, always-on-top, and resizing; pin a code snippet or screenshot to the front of the screen as a reference.

Global hotkeys cover the full loop: cmdorctrl+shift+c to capture a copy, cmdorctrl+shift+v to paste the latest item, cmdorctrl+shift+k for a quick sync, cmdorctrl+shift+s for an on-demand pull. Every hotkey is remappable in settings; the values live in the hotkeys section of config.json.

#Organization: favorites, pins, tags, and search

History retention defaults to 2,000 items with eviction beyond that, and the trash has its own separate limit. Favorites archive an item permanently. Pins add it to the Pinlist, which stays fixed at the top of the clipboard page and inside the Quick Panel, supports drag reordering, and responds to ctrl+option+0-9 to paste the item in that position. Deletions go to the trash first; space frees up only on permanent removal.

Tags work manually, or via AI auto-tagging. Both AI tagging and AI translation are BYOK: bring your own key and endpoint. Beyond built-in OCR, Syzygy's AI features carry no hidden uploads. Translation ships with multi-engine entry points (Baidu, DeepL, Google, Tencent, Youdao, plus various AI translation endpoints) configured on the plugins page. Search runs on a local index; plain text, OCR text from images, and text extracted from PDFs are all indexed, so "find the screenshot or PDF from last week with that string" is a local query in 1.0.0. Items you want to keep indefinitely can be flagged to stay local, exempt from eviction.

#The CLI is the fourth entrance

Beyond desktop and mobile, 1.0.0 ships a full CLI. The smallest loop through cargo run -p syzygy-cli is a two-node linkup: node A types copy hello-from-a on stdin, node B types paste, and the content is pulled by hash through iroh-blobs. The runner has three forms: stdin simulates triggers to verify the minimal loop, desktop drives the system clipboard and hotkey injection, and script drives automated regression. Subcommands like pair, history, and peers cover pairing and history management, and for debugging cross-network discovery you can write an endpoint address to a file and bootstrap the peer from it. The CLI reuses the same Rust node, pairing, and storage code as the desktop app, which means the core sync logic is exercised every day through two completely different interfaces, and a bug living in that core shows up through both.

#Release engineering and runtime reliability

For a stable release, reliable means more than features. This window laid down the groundwork: the macOS direct-release workflow gained notarization with retry on submission failure, and local-only bundles warn clearly; config files gained a migration and recovery path, so a corrupted config has somewhere to go; clipboard capture runs on a dedicated worker thread with queued processing, so backlog never blocks the UI; logs rotate and clean up by file count; background task status snapshots carry timeout protection, and runtime state supports staleness marks instead of pretending to be fresh. These are not entries on a feature list, but they decide whether Syzygy on four platforms is as reliable on the 500th copy as on the first.

#PRO ships for the first time: codes, seats, and pair authorization

1.0.0 is the first release to carry the PRO entitlement flow. The path: sign in, enter an activation code, confirm the benefits, assign the entitlement seat to a device from the seats table, then refresh the account in the client. The free tier keeps core sync completely free with capacity limits on history count and file preview; PRO removes those limits.

Pairing requires two confirmations: cloud pair authorization must pass, and both devices must complete local trust confirmation. If any step fails, no half-paired state or forced sync results. One thing we say plainly: this flow is the newest part of the release. Payment, activation, seat assignment, and pair authorization form a complete commercial loop for the first time in 1.0.0. It works, but its maturity needs real users to prove, and we expect it to iterate faster than core sync.

#Known edges

• The relay ships off by default; cross-network sync requires enabling relay or PKARR manually.
• iOS is in App Store review; the timeline is not ours to control.
• Linux has not received full official testing; compatibility issues are possible.
• AI auto-tagging consumes a lot of tokens; for now we recommend managing tags manually.
• The clipboard feature itself only graduated from preview to stable during this release window.
• macOS distribution is wired into a notarization workflow with submission retries, the first generation of an ongoing release-engineering effort.

These edges will not all be resolved the same way, but the 1.0.0 principle is to state each one plainly so people use the product with accurate expectations. To get started, read the install and first-run guide. The first round of fixes after 1.0.0 is covered in the 1.0.1 changelog.