# SPT Networked Messaging: Research Brief
**Sentience Pocket Transacter — Cross-Host Agent Messaging**
*Rust single-binary constraint · No central operator · No credentials · LAN + WAN*

***

## 1. Executive Shortlist

Candidates are ranked by fit against the seven hard requirements (no central server, no credentials, minimal setup, free, single static binary, cross-platform, backward-compatible surface).

### Rank 1 — **Iroh** (`iroh` / `n0-computer`)

Iroh is a QUIC-based P2P library that dials peers by Ed25519 public key and builds connections using a relay-assisted hole punch that falls back to encrypted relay. Roughly 9 out of 10 connection attempts go direct; the relay is only a temporary stepping stone and never sees plaintext. The default relays are operated by n0.computer, free to use, but the relay binary is open source and trivially self-hosted — making the architecture genuinely multi-operator in practice. It links against tokio (already ubiquitous in Rust async work), builds to a single static binary, ships prebuilt for Linux/macOS/Windows, and includes a `discovery-local-network` feature flag for LAN-first discovery. The compiled crate size is noted as ~43–93 MB before LTO/stripping, which is large but manageable with standard profile tuning. Identity is purely a keypair generated at startup — no registration required. `libp2p-iroh` (0.1.x) further bridges iroh's transport into the libp2p swarm if gossipsub or Kademlia are later needed. **Fit: passes all 7 hard requirements.** Key tradeoff: relays are n0.computer-operated by default, creating a soft trust dependency until users self-host or the network diversifies.[^1][^2][^3][^4][^5][^6][^7][^8][^9]

### Rank 2 — **rust-libp2p** with DCUtR + Kademlia

The rust-libp2p stack is modular: pick TCP/QUIC transport, add the DCUtR hole-punching protocol for NAT traversal via relay, layer Kademlia DHT for peer discovery, and gossipsub for pub/sub messaging. DCUtR achieves ~60% direct-connection success on tested NATs; QUIC hole punching support was merged in 2023. Bootstrap nodes are Protocol Labs-operated (`bootstrap.libp2p.io`), hardcoded in the binary, but the list is fully configurable and can be replaced with user-operated nodes. The library is MIT/Apache-2, actively maintained, and used in production by Ethereum, Filecoin, and IPFS. Binary size impact is significant (examples run 2–5 MB stripped) but feature-flags can shrink this. **Fit: passes all 7 hard requirements with configuration.** Key tradeoff: higher learning curve than iroh; bootstrapping involves soft reliance on Protocol Labs infrastructure by default.[^10][^11][^12][^13][^14][^15][^16]

### Rank 3 — **Iroh + mdns-sd (hybrid LAN/WAN)**

The practical minimum-surprise architecture is: `mdns-sd` crate for zero-config LAN discovery (mDNS/DNS-SD per RFC 6762/6763)[^17][^18], then iroh for WAN connectivity when peers are not on the same link. This mirrors how Syncthing combines UDP broadcast local discovery with a global discovery server[^19][^20]. The two layers are additive: SPT tries mDNS first, falls back to iroh. This pattern requires no changes to the backward-compatible `$OWL deliver|ring|send|reply` surface. **Fit: passes all 7 hard requirements. Recommended architecture for prototype.**

### Rank 4 — **Veilid** (`veilid-core`)

Veilid (Cult of the Dead Cow, 2023) is a Rust-native P2P framework with a fully distributed DHT, onion-routing-style privacy, and an identity model based purely on 256-bit public keys. No nodes are special; any node can bootstrap a network; DNS is used only once and is not required thereafter. veilid-core supports tokio by default and can switch to async-std. Licensed MPL-2.0. **Fit: passes all 7 hard requirements.** Key tradeoffs: the network routes all data through multiple hops by design (Tor-inspired), adding ~100–300 ms latency vs. direct; every node contributes relay bandwidth (~5 GB/month at idle); message payloads are capped at 64 KB per RPC frame. Best fit if anonymity matters more than latency.[^21][^22][^23][^24][^25][^26][^27]

### Rank 5 — **Mainline DHT + Magic Wormhole pairing (rendezvous only)**

BitTorrent's Mainline DHT (Kademlia-based, ~20 M nodes, no single operator) can serve as a pure key-value rendezvous layer: a peer announces its iroh or raw QUIC endpoint under its public-key hash, the other peer looks it up, and then a direct connection is made. Magic Wormhole (`magic-wormhole.rs` crate) provides the initial SPAKE2-based short-code pairing ceremony for trust establishment, after which peers can exchange raw public keys out-of-band. This combination avoids operating any rendezvous infrastructure: DHT is the global yellow pages, Wormhole is the first-contact handshake. **Fit: passes all 7 hard requirements.** Key tradeoff: Mainline DHT stores values for only ~30 minutes, requiring periodic re-announcement; more moving parts than iroh alone.[^28][^29][^30][^31][^32]

***

## 2. Per-Target Findings

### 2.1 LAN Discovery & Messaging

| Name | Primary URL | License | Last Release | Rust Support | Fits Hard Reqs | Key Tradeoff |
|---|---|---|---|---|---|---|
| mDNS / DNS-SD (RFC 6762 / RFC 6763) | https://datatracker.ietf.org/doc/rfc6762/ | IETF Standard | Feb 2013 | `mdns-sd` (pure Rust), `simple-mdns` | ✅ Y | Windows mDNS works but `mdns-sd` must open a UDP socket on port 5353; Windows Defender may prompt on first use[^17][^18] |
| mdns-sd crate | https://crates.io/crates/mdns-sd | Apache-2.0 | Active 2024–2025 | Native | ✅ Y | Spawns a background thread, not tokio-native; wrap in `spawn_blocking` |
| Syncthing Local Discovery v4 | https://docs.syncthing.net/specs/localdisco-v4 | MPL-2.0 spec | Active | Implementable | ✅ Y | Uses UDP broadcast (IPv4 255.255.255.255:21027) + IPv6 multicast; device ID = SHA-256 of X.509 cert[^19][^33] |
| SSDP / UPnP Discovery | https://datatracker.ietf.org/doc/html/draft-cai-ssdp-v1 | Vendor spec | — | `rupnp` crate | ⚠️ Partial | Router-specific; widely deployed but not all devices respond; overkill vs. mDNS for service discovery |
| LLMNR (RFC 4795) | https://datatracker.ietf.org/doc/html/rfc4795 | IETF Informational | 2007 | No dedicated crate | ⚠️ Partial | Windows-only by common deployment; DNS hostname resolution only, not service discovery |
| Magic Wormhole (LAN pairing) | https://github.com/magic-wormhole/magic-wormhole.rs | MIT | Active | `magic-wormhole` crate | ✅ Y | SPAKE2 short-code ceremony; requires mailbox server for initial handshake only; direct P2P afterwards[^34][^29] |

