Skip to main content
Hayate finds peers on your local network without a central server, a relay, or any manual IP address entry. It runs two discovery channels simultaneously: an mDNS browser/registrar that follows RFC 6762, and a UDP broadcast listener that fires every 800 ms as a fallback. Whichever channel surfaces the matching peer first wins, and Hayate immediately opens a QUIC connection for the actual transfer. The whole process takes well under a second on most home and office networks.

​
How It Works

When you run hayate send with a code phrase, the sender starts advertising itself on both channels at once:
  1. mDNS registration — Hayate creates a _hayate._udp.local. service record. The TXT records carry three fields: the channel ID derived from your code phrase, the sender’s OS name, and the QUIC listener port. Any RFC 6762-compliant mDNS browser on the same subnet will see this record.
  2. UDP broadcast — Simultaneously, Hayate sends a datagram to 255.255.255.255:50002 (and to 127.0.0.1:50002 for loopback testing) every 800 ms. This fast-path reaches devices on networks where multicast is throttled or unreliable.
On the receiver side, hayate receive --code "…" starts a matching browser that listens on both channels. The receiver compares the channel ID from each announcement against the one it computed from your phrase, and connects to the first matching sender it finds. This “hybrid” approach means discovery is resilient: if mDNS is blocked, UDP broadcast takes over; if UDP broadcast is filtered, mDNS succeeds instead.

​
Channel ID Derivation

The code phrase you share is not transmitted in the clear. Hayate computes a channel ID by running the phrase through SHA-256 and hex-encoding the first 4 bytes — producing an 8-character lowercase hex string like e3b0c442. Only this derived ID appears in mDNS TXT records and UDP broadcast packets. Because the channel ID is a one-way hash of the phrase, a passive observer on the network sees an opaque 8-character token and cannot reverse it back to your phrase. A receiver that doesn’t know the phrase will compute a different channel ID and will silently ignore your sender’s announcements entirely.
Discovery announcements are unauthenticated — any host on the LAN can send a spoofed UDP broadcast or fake mDNS response. The channel ID is public. What protects your transfer is the X25519 + passphrase handshake that happens after discovery. Treat discovered addresses as hints; only a peer that can complete the cryptographic handshake has actually proven it knows your phrase.

​
Platform Support

​
The hayate discover Command

You can use Hayate’s discovery engine independently of a transfer to see all active Hayate receivers on your network:
hayate discover scans all detected subnets using up to 128 concurrent QUIC probes, streams results to your terminal as they arrive, and exits after the scan timeout. To prioritise hosts that are likely to be your router or a dedicated server, it probes gateway-adjacent addresses (.1–.3, .253–.254) first before sweeping the rest of the subnet. You can narrow the scan to a specific subnet or extend the timeout:

​
Discovery Timeouts

Both timeouts are configurable with --timeout.
Managed and enterprise networks often block multicast DNS and directed broadcast at the switch or firewall level. If hayate discover returns no results on your network, switch to Direct Mode and supply the receiver’s IP address and port explicitly.