How it works
Peer-to-peer transfer
Files stream over a WebRTC data channel established directly between the
two browsers, encrypted end-to-end with DTLS and sent in 64 KB chunks
with backpressure. The channel carries one transfer at a time per
direction — additional sends queue automatically — and every
file is SHA-256 hashed before sending and verified on arrival; a
mismatch is discarded, not saved. No relay, no upload — if the two machines can't
reach each other (rare symmetric-NAT pairs), the transfer fails rather than
fall back to a server.
ATProto as the signaling channel
WebRTC needs a way to exchange a few kilobytes of session-setup text
(SDP) before the direct connection exists. Instead of a signaling server,
each side writes a short-lived com.austegard.filedrop.signal
record into its own ATProto repo, addressed to the other's DID, and
reads the peer's repo directly from their PDS. Records are deleted the
moment the connection is up, swept at every sign-in, and ignored after
5 minutes regardless.
Discovery and consent
Because signals live in the sender's repo, the receiving side learns whom
to poll via Constellation, a public index of ATProto backlinks. Peers
you add yourself (typed, or via a shared address link) pair automatically;
anyone else who signals you appears as a request you must accept
before any connection is attempted. A record's authorship is
cryptographically bound to its author's account, so an offer from
alice.example cannot be forged by anyone but Alice's PDS
— and the DTLS fingerprint inside it means the encrypted channel is
authenticated to that same identity.
What is public
ATProto repos are public. While a handshake is in flight (seconds,
bounded by the TTL), the signal records reveal that your account is
connecting to the peer's, and the SDP inside them includes your public IP
address. File names and file bytes never touch ATProto. Sign-in uses an
app password, sent only to your own PDS and held only in
this tab's memory.
Concept credit:
osama2kabdullah/FileDrop ·
full README