**arxiv citation:** Bryan Ford, Pyda Srisuresh, Dan Kegel. "Peer-to-Peer Communication Across Network Address Translators." *USENIX Annual Technical Conference 2005*. arXiv:cs/0603074. https://arxiv.org/abs/cs/0603074[^35][^36]

***

### 2.2 NAT Traversal & WAN P2P Transport

| Name | Primary URL | License | Last Release | Rust Support | Fits Hard Reqs | Key Tradeoff |
|---|---|---|---|---|---|---|
| STUN (RFC 8489) | https://datatracker.ietf.org/doc/html/rfc8489 | IETF Standard | Mar 2020 | `stun` crate | ✅ Y | Free public STUN at `stun.l.google.com:19302`, `stun.cloudflare.com`; only discovers public IP/port, no relay |
| TURN (RFC 8656) | https://datatracker.ietf.org/doc/html/rfc8656 | IETF Standard | Feb 2020 | `turn` crate | ⚠️ Partial | Relays all media — expensive bandwidth; free public TURN (OpenRelay Project, 20 GB/month) limited for production[^37][^38] |
| ICE (RFC 8445) | https://datatracker.ietf.org/doc/html/rfc8445 | IETF Standard | July 2018 | Via `str0m`, WebRTC libs | ✅ Y | Full STUN+TURN candidate gathering; TURN only needed for symmetric NAT[^39][^40] |
| UDP Hole Punching | https://bford.info/pub/net/p2pnat/ | — | 2005 | Quinn + manual | ✅ Y | ~82% UDP success rate on tested NATs; fails on symmetric NAT[^35][^36] |
| Quinn (QUIC) | https://github.com/quinn-rs/quinn | MIT/Apache-2.0 | Active (0-RTT, 2025) | Native (tokio) | ✅ Y | Pure-Rust QUIC; supports simultaneous-open hole punching; tested on Linux/macOS/Windows[^41][^42] |
| QUIC hole punching | arXiv:2408.01791 | — | Aug 2024 | Via quinn + iroh | ✅ Y | QUIC-based HP reduces punching time vs TCP; connection migration restores sessions after NAT timeout saving 2 RTTs[^43] |
| NAT-PMP / PCP | RFC 6887 | IETF Standard | 2013 | `nat-pmp` crate | ⚠️ Partial | Apple/Linksys routers; not universal; avoids UPnP but same coverage problem |
| WebRTC data channels | https://github.com/webrtc-rs/webrtc | MIT/Apache-2.0 | Active 2024 | `webrtc-rs`, `str0m` | ⚠️ Partial | Headless use possible; large dependency tree; `str0m` is lighter; not worth it when QUIC is available directly |

**arxiv citation:** Jinyu Liang et al. "Implementing NAT Hole Punching with QUIC." *VTC2024-Fall*. arXiv:2408.01791. https://arxiv.org/abs/2408.01791[^43]

***

### 2.3 Decentralized P2P Networking Frameworks

| Name | Primary URL | License | Last Release | Rust Binding Quality | No Daemon | Relay Operator | NAT Traversal | Message Limit | Fits Hard Reqs |
|---|---|---|---|---|---|---|---|---|---|
| rust-libp2p | https://github.com/libp2p/rust-libp2p | MIT/Apache-2.0 | Aug 2024 (0.54) | Native — the library IS Rust | ✅ Y | Protocol Labs (configurable) | DCUtR + QUIC HP (~60% direct)[^11][^12] | Stream-based, no limit | ✅ Y |
| Iroh | https://github.com/n0-computer/iroh | MIT/Apache-2.0 | Active May 2026 | Native — library-first | ✅ Y | n0.computer (self-hostable)[^3][^4] | QUIC HP + relay fallback (~90% direct)[^5] | Stream-based, no limit | ✅ Y |
| libp2p-iroh | https://lib.rs/crates/libp2p-iroh | MIT/Apache-2.0 | 2025 | Native bridge | ✅ Y | Inherits iroh relays | Inherits iroh HP | Inherits libp2p | ✅ Y |
| Veilid | https://gitlab.com/veilid/veilid | MPL-2.0 | Aug 2025 (0.4.8) | Native (veilid-core crate)[^24] | ✅ Y | Fully distributed — all nodes relay[^26][^44] | Onion + UDP/TCP | 64 KB/RPC frame[^26] | ✅ Y |
| Hyperswarm / Hypercore | https://github.com/hypercore-protocol/hypercore | MIT | JS-first | No stable Rust crate (hypercore-rs is prototype) | — | — | — | — | ❌ N (no production Rust) |
| GNUnet | https://gnunet.org | AGPL-3.0 | 2024 | C library; thin Rust bindings only (`gnunet-sys`) | ❌ Requires daemon | Volunteer nodes | Limited | — | ❌ N (daemon + AGPL) |
| Yggdrasil | https://yggdrasil-network.github.io | LGPL-3.0 | Active (Go) | Go only (no Rust crate) | ❌ Requires daemon | Manual public peers[^45][^46] | Peer-to-peer IPv6 | IPv6 only | ❌ N (no Rust, daemon) |
| cjdns | https://github.com/cjdelisle/cjdns | GPL-3.0 | Sporadic | C only | ❌ Requires daemon | Manual bootstrap | Via IPv6 mesh | — | ❌ N (no Rust, daemon) |
| Earendil | https://earendil.network | MIT | Early alpha 2024 | Partial Rust impl | ✅ Y | Relay graph | Relay-based | — | ⚠️ Too immature |

**Bootstrap / centralization note (libp2p):** The IPFS public bootstrap nodes (`/dnsaddr/bootstrap.libp2p.io/...`) are operated by Protocol Labs and hardcoded in the Kubo binary. For a private SPT network, these MUST be replaced with user-operated bootstrap peers, or a custom DHT namespace must be used. This is supported and documented — it is a configuration choice, not an architectural lock-in. One of the four IPFS bootstrap nodes now runs `rust-libp2p-server`, demonstrating production readiness.[^13][^16]

