#port-forwarding #encryption #file-transfer #send #relay #securely #tls #p2p #hole-punching #saved

app gday

Command line tool to securely send files (without a relay or port forwarding)

5 releases (3 breaking)

Uses new Rust 2024

0.4.0 Jun 28, 2025
0.3.0 Dec 2, 2024
0.2.1 Jul 12, 2024
0.2.0 Jul 8, 2024
0.1.1 Jun 7, 2024

#352 in Network programming

Download history 3/week @ 2025-05-07 128/week @ 2025-06-25 9/week @ 2025-07-02

137 downloads per month

MIT license

130KB
2K SLoC

gday

Crates.io Version

Command line tool to securely send files (without a relay or port forwarding).

peer_1: gday send file.mp4 folder
Tell your mate to run "gday get 1.n5xn8.wvqsf".
peer_2: gday get 1.n5xn8.wvqsf
Transfer complete.

asciicast

Installation

To run the executable directly:

  1. Download an executable from releases.
  2. Extract it (on Linux: tar xf <file>).
  3. Run it: ./gday

To install with cargo:

cargo install gday

To install with brew:

brew install manforowicz/tap/gday

Features

  • No limit on the size of files and folders sent.

  • Files are sent directly, without relay servers.

    • A server is only used to exchange socket addresses at the beginning. Then, a peer-to-peer connection is established with TCP Hole Punching. This may not work through some restrictive NATs. If that happens, enable IPv6, move to a different network, or use a tool with a relay server such as magic-wormhole or croc.
  • Automatically resumes interrupted transfers. Just gday send the same files, and partial downloads will be detected and resumed.

    • This is implemented by having the receiver identify when an offered file metadata (name and last modified time) exactly matches metadata saved in a local temporary file.
  • If a contact exchange server is down, just uses a different one from the default list. Or specify your own with --server.

  • Server connection encrypted with TLS and file transfer is over TCP that's end-to-end encrypted with ChaCha20Poly1305.

    • (not TLS for file transfer, because the rustls library doesn't support PSK which is needed for the certificate-less peer-to-peer connection).
  • Automatically tries both IPv4 and IPv6.

    • When IPv6 is available, peer-to-peer connection almost always succeeds because NATs are uncommon on IPv6.
  • Authenticates your peer using SPAKE2 to derive an encryption key from a shared secret.

  • No unsafe Rust in this repository.

Usage

Usage: gday [OPTIONS] <COMMAND>

Commands:
  send  Send files and/or directories
  get   Receive files
  help  Print this message or the help of the given subcommand(s)

Options:
  -s, --server <SERVER>        Use a custom gday server with this domain name
  -p, --port <PORT>            Connect to a custom server port
  -u, --unencrypted            Connect to server with TCP instead of TLS
  -v, --verbosity <VERBOSITY>  Verbosity. (trace, debug, info, warn, error) [default: warn]
  -h, --help                   Print help
  -V, --version                Print version

Similar Projects

No relays Works beyond LAN Works through very strict NATs No port forwarding Encrypted Can resume interrupted transfers
gday
magic-wormhole
croc
p2pcopy
qft
iwant
zget
sharedrop
filepizza
Personal SSH or HTTPS
Personal FTP
Dropbox, Google Drive, etc.
Delivering a USB drive

Open an issue to add more projects to this list.

Technical Overview

  1. Peer A randomly generates a "room code" and a "shared secret".

  2. Peer A randomly selects a gday server ID and connects to it over TLS.

  3. Peer A sends its room code, local IP addresses, and port numbers to the gday server.

  4. Peer A combines the server's ID, room code, and shared secret into a code of form "1.n5xn8.wvqsf" and gives it to Peer B.

  5. Peer A tells this code to Peer B, possibly via phone call or text message.

  6. Peer B also sends this room code and its local IP addresses and port numbers to the gday server.

  7. The gday server sends both peers the public and local IP addresses and ports of the other peer.

  8. From the same local port that they used to connect to the server, each peer tries a few times to connect over TCP to both the local and public socket addresses of the other peer. This may fail on networks with strict NATs.

  9. Once any of the connection attempts succeeds, they use password-authenticated key exchange to derive a strong shared key from their shared secret, and use it to encrypt their TCP connection with chacha20poly1305.

  10. Peer A sends Peer B a list of offered files and their sizes.

  11. Peer B detects interrupted downloads by checking if any offered file's metadata (name and last modified time) exactly matches metadata saved in a local temporary file leftover from the interrupted download.

  12. Peer B sends Peer A the file portions it would like to receive

  13. Peer A sends all the accepted files to Peer B, back-to-back.

Dependencies

~18–30MB
~528K SLoC