Your code never touches our servers
ForkOff uses end-to-end encryption so the relay server only sees opaque encrypted blobs routed between device UUIDs. Your prompts, code, approvals, and file paths are never visible to us.
Data Flow Architecture
The relay forwards encrypted blobs between device UUIDs. It never decrypts, processes, or stores message content.
Cryptographic Layers
Six layers of protection built on proven NaCl primitives. Identical implementations on mobile (React Native) and CLI (Node.js).
X25519 ECDH Key Exchange
Ephemeral Diffie-Hellman key pairs are generated per session. HKDF-SHA256 derives separate send/receive keys from the shared secret.
XSalsa20-Poly1305 Encryption
Every message is encrypted with NaCl secretbox — a misuse-resistant authenticated encryption construction with a 24-byte random nonce.
Ed25519 Identity Signatures
Ephemeral keys are signed with long-term Ed25519 identity keys, preventing man-in-the-middle attacks during key exchange.
TOFU Key Pinning
Trust On First Use — identity keys are pinned on first contact. Any mismatch triggers an explicit warning and blocks the exchange.
Automatic Re-Keying
Sessions expire after 24 hours or 10,000 messages. Expired sessions trigger an automatic fresh key exchange.
Replay Protection
Per-peer monotonic message counters. Every counter is validated as a strictly increasing positive integer within safe bounds.
What the Relay Can See
The API relay is intentionally blind. It routes encrypted blobs between device UUIDs — nothing more.
Visible (routing metadata)
- ●Sender device UUID (opaque)
- ●Recipient device UUID (opaque)
- ●Message counter (integer)
- ●Timestamp
- ●Encrypted blob (ciphertext + nonce)
Hidden (encrypted payload)
- ●Event types (user_message, approval, etc.)
- ●Message content (prompts, code)
- ●Session keys
- ●File paths and directories
- ●Approval decisions
- ●Permission rules
- ●Any payload data
Cryptographic Primitives
| Function | Primitive | Library |
|---|---|---|
| Key Agreement | X25519 ECDH | tweetnacl |
| Key Derivation | HKDF-SHA256 | @noble/hashes |
| Encryption | XSalsa20-Poly1305 | tweetnacl |
| Signatures | Ed25519 | tweetnacl |
| Key Storage | OS Keychain | keytar / expo-secure-store |
Design Decisions
We made deliberate tradeoffs optimized for developer tool sessions, not messaging apps.
Why no Double Ratchet?
Signal's Double Ratchet protocol provides per-message forward secrecy and self-healing after key compromise. ForkOff uses static sessions (one ECDH per connection) because: sessions are short-lived (hours, not months), both peers are always online (no offline message queue needed), 24h/10k message expiry provides forward secrecy boundaries, and ephemeral ECDH per session means compromising long-term keys doesn't reveal past session data. The complexity tradeoff isn't justified for synchronous dev tool sessions.
Why TOFU over PKI?
No certificate authority is needed. Devices pair via QR code with physical proximity, identity keys are pinned on first contact, key mismatch warnings block the exchange, and the target audience (developers) understands key verification.
Why NaCl over Web Crypto?
Using tweetnacl (NaCl) provides identical implementations on React Native and Node.js, a misuse-resistant API with no algorithm negotiation attacks, and well-analyzed constructions (XSalsa20-Poly1305, X25519, Ed25519).
Open Source & Auditable
ForkOff CLI is MIT licensed. The entire E2EE implementation is open source and available for review. Read the full security whitepaper for implementation details.