***

### 2.4 Decentralized Identity / Zero-Credential Pairing

| Name | Primary URL | License | Last Release | Rust Support | Fits Hard Reqs | Key Tradeoff |
|---|---|---|---|---|---|---|
| Noise Protocol Framework | https://noiseprotocol.org/noise.html | Public Domain spec | Rev 34 (current) | `snow` (MIT, active 2024–2025)[^47], `noise-rust` (Unlicense)[^48] | ✅ Y | Mutual auth without PKI; used in WireGuard and WhatsApp[^49]; `snow` supports `no_std` |
| Magic Wormhole (SPAKE2) | https://github.com/magic-wormhole/magic-wormhole.rs | MIT | Active | `magic-wormhole` crate | ✅ Y | Short human-typeable code; PAKE ceremony; relay server needed for rendezvous only[^34][^28][^29] |
| SSB / Scuttlebutt identity | https://ssbc.github.io/ssb-db/ | AGPL-3.0 | Active | JS-first; `ssb-db2` in JS | ⚠️ Partial | ed25519 pubkey as identity; no global registry[^50][^51] |
| Syncthing device IDs | https://docs.syncthing.net/dev/device-ids.html | MPL-2.0 | Active | Implementable pattern | ✅ Y | SHA-256 of self-signed X.509 cert; trust-on-first-use; proven in production[^19][^33] |
| Briar contact model | https://briarproject.org | GPL-3.0 | Active | Android/Java | ⚠️ Reference | QR/link exchange; direct pubkey swap; no account[^52][^53] |
| W3C DIDs (`did:key`) | https://w3c-ccg.github.io/did-key-spec/ | W3C CG | 2025 draft | `did` crate | ⚠️ Overkill | Encoding a pubkey as a URI; useful if you ever need cross-ecosystem interop, but heavy for SPT |
| SSH-style TOFU | N/A (pattern) | — | — | Trivial to implement | ✅ Y | Accept on first connection, record fingerprint, warn on change; lowest friction |

**Recommended pairing UX:** Generate an Ed25519 keypair on first run → derive the SPT node ID as the hex/base58 of the public key → for initial peer introduction, print a Magic Wormhole-style code via `$OWL pair` → complete SPAKE2 exchange → store the peer's pubkey in the local trust store. Subsequent connections authenticate by public key (Noise XX or IK pattern). No account, no server.

***

### 2.5 Free Relay / Rendezvous Infrastructure (Not Single-Operator)

| Name | Primary URL | License | Rust Crate | Account Required | Latency Reality | Rate Limits | Fits Hard Reqs |
|---|---|---|---|---|---|---|---|
| Nostr (DM events as signaling) | https://github.com/nostr-protocol/nostr | Public Domain spec | `nostr-sdk` (MIT)[^54][^55] | ❌ No (pubkey = identity) | 200–500 ms typical | Relay-specific; many free relays | ✅ Y — DM (kind 4/NIP-44) usable for signaling; SPT messages as ephemeral events |
| BitTorrent Mainline DHT | https://en.wikipedia.org/wiki/Mainline_DHT | BEP 5 spec | `mainline` crate (MIT)[^32] | ❌ No | ~1–5 s for lookup | None for read; short TTL (~30 min) | ✅ Y — rendezvous only |
| Iroh public relays | https://docs.iroh.computer/concepts/relays | MIT | Built into `iroh` | ❌ No | <50 ms | Rate-limited[^4][^5] | ✅ Y — with self-hosting path |
| IPFS Pubsub / Gossipsub | https://libp2p.io | MIT | `rust-libp2p` | ❌ No | Variable | Network-dependent | ✅ Y — requires bootstrap nodes |
| Arti / Tor hidden services | https://gitlab.torproject.org/tpo/core/arti | MIT/Apache-2.0 | `arti-client`, `tor-hsservice`[^56][^57] | ❌ No | 300–1000 ms | Tor network limits | ✅ Y — but latency cost; anonymity benefit |
| Matrix (guest access) | https://matrix.org | Apache-2.0 | `matrix-sdk` | ❌ Guest OK | ~200 ms | matrix.org rate-limited | ⚠️ Partial — guest accounts quasi-violate "no credentials" |
| Nostr public relays list | https://nostr.watch | — | — | ❌ No | — | Variable | ✅ Y — multiple operators |
| DNS-based rendezvous | Cloudflare Workers / free DNS TXT | — | `hickory-dns` | ❌ for CF free | High TTL | API limits | ⚠️ Partial — read-only key-value, not real-time |
| Bluesky / ATProto PDS | https://atproto.com | MIT | — | ✅ Required | — | — | ❌ N — account required |
| Yggdrasil Network | https://yggdrasil-network.github.io | LGPL-3.0 | Go daemon | ❌ No | LAN-speed | None | ❌ N — requires installed daemon, Go only |

**Nostr as signaling layer:** Using Nostr DM events (NIP-04 / NIP-44) as a transport for SPT signaling messages is feasible and genuinely multi-operator. A SPT node publishes its iroh endpoint in a Nostr DM to the target peer's pubkey. The receiver polls its relay set and retrieves the endpoint. No single relay is required; users choose their own relay set. The `nostr-sdk` crate is mature. Latency is 200–500 ms which is acceptable for initial connection signaling (not for message delivery).[^54]

***

### 2.6 Mesh-VPN Alternatives

| Name | Primary URL | Free & Accountless | Single Operator | Verdict |
|---|---|---|---|---|
| Tailscale | https://tailscale.com | Free tier 100 devices but **requires** SSO account[^58] | Tailscale Inc. controls plane | ❌ Disqualified — account required |
| Headscale | https://github.com/juanfont/headscale | Free, self-hosted | Per-user-operated | ❌ Disqualified — requires someone to run it (violates "no central operator" for multi-party use) |
| ZeroTier | https://zerotier.com | Free 25 devices but **requires** account[^59] | ZeroTier Inc. + user controllers | ❌ Disqualified — account required |
| Nebula (Slack) | https://github.com/slackhq/nebula | Free, open source | Self-hosted CA | ❌ Disqualified — requires CA distribution; cert coordination = a central operator |
| WireGuard (raw) | https://wireguard.com | Free | None | ⚠️ Partial — manual key exchange; usable IF Magic Wormhole handles pairing UX; no daemon on Linux 5.6+ |
| Innernet | https://github.com/tonarino/innernet | MIT | Self-hosted CA | ❌ Same as Nebula |
| Yggdrasil | https://yggdrasil-network.github.io | Free, no account | None (public peers) | ❌ Disqualified — Go daemon required, no Rust library |

