How a clip actually gets from one device to another
The short version lives on the security page. This is the long one: which keys exist, where they are made, what the pairing handshake proves, and precisely what our relay server can and cannot do.
Two keys, both born on your hardware
Neither is ever uploaded, escrowed, or derived from anything we hold.
Every device generates an Ed25519 identity keypair on first run and keeps the private half in the platform secure store: Keychain on macOS and iOS, Credential Manager on Windows, the system keyring on Linux, Keystore on Android. The relay knows your devices by that public key, not by an account.
Separately, each library has one 256-bit library key. It is created locally the first time you launch Clypy, before any pairing, so your history is encrypted at rest from the very first clip. When you pair a second device, this is the key that gets handed over, and it is the only thing that can decrypt your clips.
A 6-digit PIN that never crosses the wire
The one moment a key moves between devices, and the part worth reading closely.
Adding a device shows you an 8-character session code and a 6-digit PIN, and a QR code carries both. Pairing uses CPace, a password-authenticated key exchange, implemented to the CFRG draft's ristretto255 and SHA-512 ciphersuite and checked against its published test vectors.
Both devices use the PIN to derive the same session key without ever sending it. Anyone sitting on the relay sees only public curve points, so there is nothing to take away and grind offline. Every guess costs one live interaction against a mailbox that expires in ten minutes and dies after five wrong PINs.
Once that session exists, the established device transfers the library key over it. Both devices also record each other's identity public key, so later sync messages are authenticated and an unrecognized device is rejected outright.
On the same Wi-Fi, the server is not involved at all
The common case never leaves your building.
Paired devices advertise themselves over mDNS on the _clypy-sync._tcp.local. service type and connect to each other directly over TCP. The advertisement carries a discovery tag, an HMAC keyed by your library key, so your devices recognize their own group without publishing anything that identifies you. Someone sniffing the network sees an opaque tag and a stream of ciphertext.
Deltas are encrypted before they are handed to the transport, so this path is protected by exactly the same key as the relay path. The only difference is how many hops the bytes take.
Google Drive and iCloud are a parachute, not a pipe
The most common misunderstanding about how this works.
A backup is a single encrypted archive of your library, written to storage you control. It exists for device loss, a reinstall, or moving to a new machine. It is not a channel your devices read from, and no device ever picks up a clip from your Drive or iCloud account.
The archive is encrypted before it leaves the device, so your cloud provider holds a blob it cannot open. Restoring it needs your key material, which is why an exported backup is only as recoverable as the key you keep with it.
The clips that should never travel, and do not
Handled before storage, not after.
Copies from known password managers, and anything the operating system marks as concealed or transient, are dropped before they are written. They are never stored, never indexed, and never synced.
Content that looks like a secret on its own, such as API tokens, JWTs, credentials, and card numbers, is captured but concealed: no preview, no title, hidden in the list. Revealing it requires Touch ID on macOS, Windows Hello on Windows, or your system authentication prompt on Linux. Those clips also stay on the device that captured them and are kept out of sync entirely.
On top of that automatic behaviour you can mark any clip local-only, give it an expiry, or add your own apps, domains, and text patterns to the ignore list.
What an attacker actually gets
Stated as outcomes rather than adjectives.
Questions people ask before buying
Can Clypy sync through Google Drive or iCloud instead of a server?
No. Google Drive and iCloud are backup destinations only: an encrypted snapshot of your library that you restore from later. Sync happens directly between your devices on the local network, or through Clypy's relay when they are on different networks.
What can the relay server see?
Encrypted bytes and routing metadata: a device's public key, an opaque group tag, the platform name you gave the device, its IP address, and the size and timing of frames. It holds no keys, so it cannot decrypt clip contents, previews, titles, or file names.
Does the relay store my clipboard history?
No. There is no database. The relay forwards a frame to the other devices that are online in your group at that moment and keeps nothing afterwards. The undelivered copy lives in the sending device's own local outbox until a peer confirms receipt.
What happens if my other device is offline?
Nothing queues on the server. The clip waits in the sending device's local outbox and goes out the next time both devices are online at the same time.
Can someone who guesses my pairing code join my devices?
They would need both halves within ten minutes: the 8-character session code, which carries about 40 bits of entropy, and the 6-digit PIN. The PIN is never transmitted, only proved through CPace, so it cannot be brute-forced offline. Five wrong PINs burn the session permanently.
Do I need a Clypy account?
No. There is no Clypy profile and no password to steal. Devices are known to the relay by their own public keys, and a purchase creates only a license and receipt record with the payment provider.
Still unclear on something, or think we have a detail wrong? Say so on the help page and we will either fix the implementation or fix this page.