Only the Macs you approved ever receive anything.

Two Macs on the same desk. Moving a paragraph from one to the other should not involve leaving a third copy with a cloud service somewhere. Supported clipboard content and selected files go directly between approved Macs on a local network both can reach.

The connection runs over local Wi-Fi or Ethernet. Shared content does not pass through a Deskferry developer server, and there is no Deskferry cloud clipboard that devices download from later. The receiving Mac gets the content over its own connection to the sending Mac. In protocol terms, that is peer-to-peer (P2P) LAN transport, with no Deskferry cloud relay in the path.

What that buys you day to day is one less place to keep tidy. Nothing accumulates in a cloud library you have to remember to clear, no uploaded archive to sort through later, no service account to connect before the first copy works. It matters most when the same laptop and desktop hand things back and forth twenty times a day.

Reachability is a real condition and not a formality, so be ready for it to bite. A guest network that isolates its clients blocks the connection outright, even while both Macs display the same Wi-Fi name. Nothing bridges home and the office. Local history on a single Mac is unaffected by any of this.

Work Mac on the company account, personal Mac on yours. There is rarely a good reason to merge those, and connecting two machines should not force you to.

So there is nothing to register and no sign-in step before pairing or syncing. The two Macs can be on entirely different Apple Accounts. Permission comes from an approved device group rather than a shared login: device identity and group-scoped authorization do the job a service account would otherwise do.

In a household or a small team that means you invite one specific Mac. Nobody hands around credentials, personal and work sign-ins stay exactly where they are, and adding a device remains a decision somebody has to actually make.

Apple still handles Mac App Store downloads, purchases and any account requirement attached to them. What Deskferry avoids is a second product account, and it never asks the paired Macs to share one Apple Account.

Being nearby says nothing about whether a Mac should receive your work. Discovery and permission are separate on purpose: turning up on the same Wi-Fi gets a device into no group and earns it nothing.

Pairing runs as a short sequence, so the administrator can look at the device before membership is granted:

1. The administrator starts an invitation from their own group with Add Mac. The six-digit code is valid for 120 seconds and allows three authentication attempts.
2. On the joining Mac, Join a Group selects that nearby invitation and takes the code. The encrypted pairing exchange uses SPAKE2 to verify both sides before the request reaches approval, and binds its result to the secure connection through a TLS exporter, so the short-lived code and the device session that follows belong to the same trust establishment.
3. The administrator checks the joining Mac and approves it. If the code expires or the three attempts run out, the invitation has to be started again.

These checks belong to the moment access is granted. There is no code to retype for each copy — later connections verify the device identity that pairing established. Before the first transfer, select the same current group on both Macs and wait for the connection to be ready.

One part of this is not cryptographic at all: approve only a request you recognise. The code and the encrypted exchange protect the pairing process. Whether this is the device you meant to trust is the question only you can answer.

A Wi-Fi password settles who gets onto the network. It does nothing about the content you then send across it. Both Macs have their identity verified and the connection between them is encrypted, which is what keeps copied text, images and files from being read in transit.

The transport uses TLS 1.3 with mutual authentication (mTLS), so each side proves who it is instead of trusting the network. Events are signed, and replay protection means an old but valid message cannot be accepted again as a new action. The connection also carries its context: it belongs to one approved group, not to whoever happens to be listening.

Retained history has its own protection. Bodies and attachments are encrypted on each Mac, and macOS Keychain holds the key. Index information such as times and status is stored separately, so encrypting the content does not mean that every field in the index is encrypted.

Here is what none of that decides: what a trusted recipient does afterwards. A Mac that received your content can keep it indefinitely, and an unlocked Mac belongs to whoever sits down at it. Picking recipients, and locking the machines themselves, is work that stays with you.

Once more than two Macs are involved, knowing who can receive a copy starts to matter more than how fast it gets there. The current group is the audience — not every nearby Mac, and not every group you have ever joined. Underneath, group-bound v2 frames keep messages in their intended group context, while a signed membership list and signed revocation record who is still authorized. Each Mac then applies its own sync policy on top of that.

The controls split membership decisions away from everyday use:

• Administrators manage membership. Approving a new Mac is theirs, and so is removing a member from a group they own, including a device that happens to be offline at the time. Members cannot remove each other.
• Each Mac controls its own sharing. Which group is current, whether sync is paused, which content types this machine may send — all local decisions. Glance at the group before a copy that matters.
• Personal history stays personal. Being in a group with someone gives them no route into your history library, and that includes the administrator. What a recipient does keep is its own local record of whatever you allowed to sync.

A home group and a work group can sit side by side, and you pick before you share. Switching changes the active audience; having both does not mean every new copy goes to both.

Removing a member revokes future authorized access through that pairing, and stops there. It does not reach back into files, pasted content or history the other Mac already stored. Access control governs who receives the next copy, never what became of the last one.

You paste a password and forget about it. It is now an entry in a list you will scroll past for weeks. A local check for supported sensitive formats exists so that some of those copies never become readable history in the first place.

The rules cover credentials with explicit fields, certain private-key formats and supported recovery phrases, matched by structure rather than by treating every random-looking string as a secret. Recognition is deterministic: it uses the format's own structure, NFKD normalization and checksums where the format defines them, including supported BIP39 and SLIP39 phrases, BIP32, BIP38 and WIF private keys, and PEM or OpenSSH containers. The check runs on your Mac, and the clipboard content is not uploaded for inspection.

When a supported format matches, the whole event is stored as a sensitive placeholder. Its readable body, attachment names and thumbnails are not kept in that entry, so it cannot be opened later to recover the secret.

Now the distinction that actually catches people out: keeping something out of history and keeping it off the network are two different settings. Sensitive-content sync is on by default, and each Mac applies its own settings independently. If private material should not reach the current group at all, turn that setting off or pause sync before you copy it. A placeholder sitting in history is not evidence that nothing was sent.