***

### 2.7 Existing Agent-to-Agent Messaging Systems

| System | Model | Transport / Identity | Account Required | P2P WAN | Rust Support | Key Lesson for SPT |
|---|---|---|---|---|---|---|
| Matrix federation | Federated servers | HTTPS + Matrix ID | ✅ Yes (per homeserver) | Via bridges | `matrix-sdk` | Federation model is good; account requirement disqualifies |
| XMPP federation / XEP-0174 | Federated servers + serverless local | XML streams + mDNS for local[^60] | ⚠️ Optional (serverless mode) | Via s2s | `xmpp-rs` | Serverless XMPP (XEP-0174) is mDNS-based and account-free on LAN — relevant for SPT LAN mode |
| ActivityPub | Push-based federated | HTTP + server identity | ✅ Yes | Via servers | `activitypub-core` | Server-required by design; not useful |
| SSB (Secure Scuttlebutt) | Gossip + signed feed | ed25519 pubkey | ❌ None | Via "pub" servers (optional)[^50][^61][^51] | JS-first | Best identity model: pubkey IS identity; no global registry; pub servers are optional and untrusted |
| Briar | Tor + BT + LAN | Tor hidden services + mDNS | ❌ None (username+password local only)[^52][^53] | Via Tor | Android/Java | Contact model: QR/link exchange at first contact — directly applicable to SPT pairing UX |
| DAT / Hypercore | Gossip + signed log | Ed25519 | ❌ None | Via Hyperswarm | JS-first (`hypercore-rs` prototype) | Append-only signed feed concept; Rust port immature |
| Nostr | Relay-broadcast events | Pubkey (secp256k1) | ❌ None | Via relays | `nostr-sdk` (MIT)[^54] | Multi-relay model eliminates single-operator; event model maps naturally to SPT message spooling |
| MLS (RFC 9420) | Group key agreement | Delivery Service (DS) | Depends on DS | Via DS | `openmls` crate | Group forward secrecy for SPT multi-agent chats; requires a DS (can be any spool) — relevant at crypto layer[^62][^63] |
| **Anthropic MCP** | Tool/context protocol | JSON-RPC 2.0 over stdio/SSE | ❌ None | Remote MCP being added (2025)[^64][^65] | `mcp-rs` | MCP transports are local by design; remote MCP is HTTP-based and requires a server URL — not a P2P transport |
| **Google A2A** | Agent capability protocol | HTTP + AgentCard + A2A SDK | Depends on server | Via HTTP | None yet (Python SDK only)[^66][^67] | Enterprise-oriented; HTTP client-server model; no P2P addressing or identity; not applicable to SPT constraints |
| AutoGen / LangGraph / CrewAI | Multi-agent orchestration | In-process or HTTP | Framework-specific | Limited (HTTP) | None | These frameworks do not address multi-machine transport; they assume a shared process or a reachable HTTP server[^68] |

**MCP / A2A gap:** Neither MCP nor A2A addresses multi-machine P2P transport. MCP in 2025 is evolving toward "remote MCP connections" over HTTPS, but this requires a URL-accessible server, not a P2P endpoint. A2A is an enterprise HTTP orchestration protocol. Neither provides NAT traversal, account-free identity, or relay infrastructure — all three problems SPT must solve. The networking layer developed for SPT would be complementary to MCP/A2A at the protocol surface level.[^67][^64][^69]

***

### 2.8 Embeddable Runtime Concerns (Rust + Claude Code Plugin)

**Binary size.** With LTO, `opt-level = "z"`, and `strip = true`, a tokio + quinn + iroh binary typically lands at 5–15 MB stripped vs. the 43–93 MB figure reported for the unoptimized crate. The key technique is disabling default features on transitive dependencies. libp2p with a minimal feature set (tcp, quic, dcutr, kad, mdns) adds approximately 2–5 MB. Neither is disqualifying for a desktop tool.[^70][^71][^9]

**Async runtime.** Both iroh and veilid-core default to tokio. Quinn is tokio-native. If SPT currently uses a synchronous or async-std runtime, pulling in tokio adds ~1–2 MB and requires a `#[tokio::main]` entry point or a `Runtime::new().block_on(...)` wrapper in the existing main. This is a one-time integration cost, not an ongoing complexity.[^41][^72][^73][^24][^74][^8][^75]

**Windows Firewall prompt.** Any application that binds an inbound UDP or TCP socket for the first time will trigger a Windows Defender Firewall dialog. This is unavoidable without pre-shipping a signed application with a pre-declared firewall exception. The mitigation is: (a) frame it in the CLI UX ("SPT is requesting network access — click Allow"), (b) prefer outbound-initiated UDP hole punching where possible (outbound is not blocked by default), and (c) consider using a high-numbered port (>1024) in user space to reduce "public network" warnings.[^76][^77]

**IPv6 reliance.** Iroh and QUIC work over both IPv4 and IPv6. mDNS sends on both IPv4 multicast (224.0.0.251) and IPv6 multicast (FF02::FB). Consumer IPv6 deployment is uneven (~40–50% global), so the implementation must not assume IPv6 WAN reachability. Both iroh and libp2p handle dual-stack automatically.[^78][^17][^2][^1]

***

### 2.9 arxiv Papers

