You copy a short address, a code block, a screenshot, and a PDF during the same hour. The operating system clipboard holds one of them at a time. The rest disappear when you replace them.
Syzygy keeps a local history so those small pieces of work remain available. It gives each item a content type, a preview, and a set of actions that match what the item can actually do. A text item can open in the editor. An image can open in a visual preview. A scanned document can enter OCR before it enters search.
The distinction is practical. You do not need to remember which application produced the item. You can search for it, inspect it, and choose the next action from the same place.
Why we built it
Most clipboard tools start with a list of strings. That model works until the first image, file, or rich document arrives. A screenshot is not a string. An SVG copied from a design tool may contain both a picture and editable source. A folder may arrive as a collection of files with different names and sizes.
We wanted the history to describe those differences instead of hiding them. The item should tell the interface whether it can be searched, previewed, copied, edited, sent to another device, or opened in another application.
That description also gives the user a safe boundary. A pending item can show its title and tags before a large file arrives. The interface can say “download required” instead of offering a copy action that cannot work yet.
Local history first
Syzygy stores the working history on the device that collected it. You can open recent items without waiting for a server. Local search can find a phrase while the network is offline. A saved edit remains available after you close and reopen the application.
This does not make the application disconnected from every service. Accounts, device pairing, optional OCR providers, translation providers, and updates can use a network. Each operation has its own boundary, so you can tell which action needs the network.
The distinction helps during a train ride, a flight, or a service outage. You can keep working with what you already own, then decide what to send when a connection returns.
A history item is more than a preview
An item has a content family, a text representation when one exists, a visual representation when one exists, and actions that match those representations. The preview is a view of the item. It is not a replacement for the item itself.
Copying an SVG can give you a rendered picture and the original SVG source. Copying a PDF can give you a page preview and extracted text. Copying HTML can give you a readable view while preserving the original markup for an explicit source action.
The application keeps those choices visible. You can copy the source when you need exact markup. You can copy a rendered image when you need a visual result. Those two actions should never silently substitute for each other.
The first useful moment
The first screen after launch should answer one question: can you find the thing you need? Syzygy reads the local history and shows recent items without a remote request. The command palette provides another route when your hands are already on the keyboard.
You can search by text, filename, application, tag, or extracted OCR text. You can preview the selected item before sending it anywhere. The next action appears beside the item instead of in a separate settings page.
That sequence reduces the cost of a small task. You do not have to switch applications, open a file browser, and reconstruct which version you copied five minutes ago.
Keyboard-first without keyboard-only
Command + K opens the command palette on supported desktop platforms. The palette keeps the selected item and the current intent together. The first row remembers the last command you used, so a repeated action starts from a known place.
The mouse and touch surfaces remain available. A keyboard shortcut should accelerate an action, not hide it from users who prefer a pointer. Focus returns to the right surface when you close a preview or popup window.
The palette also respects item state. It will not pretend that a remote image is ready for clipboard insertion while the image is still downloading. It will explain the missing step and keep the original selection intact.
Preview before action
Preview is a decision surface. It lets you check a long command, compare an OCR result with its screenshot, or inspect a PDF page before you copy it to another application.
Text previews preserve line breaks. Code previews preserve indentation. Markdown previews render headings, lists, links, and images. SVG previews show the graphic while keeping the source view available.
Unknown binary content receives a safe summary rather than a guessed renderer. The summary can show a filename, size, and detected format. You can then open the file with an external application when that is the right choice.
Popups have a narrow job
A popup window gives a selected item more room without making you lose the main list. It opens with the same item identity and preview plan. Closing it returns you to the previous selection instead of creating a duplicate history item.
The popup does not own the history. It reads the same item state as the main workspace. If a background download finishes, the popup can update its preview. If the content remains pending, the popup shows the action required to materialize it.
Keeping one owner for the item avoids a common class of bugs where the list says “ready” while the popup still shows an older copy.
Tags create a working vocabulary
Tags are small pieces of metadata, but they become useful when a history grows. You can label a screenshot with a project name, mark a command as “support,” or group a set of research notes without moving the underlying content.
The tag record owns its name and color. The list, preview, and tag management surfaces read the saved value rather than deriving a random color for each view. Renaming a tag keeps its identity and color. Removing a tag relationship does not delete the item.
That separation lets you organize a pending file before downloading its body. Metadata can move first, while the larger content stays on the device that owns it.
Trash is a visible state
Trash gives you a review point before permanent deletion. Moving an item to Trash hides it from the active history while keeping a recovery path. Restoring it puts the same item back; it does not create a new copy.
Permanent deletion is a separate action with a separate confirmation. The confirmation states which local data, search result, and synchronized state it will remove. A device revocation is different again: it changes future authorization without silently wiping the local history on another device.
These words are part of the workflow. They help you choose the smallest action that matches your intention.
Search learns from the content
Plain text and Markdown can enter the local index as soon as the item arrives. HTML extraction removes scripts, styles, and hidden transport markup while preserving visible text and meaningful line breaks.
A PDF with a text layer can be searched without OCR. A scanned PDF needs a bounded page render before OCR adds searchable text. A screenshot can enter OCR with a language hint and an image-size limit.
The original item remains the source of truth. Search stores a projection that points back to the history item. If extraction fails, the item remains available and the task can be retried.
OCR should not change the picture
OCR reads pixels and returns text with optional bounding boxes. The screenshot remains unchanged. You can search the words, compare the boxes with the original, and copy the recognized text as a new item when it helps.
The OCR cache includes the content fingerprint, language, provider, engine, image limit, and coordinate version. Changing one of those inputs selects a new result. A cached result never rewrites the original history item.
Text tools produce new snapshots
The text workbench applies named operations such as trimming whitespace, collapsing spaces, sorting lines, formatting JSON, or encoding a URL. It shows the output before you save it.
Saving creates a new history snapshot. The original remains available for comparison. This makes a cleanup reversible and gives search a new item to index. An empty output, invalid encoding, unsupported content, or oversized input produces an explanation instead of a silent replacement.
Translation keeps source and result together
Translation starts with a complete source text and an explicit profile. The profile names the provider and language pair. You can inspect the source before sending it and compare the result when it returns.
For a collection, you select the file to translate. Two files with the same basename remain different items because the collection keeps their occurrence and content identity. The result can become a new snapshot without changing the original file.
AI needs a human decision
AI features can suggest tags, clean text, or produce another transformation when you configure a provider and allow the input. Suggestions remain suggestions until you accept them.
The same validation used by ordinary actions applies to AI output. A suggestion cannot write an invalid tag color, edit a protected item, or save an empty result. The history shows the final action so you can understand what changed.
Pair only the devices you trust
Device pairing is an authorization decision. Both devices show an identity that you can check before accepting. You can give the new device a recognizable name and choose a sync mode.
The network path is a separate fact. A direct session may use a local network or a VPN address. A relay may forward encrypted frames when direct connectivity fails. The path does not decide whether the device is trusted.
Revoking a device removes future access. It does not silently delete the local history that remains on your laptop. Use Trash and permanent deletion when you intend to remove data from that device.
Metadata first, large content later
Syzygy can synchronize a small header before it transfers a large content blob. The header can contain a title, tags, preview information, and size. The receiving device can list and filter the item while the body remains pending.
Realtime mode may materialize small items in the background. On-demand mode waits for a Download action before transferring a large item. Both modes keep the pending state honest until the receiving device verifies the complete content.
This approach protects a phone on a metered plan and keeps a large project from taking over the foreground interface.
Background work should stay in the background
The transfer worker owns long downloads. The command palette, clipboard insertion, and preview actions keep their own lifecycle. Pressing Enter on a ready local item should work while another project continues to download.
The interface reports queued, syncing, pending, ready, and failed states. It can show bytes received and the current rate when the transfer provides those metrics. A spinner alone cannot tell you whether the app is waiting for a peer, writing a file, or retrying a connection.
A route is not a latency number
Network diagnostics separate discovery, route selection, connection reuse, transfer, acknowledgement, and local persistence. A stable 100 ms network round trip can still produce a multi-second sync if the app waits through a failed candidate or retries a handshake in sequence.
The diagnostic view shows the selected route, local and remote addresses, reuse state, queue time, retry count, received bytes, and persistence time. You can copy a summary without including clipboard text or account secrets. Raw addresses are optional for a network administrator.
Recovery is part of the design
Disconnect the network during a large download and the item should remain pending or syncing. It should not become a ready file with missing bytes. Restore connectivity and retry the same intent; the receiver should not create a duplicate history item.
If a route changes from direct to relay, the pairing remains the same. If the peer goes offline, metadata already received should remain useful. Each stage records its own failure so you can decide whether to wait, change networks, download again, or remove the item.
What this blog will cover
Future posts will explain the content types, preview and command palette, tags and Trash, local indexing, OCR and text tools, and P2P pairing in more detail. Each article will start with a user problem and finish with checks you can perform in the application.
The goal is a useful record of how the product behaves. We will call out limits, pending states, and recovery paths alongside the happy path. A feature description that omits its boundary leaves the reader with the hardest part.
A first session
Copy a short note, a code block, an image, and a PDF. Open the history and search for a word from each item. Preview the code, inspect the image, and check whether the PDF has a text layer.
Add a project tag and change its color. Close the application and reopen it. Confirm that the same color appears in the list, preview, and tag page. Move the image to Trash, restore it, and inspect the history identity.
Pair a second device. Let a small note arrive automatically and leave a large archive pending. Download the archive from the receiving device while you use the command palette on a ready local item.
Open network diagnostics after the transfer. Check the selected route and the time spent in the queue, transfer, and local write. That short session tells you more about the workflow than a feature checklist.
A calm default
The default view stays focused on the item you want to use. Network details appear when you ask for them. Long work runs in the background. Destructive actions name their scope. The application keeps the source and the result visible when a tool creates a new item.
Those choices reduce noise without hiding control. You can move quickly during a normal day and still inspect the boundary when a transfer fails, a provider times out, or a device leaves the network.
Syzygy is built around that balance: local work first, explicit sharing, typed content, and a recovery path for every long-running operation.