What Peering's Relay Can and Cannot See
A relay is a server in the middle of your remote desktop session, so the right question is what stops it from looking. The answer is a key it never receives.
What it does
The relay does three jobs. It introduces two devices that cannot reach each other directly, it copies bytes between them when they still cannot, and it sends push notifications on a Mac's behalf, such as "your coding agent needs an answer". It is a small Rust program, and keeping its job small is the design.
What it knows
Being honest about this is part of the point. To do its job the relay sees:
- Device identifiers and the Mac's name, so it can match a phone to a Mac.
- The network address each device connects from, as any server does, and it hands each device the other's so they can try a direct path.
- Which plan is in use and how much relay time has been spent, to enforce the free allowance of 30 minutes a day.
- That a session exists, when it started and how long it lasted.
The privacy policy lists these in full. None of them is the content of your session.
What it cannot see
The picture, the sound, the clipboard, the keystrokes and the pointer are all inside an encrypted channel that ends on your two devices. The relay cannot read them, change them or replay them. Two mechanisms make that true, and neither depends on trusting the relay.
The control channel is TLS between the devices
When a session is relayed, the phone runs a TLS 1.3 handshake with the Mac through the relay. The relay copies the encrypted records without terminating them, so it never holds a session key. Both ends authenticate with the keys they pinned when you paired, so the relay cannot swap itself in without the phone refusing the connection.
The video key never travels through the relay
Video takes a different road, over UDP, so it needs its own key. After the session is ready, the Mac creates 32 random bytes and sends them to the phone inside the TLS stream. The relay carries that stream and cannot open it. Each direction then derives its own key with HKDF-SHA256, and every datagram is sealed with ChaCha20-Poly1305 and a counter.
key = HKDF-SHA256(secret, salt = "pl.dmq.peering.video-datagram", info = direction) datagram = token | counter | ciphertext | tag
The 16 byte token at the front is the only thing the relay reads. It is a routing hint that says which session the datagram belongs to, and the relay removes it before forwarding. Everything after it is ciphertext.
Push notifications and Live Activities
When your phone is asleep, the Mac asks the relay to wake it with an Apple push. What goes in that push is deliberately thin: a short title and message for an alert, and for Live Activity updates only coded state such as ids, states, counts and times. The Mac never sends the relay your screen or your terminal output. For agent approvals, see notifications for coding agents.
Proofs instead of accounts
The free allowance has to attach to something. Instead of an account, devices sign a short message with their own key, and the relay checks the signature within a five minute window. That ties the allowance to a key rather than to a resettable ID, and it lets nobody impersonate a registered Mac without holding its private key.
Check it yourself
The wire format is documented and the relay is built around a constraint: it introduces peers and copies encrypted bytes, and cannot inspect, alter or authorise what it carries. For how a session gets onto the relay in the first place, read how your iPhone reaches your Mac from anywhere, and for how the keys on each end come to be trusted, pairing without an account.
Questions
Can Peering's relay see my screen?
No. The picture is sealed with a key the Mac sends to the phone inside an encrypted connection the relay cannot open, so the relay only ever copies ciphertext.
What does Peering's relay know about me?
Device identifiers, your Mac's name, the plan in use, relay usage and the network address each device connects from. It does not see video, audio, keystrokes or clipboard content.