| Title | Authors | Year | arXiv URL | Relevance to SPT |
|---|---|---|---|---|
| "Peer-to-Peer Communication Across Network Address Translators" | Bryan Ford, Pyda Srisuresh, Dan Kegel | 2005 | https://arxiv.org/abs/cs/0603074 | Foundational hole-punching analysis; 82% UDP NAT success rate[^35][^36] |
| "Implementing NAT Hole Punching with QUIC" | Jinyu Liang, Wei Xu, Taotao Wang, Qing Yang, Shengli Zhang | 2024 | https://arxiv.org/abs/2408.01791 | QUIC HP reduces punching time; connection migration saves 2 RTTs on NAT timeout[^43] |
| "Scalability limitations of Kademlia DHTs when enabling Data Availability Sampling" | Various | 2024 | https://arxiv.org/abs/2402.09993 | Kademlia DHT at scale; undialable NAT'd peers inflate routing table churn[^79] |
| "Honeybee: Decentralized Peer Sampling with Verifiable Random Walks" | Yunqi Zhang, Shaileshh Bojja Venkatakrishnan | 2024 | https://arxiv.org/abs/2402.16201 | GossipSub vs Kademlia adversarial sampling; Honeybee outperforms by 4–63%[^80] |
| "Towards Communication-Efficient Peer-to-Peer Networks" | Hourani, Moses, Pandurangan | 2024 | https://arxiv.org/abs/2406.16661 | Random-topology P2P networks and propagation delay; relevant to gossipsub topology design[^81] |
| "Large Scale Measurement Campaign on Decentralized NAT Traversal" | Various | 2025 | https://arxiv.org/abs/2510.27500 | First large-scale measurement of decentralized NAT traversal; centralization risks in P2P re-introduced through traversal infrastructure[^82] |

***

## 3. Disqualified Options

| Option | Hard Requirement Failed | Reasoning |
|---|---|---|
| **Tailscale** | #2 (no credentials) | Free tier requires SSO account (Google/Microsoft/GitHub login)[^58]; cannot be used without account creation |
| **Headscale** | #1 (no central server) | Self-hosted Tailscale control plane; someone must operate it for all users — violates "no single operator" in a multi-party scenario |
| **ZeroTier** | #2 (no credentials) | Account required even on free tier[^59][^83]; reduced device cap on free tier |
| **Nebula (Slack)** | #1 (no central server) | Requires a CA operator to sign certificates for all nodes; cert distribution is a coordination point |
| **Innernet** | #1 (no central server) | Same as Nebula: CA-based WireGuard mesh requires a trusted CA operator |
| **Yggdrasil** | #5 (single binary) | Go implementation only; no production Rust library; requires daemon install[^45][^46][^84] |
| **GNUnet** | #2, #5 | AGPL-3.0 license; C daemon; thin Rust bindings only; complex multi-service architecture unsuitable for embedding |
| **Hyperswarm/Hypercore** | #5 (single binary) | JavaScript-first; `hypercore-rs` is an unmaintained prototype; no production Rust crate[^85] |
| **Matrix** | #2 (no credentials) | Standard use requires account registration; guest access is rate-limited and quasi-violates the no-credentials requirement |
| **Bluesky / ATProto PDS** | #2 (no credentials) | Account required even on self-hosted PDS |
| **cjdns** | #5 (single binary) | C implementation; requires daemon install; GPL-3.0 license conflicts with potential commercial use |
| **Tor (arti) as primary transport** | #4 (free at hobbyist scale) + latency | Functionally free and embeddable (`arti-client`)[^56][^86], but 300–1000 ms latency is incompatible with interactive agent-to-agent messaging; reserved as an anonymity-mode fallback |
| **WebRTC data channels** | #5 (single binary) | Large dependency tree; headless use requires significant integration work; QUIC via Quinn provides the same capabilities more directly without ICE complexity |
| **Google A2A protocol** | #1, #2 | HTTP client-server model; requires URL-reachable server; enterprise-oriented; no P2P addressing[^66][^67] |
| **Anthropic MCP (as transport)** | #1, #2 | Local stdio/SSE transport; remote MCP requires HTTP server; not a P2P NAT-traversing transport[^64][^65] |

***

## 4. Open Questions

1. **Relay operator commitment.** Are the SPT maintainers willing to operate a small fleet of iroh relay nodes (`iroh-relay` binary on a $5/month VPS) as "best effort community infrastructure"? This eliminates the n0.computer dependency for production users while keeping the default config working. Without this, production deployments silently depend on a third party.

2. **Bootstrap node strategy for libp2p / DHT path.** If rust-libp2p + Kademlia is chosen, who runs the bootstrap nodes? Options: (a) embed a hardcoded list of well-known community nodes, (b) use the existing IPFS bootstrap nodes (soft-centralization), or (c) build a "bring your own bootstrap" model where each install can self-bootstrap.

3. **Pairing ceremony UX scope.** How interactive should the initial peer introduction be? Options range from "paste a public key string" (power-user) to "run `$OWL pair` and exchange a 6-word code via any out-of-band channel" (Magic Wormhole style) to "scan a QR code" (Briar style). The choice constrains the identity primitives.

4. **Message delivery semantics.** SPT currently has `spool` (SQLite-backed). For WAN delivery: should the protocol guarantee at-least-once delivery with a spool on the sender side until the remote acknowledges, or best-effort? This determines whether a relay spool is needed (complexity) or delivery is fire-and-forget (simpler, risk of loss).

5. **Nostr signaling relay governance.** If Nostr is used for endpoint signaling (not message delivery), which relay set does the binary default to? The community relay list changes. A curated default list of 3–5 high-uptime relays should be embedded with a runtime override mechanism.

6. **Veilid all-node-as-relay model.** Veilid routes all traffic through intermediate nodes by design, contributing ~5 GB/month of relay bandwidth at idle. Is this acceptable for SPT users? A disclosure in the `$OWL provision` UX is required if Veilid is chosen.[^27]

7. **Windows code signing.** Without a signed binary, the Windows Firewall dialog labels SPT as "unknown publisher." Is there a plan to sign Windows builds? Unsigned is functional but degrades first-run UX.

8. **IPv6-only CGNAT users.** Some ISPs (mobile carriers, some residential) double-NAT users behind CGNAT on IPv4 with IPv6 exposed. Symmetric UDP hole punching fails for these users. Does the relay fallback automatically handle this, or does the UX degrade to "relay-only mode" with user warning?[^87][^88]

***

## 5. Recommended Next Prototype

**Experiment: Iroh + mdns-sd LAN+WAN smoke test in ≤ 1 week**

### Goal
Validate that two SPT instances on separate machines, behind separate NATs, can establish a bidirectional QUIC stream using iroh's magic-endpoint, with mDNS discovery auto-detecting LAN peers.

### Steps

1. **Add dependencies** to `Cargo.toml`:
   ```toml
   iroh = { version = "0.90", features = ["discovery-local-network"] }
   mdns-sd = "0.11"
   tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
   ```

