> ## Documentation Index
> Fetch the complete documentation index at: https://hayate.shiina.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic LAN Peer Discovery with mDNS and UDP Broadcast

> Hayate discovers peers automatically on any LAN using RFC 6762 mDNS with UDP broadcast fallback — no IP addresses, no server, no configuration.

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.

<Note>
  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.
</Note>

## Platform Support

| Platform         | mDNS Support | UDP Broadcast | Notes                      |
| ---------------- | ------------ | ------------- | -------------------------- |
| Linux            | Yes          | Yes           | io\_uring async backend    |
| macOS            | Yes          | Yes           | Bonjour-compatible         |
| Windows          | Yes          | Yes           | IOCP async backend         |
| Android (Termux) | Yes          | Yes           | Works on most home routers |

## The `hayate discover` Command

You can use Hayate's discovery engine independently of a transfer to see all active Hayate receivers on your network:

```bash theme={null}
hayate discover
```

`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:

```bash theme={null}
# Scan a specific subnet
hayate discover --cidr 192.168.1.0/24

# Extend the timeout to 30 seconds
hayate discover --timeout 30
```

## Discovery Timeouts

| Context                         | Default timeout |
| ------------------------------- | --------------- |
| Pairing Mode (`hayate receive`) | 60 seconds      |
| `hayate discover` scan          | 15 seconds      |

Both timeouts are configurable with `--timeout`.

<Note>
  **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](/concepts/transfer-modes) and supply the receiver's IP address and port explicitly.
</Note>