airdrop · ⌘D
Developer AirDrop
Move files between machines you own. Encrypted end-to-end. Never touches our servers.
vev drop ./dump.sql prod-db-01That's it. Your laptop opens an X25519 handshake with the host, agrees on a ChaCha20-Poly1305 key, streams the file. LAN hits line rate. WAN hits the limiting pipe. Resumes on disconnect.
from
amir@edge-03
10.0.0.7 · X25519
⇄
to
nova@db-primary
10.0.0.14 · peer
dump-2026-04-19.sql.zst1.2 GB
0%112 MB/s
never touches vev.sh · peer-to-peer · no relay
how the bytes actually travel
- Both machines authenticate to your vev identity (local keypair in ~/.config/vev/identity).
- They exchange ephemeral X25519 public keys. Both sides verify the peer identity signed the ephemeral key.
- They derive a session key via HKDF.
- They stream chunks wrapped in ChaCha20-Poly1305 with a monotonic nonce.
- NAT traversal: WebRTC with our STUN server. No TURN — your bytes do not relay through us.
If both peers are on the same LAN, the STUN step is skipped. If both are on Tailscale, they talk direct.
why this and not scp
- — scp is fine for one file. It does not resume. It does not pipeline. It does not know your fleet.
- — vev drop knows your fleet. You name the destination by its fleet alias, not IP.
- — vev drop resumes. 2GB dump fails at 1.8GB, you retry, it picks up at 1.8GB.
- — vev drop pipelines — chunks in flight while others ack. On a fat LAN, this is the difference between a minute and five.
what we see
Nothing.
Our STUN server sees that two IPs want to talk. It does not see the payload, the filename, the size, the result. It does not log the IPs past 60 seconds.