2. **Generate identity on first run.** On startup, if no keypair exists in `%LOCALAPPDATA%\spt\owlery\node.key` (Windows) / `~/.spt/owlery/node.key` (Unix), generate an Ed25519 keypair via `iroh::key::SecretKey::generate()` and persist it. The node's public key is its SPT address.

3. **LAN discovery.** Register an mDNS service `_spt._udp.local.` with the iroh endpoint's `NodeAddr` serialized as a TXT record. Simultaneously browse for `_spt._udp.local.` services to discover neighbors without WAN.

4. **WAN connection.** When a peer's iroh `NodeId` is known (from mDNS TXT or out-of-band key exchange), call `endpoint.connect(node_id, ...)`. Iroh contacts n0.computer's public relay for signaling, attempts QUIC hole punching, falls back to relay if needed.

5. **Wrap the `$OWL deliver` surface.** On successful connection, open a bidirectional QUIC stream and encode existing SPT messages as length-prefixed JSON frames. The local spool remains the source-of-truth; remote delivery is an async best-effort push with acknowledged receipt.

6. **Measure.** On two machines behind residential NAT (or two cloud VMs in different regions), time to first message. Record whether connection went direct or through relay (`endpoint.conn_type()` in iroh exposes this). Report binary size (stripped release build).

### Success criteria
- Two SPT instances exchange an `$OWL deliver` message end-to-end with no user configuration beyond exchanging node IDs.
- Connection goes direct (not relay-only) on at least one typical residential NAT test.
- Stripped binary size increase ≤ 8 MB vs. baseline.
- `$OWL list` and `$OWL poll` continue to work unchanged (backward compatibility check).

### Fallback if iroh fails
If iroh's binary size or tokio dependency proves incompatible, switch to: raw `quinn` (QUIC transport) + `mainline` crate (Mainline DHT for rendezvous) + `mdns-sd` for LAN. This requires implementing the hole-punching coordination manually using the DHT as the signaling channel, but avoids any third-party relay infrastructure entirely.

---

## References

1. [Crate irohCopy item path](https://docs.rs/iroh/0.90.0/iroh/) - Peer-to-peer QUIC connections.

2. [n0-computer/iroh: peer-2-peer that just works](https://github.com/n0-computer/iroh) - peer-2-peer that just works. Contribute to n0-computer/iroh development by creating an account on Gi...

3. [Custom relays - iroh](https://docs.iroh.computer/add-a-relay) - Configure dedicated relays so your endpoints don't share infrastructure with the public network

4. [Relays - iroh](https://docs.iroh.computer/concepts/relays)

5. [FAQ - irohdocs.iroh.computer › about › faq](https://docs.iroh.computer/about/faq)

6. [johnthagen/min-sized-rust: How to minimize Rust binary size - GitHub](https://github.com/johnthagen/min-sized-rust) - 🦀 How to minimize Rust binary size 📦. Contribute to johnthagen/min-sized-rust development by creatin...

7. [libp2p-iroh 0.1.1 on Cargo - Libraries.io](https://libraries.io/cargo/libp2p-iroh) - iroh quic as libp2p transport

8. [iroh-loro/Cargo.toml at main · loro-dev/iroh-loro](https://github.com/loro-dev/iroh-loro/blob/main/Cargo.toml) - Contribute to loro-dev/iroh-loro development by creating an account on GitHub.

9. [Iroh — Rust network library // Lib.rs](https://lib.rs/crates/iroh) - p2p quic connections dialed by public key

10. [libp2p::tutorials::hole_punching - Rust - Docs.rs](https://docs.rs/libp2p/latest/libp2p/tutorials/hole_punching/index.html) - Hole Punching Tutorial

11. [NAT Traversal rust-libp2p](https://discuss.libp2p.io/t/nat-traversal-rust-libp2p/1316) - We are building a decentralized peer-to-peer network using rust-libp2p and i saw there are many chan...

12. [DCUtR - libp2p](https://libp2p.io/docs/dcutr/) - DCUtR is a protocol for establishing direct connections between nodes behind NATs.

13. [A Rusty Bootstrapper | IPFS Blog & News](https://blog.ipfs.tech/2023-rust-libp2p-based-ipfs-bootstrap-node/) - Running rust-libp2p-server on one of our four IPFS bootstrap nodes.

14. [Kademlia DHT - libp2p](https://libp2p.io/docs/kademlia-dht/) - The libp2p Kad-DHT subsystem is an implementation of the Kademlia DHT, a distributed hash table.

15. [feat(quic): implement hole punching by arpankapoor · Pull Request #3964 · libp2p/rust-libp2p](https://github.com/libp2p/rust-libp2p/pull/3964) - Description Implement Transport::dial_as_listener for QUIC as specified by the DCUtR spec. To facili...

16. [Modify the bootstrap list - IPFS Docs](https://docs.ipfs.tech/how-to/modify-bootstrap-list/) - Learn how to modify the IPFS bootstrap peers list to create a personal IPFS network.

17. [RFC 6762 - Multicast DNS - IETF Datatracker](https://datatracker.ietf.org/doc/rfc6762/) - As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with...

18. [mdns_sd - Rust - Docs.rs](https://docs.rs/mdns-sd/latest/mdns_sd/) - A small and safe library for Multicast DNS-SD (Service Discovery). This library creates one new thre...

19. [Local Discovery Protocol v4¶](https://docs.syncthing.net/specs/localdisco-v4)

20. [Local Discovery Protocol v4 - Syncthing documentation](https://docs.syncthing.net/specs/localdisco-v4.html)

21. [Cult of the Dead Cow unveils 'Veilid', "a secure peer-to-peer network for apps that flips off the surveillance economy" - Garuda's Lemmy](https://lemmy.garudalinux.org/post/19900/64062) - DEF CON Infosec super-band the Cult of the Dead Cow has released Veilid (pronounced vay-lid), an ope...

22. [Cult of the Dead Cow unveils Veilid peer-to-peer project - The Register](https://www.theregister.com/2023/08/12/veilid_privacy_data/) - DEF CON: ‘It’s like Tor and IPFS had sex and produced this thing’

23. [Veilid - Wikipedia](https://en.wikipedia.org/wiki/Veilid)

24. [veilid-core 0.4.8](https://docs.rs/crate/veilid-core/latest)

25. [veilid-tools](https://lib.rs/crates/veilid-tools) - A collection of baseline tools for Rust development use by Veilid and Veilid-enabled Rust applicatio...

26. [Networking - Veilid](https://veilid.com/how-it-works/networking/) - Any node can bootstrap a Veilid network. Networks can be 'keyed' to keep nodes off that don't have t...

27. [Thoughts on Veilid (privacy network, cult of the dead cow) - Reddit](https://www.reddit.com/r/opensource/comments/1qdlgg3/thoughts_on_veilid_privacy_network_cult_of_the/) - Veilid is "Tor for apps" and relies on users hosting nodes. It seems similar to Freenet which is als...

28. [magic_wormhole - Rust - Docs.rs](https://docs.rs/magic-wormhole) - Magic Wormhole is known for its ability to transfer files. This is implemented in the transfer modul...

29. [Rust implementation of Magic Wormhole, with new features ... - GitHub](https://github.com/magic-wormhole/magic-wormhole.rs) - New features that exceed the other implementations: Can do direct connections across the internet (N...

30. [Welcome — Magic-Wormhole 0.24.0+16.g92eda0c documentation](https://magic-wormhole.readthedocs.io/en/latest/welcome.html) - The wormhole tool uses PAKE “Password-Authenticated Key Exchange”, a family of cryptographic algorit...

31. [Mainline DHT - Wikipedia](https://en.wikipedia.org/wiki/Mainline_DHT) - Mainline DHT is the name given to the Kademlia-based distributed hash table (DHT) used by BitTorrent...

32. [mainline - Rust - Docs.rs](https://docs.rs/mainline) - Simple, robust, BitTorrent's Mainline DHT implementation. This library is focused on being the best ...

33. [Local Discovery Protocol v4](https://docs.syncthing.net/v1.28.0/specs/localdisco-v4.html)

34. [Magic Wormhole - Flaviu Vlaicu](https://vlaicu.io/posts/wormhole/) - How PAKE Works: Uses a short, low-entropy password (the wormhole code) to establish a strong, high-e...

35. [Peer-to-Peer Communication Across Network Address Translators](https://arxiv.org/abs/cs/0603074) - This paper documents and analyzes one of the simplest but most robust and practical NAT traversal te...

36. [Peer-to-Peer Communication Across Network Address Translators](http://arxiv.org/abs/cs/0603074v1) - Network Address Translation (NAT) causes well-known difficulties for peer-to-peer (P2P) communicatio...

37. [OpenRelay Project: Free Reliable WebRTC TURN Server - Reddit](https://www.reddit.com/r/WebRTC/comments/sqx3ip/openrelay_project_free_reliable_webrtc_turn_server/) - Open Relay Project (https://openrelayproject.org) is a reliable, production ready WebRTC TURN+STUN S...

38. [RFC 8656 - Traversal Using Relays around NAT (TURN)](https://datatracker.ietf.org/doc/html/rfc8656) - This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allow...

39. [RFC 8445 - Interactive Connectivity Establishment (ICE)](https://datatracker.ietf.org/doc/html/rfc8445) - This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based comm...

40. [rfc8445.txt - » RFC Editor](https://www.rfc-editor.org/rfc/rfc8445.txt)

41. [GitHub - quinn-rs/quinn: Async-friendly QUIC implementation in Rust](http://github.com/quinn-rs/quinn) - Async-friendly QUIC implementation in Rust. Contribute to quinn-rs/quinn development by creating an ...

42. [quinn-rs/quinn: Async-friendly QUIC implementation in Rust](https://github.com/quinn-rs/quinn) - Async-friendly QUIC implementation in Rust. Contribute to quinn-rs/quinn development by creating an ...

43. [[2408.01791] Implementing NAT Hole Punching with QUIC - arXiv](https://arxiv.org/abs/2408.01791) - We find that the QUIC-based scheme effectively reduces the hole punching time, exhibiting a pronounc...

44. [How It Works · Veilid](https://veilid.com/how-it-works/) - The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to...

45. [Yggdrasil Network — Join the Global Mesh](https://dev.to/byteknight/yggdrasil-network-join-the-global-mesh-1kcc) - The Yggdrasil Network is an experimental, end‑to‑end encrypted IPv6 overlay that links nodes into a....

46. [Yggdrasil Network | End-to-end encrypted IPv6 networking to ...](https://yggdrasil-network.github.io) - End-to-end encrypted IPv6 networking to connect worlds

47. [snow - Rust - Docs.rs](https://docs.rs/snow/) - The snow crate aims to be a straightforward Noise Protocol implementation. See the Noise Protocol Fr...

48. [noise-protocol — Rust crypto library // Lib.rs](https://lib.rs/crates/noise-protocol) - This repository contains several crates. The noise-protocol crate contains the abstract implementati...

49. [The Noise Protocol Framework - media.ccc.de](https://media.ccc.de/v/34c3-9222-the_noise_protocol_framework) - Noise provides a simple pattern language and naming scheme for 2-party DH-based cryptographic handsh...

50. [Secure Scuttlebutt - Scuttlebot](https://scuttlebot.io/more/protocols/secure-scuttlebutt.html)

51. [Secure Scuttlebutt - SSBC](https://ssbc.github.io/ssb-db/) - Secure Scuttlebutt is a database protocol for unforgeable append-only message feeds. "Unforgeable" m...

52. [Secure, Peer-To-Peer Messaging Apps - Brax Community](https://community.braxtech.net/t/secure-peer-to-peer-messaging-apps/2668) - To add a contact, users must connect directly, typically by scanning each other's QR codes, ensuring...

53. [Briar: Secure messaging, anywhere](https://briarproject.org) - Censorship-resistant peer-to-peer messaging that bypasses centralized servers. Connect via Bluetooth...

54. [Rust implementation of the nostr protocol, high-level client ... - GitHub](https://github.com/rust-nostr/nostr) - nostr-relay-builder: Build your own custom nostr relay; nostr-sdk: A full-featured SDK for building ...

55. [nostr - Rust - Docs.rs](https://docs.rs/nostr) - Rust implementation of Nostr protocol. You may be interested in: nostr-sdk if you want to write a ty...

56. [tor-hsservice — Rust network library // Lib.rs](https://lib.rs/crates/tor-hsservice) - Arti's implementation of an onion service provider

57. [tor_hsservice - Rust - Docs.rs](https://docs.rs/tor-hsservice/latest/tor_hsservice/) - tor-hsservice

58. [Tailscale: The Zero-Config VPN Your Homelab Needs](https://www.antlatt.com/blog/tailscale-homelab-vpn/) - Skip the port forwarding headaches. Tailscale gives you instant, secure access to your homelab from ...

59. [Tailscale vs Zerotier vs … - Duplicacy Forum](https://forum.duplicacy.com/t/tailscale-vs-zerotier-vs/9795) - Completely off-topic, but try Zerotier instead. It’s a Layer 2 solution (as opposed to Layer 3 servi...

60. [XEP-0174: Serverless Messaging - XMPP](https://xmpp.org/extensions/xep-0174.html) - This specification defines how to communicate over local or wide-area networks using the principles ...

61. [Gossip - Introduction · GitBook](https://handbook.scuttlebutt.nz/concepts/gossip) - In Scuttlebutt, 3rd parties can relay (gossip) information for you, which improves availability. Eve...

62. [Information on RFC 9420 - » RFC Editor](https://www.rfc-editor.org/info/rfc9420)

63. [The Messaging Layer Security (MLS) Protocol](https://www.rfc-editor.org/rfc/rfc9420) - Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that ...

64. [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol?guides=understanding-tradeoffs)

65. [Introducing the Model Context ...](https://www.anthropic.com/news/model-context-protocol)

66. [Announcing the Agent2Agent Protocol - A2A (Google Blog, April 2025)](https://www.facebook.com/groups/DeepNetGroup/posts/2456717144721153/) - The A2A protocol will allow AI agents to communicate with each other, securely exchange information,...

67. [What Is Agent2Agent (A2A) Protocol?](https://www.ibm.com/think/topics/agent2agent-protocol) - The Agent2Agent (A2A) protocol is an open communication protocol for artificial intelligence (AI) ag...

68. [Multi-agent Conversation Framework | AutoGen 0.2](https://microsoft.github.io/autogen/0.2/docs/Use-Cases/agent_chat/) - AutoGen offers a unified multi-agent conversation framework as a high-level abstraction of using fou...

69. [Anthropic Officially Releases MCP Protocol 2025 Semi-Annual ...](https://www.kdjingpai.com/en/anthropic-zhengshifaa/) - Our Plans for the Evolution of the Model Context Protocol (first half of 2025) The Model Context Pro...

70. [Binary size · Issue #1051 · libp2p/rust-libp2p](https://github.com/libp2p/rust-libp2p/issues/1051) - I have tried compiling the examples, ipfs-kad.rs and chat.rs, and I am getting quite heavy binary si...

71. [I shrunk my Rust binary from 11MB to 4.5MB with bloaty-metafile](https://dev.to/ahaoboy/i-shrunk-my-rust-binary-from-11mb-to-45mb-with-bloaty-metafile-1n7i) - TL;DR: Used bloaty-metafile to analyze binary size, disabled default features on key dependencies,.....

72. [TokioRuntime in iroh_quinn - Rust - Docs.rs](https://docs.rs/iroh-quinn/latest/iroh_quinn/struct.TokioRuntime.html) - A Quinn runtime for Tokio

73. [Hello Tokio - An asynchronous Rust runtime](https://tokio.rs/tokio/tutorial/hello-tokio) - Tokio is a runtime for writing reliable asynchronous applications with Rust. It provides async I/O, ...

74. [veilid-tools 0.4.7](https://docs.rs/crate/veilid-tools/latest)

75. [How to use async/await in Rust when you can't make main function async](https://stackoverflow.com/questions/71116502/how-to-use-async-await-in-rust-when-you-cant-make-main-function-async) - I have a function to download a file which is async: async fn download_file() { fn main() { let resp...

76. [Windows Firewall Inbound Rule behavior : r/sysadmin - Reddit](https://www.reddit.com/r/sysadmin/comments/17c4r18/windows_firewall_inbound_rule_behavior/) - When you first open many networked applications, Windows pops up asking you to allow the application...

77. [Windows Firewall Rules | Microsoft Learn](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules) - This article describes the concepts and recommendations for creating and managing firewall rules.

78. [RFC 6762 - ICANNWiki](https://icannwiki.org/RFC_6762) - For implications on Internet governance, see Multicast DNS. RFC 6762, Multicast DNS, is an IETF Stan...

79. [[PDF] Scalability limitations of Kademlia DHTs when enabling Data ... - arXiv](https://arxiv.org/pdf/2402.09993.pdf) - This paper provides insights after exploring the usage of a Kademlia-based DHT to enable Data Availa...

80. [Honeybee: Decentralized Peer Sampling with Verifiable Random ...](https://arxiv.org/html/2402.16201v1) - However, when the network contains adversarial nodes, Honeybee outperforms GossipSub and Kademlia by...

81. [Towards Communication-Efficient Peer-to-Peer Networks](https://arxiv.org/abs/2406.16661) - We focus on designing Peer-to-Peer (P2P) networks that enable efficient communication. Over the last...

82. [Large Scale Measurement Campaign on Decentralized NAT Traversal](https://arxiv.org/html/2510.27500v1)

83. [Wireguard, Zerotier or Tailscale - General Discussion - DietPi](https://dietpi.com/forum/t/wireguard-zerotier-or-tailscale/13546) - In upcoming dietpi Zerotier, Tailscale are coming as new software. Any advice or recommendation for ...

84. [yggdrasil-network/yggdrasil-go: An experiment in scalable ... - GitHub](https://github.com/yggdrasil-network/yggdrasil-go) - An experiment in scalable routing as an encrypted IPv6 overlay network - yggdrasil-network/yggdrasil...

85. [libp2p — Rust network library // Lib.rs](https://lib.rs/crates/libp2p) - Peer-to-peer networking library

86. [Arti 1.4.6 is released: Hidden Service resilience](https://forum.torproject.org/t/arti-1-4-6-is-released-hidden-service-resilience-work-on-flow-control-conflux-and-cgo/20258) - by Diziet | August 5, 2025 Arti is our ongoing project to create a next-generation Tor client in Rus...

87. [How to Implement UDP Hole Punching for NAT Traversal - OneUptime](https://oneuptime.com/blog/post/2026-03-20-udp-hole-punching-nat/view) - Implement UDP hole punching to establish direct peer-to-peer UDP connections between hosts behind NA...

88. [A P2P Vision for QUIC (2024) - Hacker News](https://news.ycombinator.com/item?id=45822982) - > UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have pr...