# Forums + Wikis + Videos Index

Prior-art notes for SPT (Rust inter-agent messaging, single binary, no central server). Cross-refs are to footnote numbers in `../../SPT Networked Messaging Research Brief.md`.

## Quick lookup

| Question | Best file |
|---|---|
| What practical errors do you hit wiring up rust-libp2p DCUtR? | forums/discuss-libp2p-io-t-nat-traversal-rust-libp2p-1316.html |
| Why can't I just hole-punch every NAT? (symmetric / CGNAT walls) | forums/news-ycombinator-com-item-45822982.html |
| Does QUIC's mandatory TLS block self-signed P2P? | forums/news-ycombinator-com-item-45822982.html |
| TCP simultaneous-open — does it really work? | forums/news-ycombinator-com-item-45822982.html |
| What account-free P2P messengers should we learn from? | forums/community-braxtech-net-t-secure-peer-to-peer-messaging-apps-2668.html |
| Tailscale vs ZeroTier vs WireGuard — and why all three fail SPT's "no account" bar | forums/forum-duplicacy-com-t-tailscale-vs-zerotier-vs-9795.html, forums/dietpi-com-forum-t-wireguard-zerotier-or-tailscale-13546.html |
| Why ZeroTier's mDNS-over-L2 matters for service discovery | forums/forum-duplicacy-com-t-tailscale-vs-zerotier-vs-9795.html |
| Mobile-mobile dual-NAT pain (outbound-only escape hatch) | forums/dietpi-com-forum-t-wireguard-zerotier-or-tailscale-13546.html |
| How do I bridge sync `main` to async runtime in Rust? | forums/stackoverflow-com-questions-71116502-how-to-use-async-await-in-rust.html |
| What is Mainline DHT actually capable of (size, TTL, KRPC framing)? | wikis/en-wikipedia-org-wiki-mainline-dht.html |
| What is Veilid in one paragraph (lang, license, identity model)? | wikis/en-wikipedia-org-wiki-veilid.html |
| Why pick Noise over rolling your own handshake? | videos/media-ccc-de-v-34c3-9222-the-noise-protocol-framework.html |
| Veilid community sentiment (Tor-for-apps vs Freenet) | forums/reddit-com-r-opensource-comments-1qdlgg3-thoughts-on-veilid.html (gated) |
| Windows Firewall first-inbound UX | forums/reddit-com-r-sysadmin-comments-17c4r18-windows-firewall-inbound-rule.html (gated) |
| Free TURN for WebRTC fallback | forums/reddit-com-r-webrtc-comments-sqx3ip-openrelay-project.html (gated) |
| mDNS / RFC 6762 background | wikis/icannwiki-org-rfc-6762.html (gated) |

## Per-file entries

### forums/

#### community-braxtech-net-t-secure-peer-to-peer-messaging-apps-2668.html
- **Source:** Brax Community (Discourse forum), general-topics thread, Oct 2025.
- **Q:** Which messengers are genuinely P2P / account-free?
- **Key answers:**
  - @loumac (OP): Briar = "no central server, direct encrypted connections", syncs over Bluetooth/Wi-Fi/SD when offline, Tor when online; "to add a contact, users must connect directly, typically by scanning each other's QR codes"; "does not require personal information to set up, only a username and password".
  - @xliiv: also consider Simplex, Jami, Tox.
  - @romluk: "I use SimpleX. I'm very happy with it."
  - @404usernotfound: notes Briar Mailbox = always-on companion device so offline phones still receive mail.
- **Takeaway:** Briar's QR-at-first-contact + offline-by-design + mailbox-companion is the closest social pattern to what SPT pairing/spool needs. Simplex worth a deeper look as a second prior art.
- **Tags:** identity, pairing, privacy, mesh, none-rust
- **Brief footnote refs:** [^52][^53] (Briar contact model)

#### dietpi-com-forum-t-wireguard-zerotier-or-tailscale-13546.html
- **Source:** DietPi community forum, June 2022 – Feb 2024.
- **Q:** WireGuard vs ZeroTier vs Tailscale for a small/home user?
- **Key answers:**
  - @MichaIng: "WireGuard is a classic non-cloud VPN server, so the server needs a static IP or domain… ZeroTier is the other extreme: simple to setup, no static IP/domain needed, but you rely on the ZeroTier infrastructure."
  - @precisionpete: WG works only if you're not mobile; recommends Netrinos as a WG wrapper that "handles… NAT hole punching, DNS, etc. and adjusts your config dynamically." Concrete case: "two students working in different buildings on a campus… can create outbound connections to some 3rd site. But they cannot connect to each other. Netrinos allows them to do that."
- **Takeaway:** Independent confirmation that the Tailscale/ZT/Headscale family disqualifies (account/control plane) and that the *real* user need is outbound-initiated hole-punching with a rendezvous helper — exactly the gap iroh+relay fills for SPT.
- **Tags:** vpn, nat-traversal, hole-punching, bootstrap
- **Brief footnote refs:** [^83] (this exact URL); contrast with [^58][^59] disqualifications.

#### discuss-libp2p-io-t-nat-traversal-rust-libp2p-1316.html
- **Source:** discuss.libp2p.io official forum, March–May 2022. mxinden = rust-libp2p maintainer.
- **Q:** How do I actually enable NAT traversal in rust-libp2p? Why does the hole-punch tutorial fail?
- **Key answers:**
  - @mitalib (OP): points the official tutorial; reports "best NAT traversal technique as of now we have in rust-libp2p is hole punching using dcUTR which has ~60% success connection rate." Asks about QUIC roadmap and multi-protocol fallback.
  - @mitalib (later): tutorial commands wrong — "it uses dns4 as protocol but ask to put ip_address" (filed PR). Direct connection upgrade fails with `connection reset by peer` and `MultiaddrNotSupported`. Hole-punch "keeps on timing out."
  - @mxinden: confirms the error is "outgoing TCP connection timed out, unable to connect to the dialing client"; asks for RUST_LOG=debug.
  - @cheako: links rust-libp2p NAT-traversal tracking issue with the full transport/TURN/signaling checklist (DCUtR, AutoNAT, circuit relay v2, parallel attempts).
- **Takeaway:** First-hand confirmation that rust-libp2p's documented NAT-traversal flow has been brittle in practice; relay reachable, direct upgrade fails. Validates the brief's "higher learning curve" tradeoff and is a strong argument for iroh's batteries-included relay+hole-punch flow over assembling libp2p pieces.
- **Tags:** nat-traversal, hole-punching, rust, dht, transport, review
- **Brief footnote refs:** [^11] (this exact URL — DCUtR ~60% number), [^12][^15][^10].

#### forum-duplicacy-com-t-tailscale-vs-zerotier-vs-9795.html
- **Source:** Duplicacy backup-tool forum, March 2025. Off-topic VPN deep-dive between @saspus and @Droolio.
- **Q:** Tailscale vs ZeroTier for an end-user mesh?
- **Key answers:**
  - @saspus: "Zerotier… is a Layer 2 solution (as opposed to Layer 3 services like WireGuard, OpenVPN, and other IP-based solutions), so you get a lot of LAN functionality, including mDNS for free working out of the box." Repeats: "If you need mDNS support however — Tailscale is plain not a contender." Real use case: Time Machine over the internet for parents.
  - @Droolio: "Tailscale uses wireguard for connectivity…"; defends Tailscale's MagicDNS as supplanting mDNS; "ZT reduced device cap under the free tier from 50 to 25, to 10 — Tailscale increased theirs from 20 to 100." Notes "they still don't have SSO on the free tier" (ZT).
  - Both confirm: account required on both; ZT/TS effectively choose between two single-vendor control planes.
- **Takeaway:** Strong evidence that L2 + mDNS-style service discovery (DNS-SD: AirPrint, Time Machine, shared volumes) is what users actually feel — pure routed VPN feels broken. SPT's mDNS-first LAN design directly addresses this; the thread also enumerates why all three commercial meshes fail the no-account bar even when "free."
- **Tags:** vpn, mdns, discovery, identity, privacy
- **Brief footnote refs:** [^59] (this URL cited there); [^58] (Tailscale SSO); cross with §2.6 disqualifications.

#### news-ycombinator-com-item-45822982.html
- **Source:** Hacker News, "A P2P Vision for QUIC (2024)" (seemann.io), 100 points, 48 comments, ~6 months ago. Highest-signal forum thread in the set.
- **Q:** Can QUIC be the universal P2P transport? What blocks it?
- **Key answers / quotes:**
  - @throw0101d (OP excerpt): "no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way."
  - @tbocek: "UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it." Links own project `qotp` (ed25519 + chacha20poly1305 transport).
  - @throw0101d rebuts: symmetric NAT (corp/CGNAT) breaks the predictable-mapping assumption.
  - @crote: clean taxonomy walk-through — full-cone vs address-restricted vs port-restricted vs symmetric, with rewriting examples. Most consumer NATs = full-cone-ish; corp NAT often destination-dependent.
  - @toast0 + @zamadatix: math of birthday-paradox port probing — "the success rate goes from something like the 64% with 256 probes down to something less than 0.01%" against symmetric NAT; "if you can manage to bump it up to 65536 probes… same success rate." Practical limit: "many NATs are realistically likely to [not] let a single client run 64k sessions." ISPs increasingly CGNAT, no v6, no rescue.
  - @immibis: "TCP Simultaneous Open. If two clients happen to connect to each other's ephemeral ports at exactly the same moment, they connect to each other with no server involved." @klabb3 confirms it works in user-space at payload.app, no packet forging.
  - @superkuh: "QUIC REQUIRES CA TLS for all endpoints." — answered by @tialaramex: "No. QUIC require TLS. TLS just provides a way to move certificates, but doesn't care what a 'certificate' actually is." Plus @max-privatevoid / @saurik / @octoberfranklin: use self-signed + verify by pubkey fingerprint (RFC 7250 raw public keys); WebTransport accepts cert hash.
  - @rubatuga: Yggdrasil uses QUIC/TLS with self-signed certs and runs its own encryption over them; mentions QUIC-in-QUIC HoL pitfalls.
  - @1vuio0pswjnm7: "A default policy that relays traffic through a third party is asinine. For the small percentage, the third parties will always be there if they need them."
- **Takeaway:** Direct evidence for several SPT design choices: (a) raw-pubkey TLS is fine and idiomatic for P2P — kills the "QUIC needs a CA" objection that comes up against iroh; (b) symmetric NAT / CGNAT will need a relay fallback, no escaping it; (c) TCP simultaneous-open is a real, deployed escape hatch; (d) community has clear "direct first, relay only when needed" preference. Reinforces iroh's architecture choice over raw QUIC.
- **Tags:** nat-traversal, hole-punching, quic, transport, identity, noise, review, windows-quirk
- **Brief footnote refs:** [^88] (this exact URL); also [^43] (QUIC HP paper), [^35][^36] (Ford NAT paper), [^46] (Yggdrasil), [^41] (Quinn).

#### reddit-com-r-opensource-comments-1qdlgg3-thoughts-on-veilid.html
- **Source:** Reddit r/opensource thread on Veilid. **Gated** — saved HTML is the Reddit verification interstitial; no thread body captured.
- **Q (from URL):** Community opinion of Veilid (CDC's "Tor for apps").
- **Key answers:** Not available locally; per Brief summary [^27] the takeaway from the thread is "Veilid is 'Tor for apps' and relies on users hosting nodes. It seems similar to Freenet which is also user-hosted."
- **Takeaway:** Reference only; if reading needed, fetch fresh. Useful as the citation anchor for the "every node relays ~5 GB/month" critique of Veilid.
- **Tags:** privacy, overlay, none
- **Brief footnote refs:** [^27] (this URL).

#### reddit-com-r-sysadmin-comments-17c4r18-windows-firewall-inbound-rule.html
- **Source:** Reddit r/sysadmin. **Gated** — verification interstitial, no body captured.
- **Q (from URL):** Behavior of Windows Defender Firewall inbound rules — the dialog on first bind.
- **Key answers:** Not available locally; Brief [^76] summarizes: "When you first open many networked applications, Windows pops up asking you to allow the application."
- **Takeaway:** Reference only. Confirms the first-bind UX issue SPT must frame for users; mitigation = outbound-initiated hole-punching, high port, friendly CLI copy.
- **Tags:** windows-quirk
- **Brief footnote refs:** [^76] (this URL).

#### reddit-com-r-webrtc-comments-sqx3ip-openrelay-project.html
- **Source:** Reddit r/WebRTC. **Gated** — verification interstitial, no body captured.
- **Q (from URL):** OpenRelay Project = free reliable WebRTC TURN server.
- **Key answers:** Not available locally; Brief [^37] notes "OpenRelay Project … is a reliable, production ready WebRTC TURN+STUN" — 20 GB/month free.
- **Takeaway:** Reference only. Cited as the realistic free-tier TURN ceiling if SPT ever falls back to WebRTC-style relaying instead of iroh relays.
- **Tags:** transport, nat-traversal
- **Brief footnote refs:** [^37] (this URL).

#### stackoverflow-com-questions-71116502-how-to-use-async-await-in-rust.html
- **Source:** Stack Overflow, Feb 2022, 31 upvotes, 39k views. Asked by @NightmareXD, top answer by @msrd0.
- **Q:** How do I call `.await` from a sync `fn main`?
- **Key answers:**
  - @msrd0 (37 ↑): use `#[tokio::main] async fn main()` with `tokio = { version = "1", features = ["macros", "rt-multi-thread"] }`.
  - @t56k (9 ↑): manual builder pattern — `tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap().block_on(async { … })`.
  - @Radu Diță: `async-std = {version="1.12.0", features=["attributes"]}` + `#[async_std::main]`.
  - @faizal khan: explains why — "there must be a parent thread which is going to poll the result of main function. if main is itself is async then who is going to poll main?"
  - @kolserdav: full example with `tokio::runtime::Runtime::new().unwrap().block_on(future)`.
- **Takeaway:** Cookbook for the runtime-bridging task the brief flags in §2.8 ("requires a `#[tokio::main]` entry point or a `Runtime::new().block_on(...)` wrapper"). The `Builder::new_current_thread().block_on(...)` recipe is the minimum-footprint way to add tokio to SPT's existing sync `main` without rewriting it.
- **Tags:** rust
- **Brief footnote refs:** [^75] (this URL).

### wikis/

#### en-wikipedia-org-wiki-mainline-dht.html
- **Source:** Wikipedia, last edited 2025-12-25.
- **Q:** What is Mainline DHT and what is its operational shape?
- **Key facts:**
  - "Kademlia-based distributed hash table (DHT) used by BitTorrent clients to find peers"; first shipped in Azureus 2.3.0.0 (May 2005), BitTorrent client v4.2.0 (Nov 2005).
  - "by 2013, the concurrent number of users of Mainline DHT is from 16 million to 28 million, with intra-day changes of at least 10 million."
  - Each client picks a random 160-bit ID; XOR distance; k-buckets.
  - Wire = **KRPC** = "bencoded dictionaries over UDP." Every msg has `t` (txn id) and `y` (q/r/e).
  - Anti-spoofing: "Mainline DHT uses the SHA-1 hash of the IP address concatenated onto a secret that changes every five minutes for a token value. Tokens up to ten minutes old are accepted."
  - Routing-table optimization: lazy split (start with 1 bucket, split only when own ID is in range).
  - Implementations listed: μTorrent, Transmission, rTorrent, KTorrent, BitComet, Deluge, BitSpirit, Vuze (MlDHT plugin), Shareaza, Tixati, qBittorrent.
- **Takeaway:** The 16–28 M concurrent users + ~5-min token rotation explain *both* Mainline's appeal (huge anonymous yellow-pages) and SPT's "~30 minute TTL, must re-announce" warning in Rank 5. KRPC's bencode-over-UDP is the protocol template if SPT ever wants to participate vs. just consume.
- **Tags:** dht, discovery, bootstrap, overlay
- **Brief footnote refs:** [^31] (this URL), with [^32] (`mainline` Rust crate).

#### en-wikipedia-org-wiki-veilid.html
- **Source:** Wikipedia, last edited 2025-12-25.
- **Q:** What is Veilid, in one paragraph?
- **Key facts:** "peer-to-peer network and application framework released by the Cult of the Dead Cow on August 11, 2023, at DEF CON 31." "like Tor, but for apps." Written in **Rust**, MPL-2.0. Runs on Linux/macOS/Windows/Android/iOS/WASM. "Borrows from both the Tor anonymising router and the InterPlanetary File System (IPFS)"; "256-bit public key as the only visible ID. Even details such as IP addresses are hidden."
- **Takeaway:** Confirms the brief's identity-and-license claims and the pubkey-only addressing — a direct precedent for SPT's "node ID = Ed25519 pubkey" design. Stub article, no implementation depth.
- **Tags:** privacy, identity, rust, overlay, dht
- **Brief footnote refs:** [^23] (this URL); pair with [^21][^22][^26].

#### icannwiki-org-rfc-6762.html
- **Source:** ICANN Wiki page for RFC 6762 (Multicast DNS). **Gated** — saved HTML is the Cloudflare "Just a moment…" challenge; no body captured.
- **Q:** Background and governance context of mDNS (RFC 6762).
- **Key answers:** Not available locally; Brief [^78] summarizes "RFC 6762, Multicast DNS, is an IETF Standard…"
- **Takeaway:** Reference only. If body needed for governance / Internet-governance angle on mDNS, refetch.
- **Tags:** mdns, discovery
- **Brief footnote refs:** [^78] (this URL); pair with [^17] (RFC itself), [^18] (`mdns-sd` crate).

### videos/

#### media-ccc-de-v-34c3-9222-the-noise-protocol-framework.html
- **Source:** Chaos Computer Club media (34C3, Leipzig 2017). Talk by **Trevor Perrin**, 32 min, Security track.
- **Q:** What is the Noise Protocol Framework and why use it?
- **Key facts / pitch (from talk abstract):**
  - "toolkit for 2-party secure-channel protocols."
  - "Noise is used by **WhatsApp** for client-server communication, by the **WireGuard** VPN protocol, and by the **Lightning Network**."
  - "Noise provides a simple pattern language and naming scheme for 2-party DH-based cryptographic handshakes, covering the different possibilities for client and/or server authentication, post/pre-specified peers, identity-hiding, and 0-RTT encryption."
  - "Extensions are in the works for additional cryptographic choices, e.g. post-quantum options for 'hybrid forward-secrecy'."
  - Talk page links: mp4 1080p/576p, webm, opus/mp3, eng srt, slides pdf.
- **Takeaway:** Authoritative one-source justification for picking Noise (XX or IK pattern) for SPT's peer handshake — same building block proven in WireGuard + WhatsApp. Pair with the `snow` crate ([^47]) for the Rust implementation.
- **Tags:** noise, identity, pairing, transport
- **Brief footnote refs:** [^49] (this URL); pair with [^47] (`snow`), [^48] (`noise-rust`).

## Themes

- **Direct-first, relay-only-as-fallback is the consensus.** HN P2P-QUIC thread, dietpi mobile-mobile case, and libp2p forum all confirm: users want direct connections; relays are the embarrassed last resort. iroh's "~90% direct" pitch matches this preference exactly.
- **Symmetric NAT / CGNAT is the hard floor.** Birthday-paradox math (HN), Netrinos campus example (dietpi), and `MultiaddrNotSupported`/timeout failures (libp2p) all point to the same residual ~5–15% of users that *must* relay. Validates the brief's Open Question #8.
- **Account-required mesh VPNs are wrong shape for SPT.** Tailscale ↔ ZeroTier ↔ Headscale debates in two forums independently land on "you're picking which company / friend operates your control plane." Reinforces §3 disqualifications.
- **DNS-SD / mDNS still matters for LAN UX.** Duplicacy thread + ICANN reference confirm AirPrint / Time Machine / "things just appear in the sidebar" is what users *feel* as "it works." Brief's mDNS-first hybrid (Rank 3) is well-aligned.
- **Identity = raw Ed25519 pubkey is now boring.** Veilid wiki (256-bit pubkey only), Briar (QR + pubkey), HN thread (RFC 7250 raw public keys in TLS, fingerprint verification), Noise patterns — same recipe everywhere. SPT can pick this without controversy.
- **Rust + tokio integration is a solved cookbook.** The SO answer collapses §2.8's runtime-bridging concern to a one-line attribute macro or a `Builder::new_current_thread()` wrapper.
- **Three Reddit URLs + ICANN are bot-walled.** They remain valid citation anchors via Brief footnotes [^27][^37][^76][^78] but offline analysis must rely on the Brief's pre-existing summaries; refetch with a real browser if quotes are needed.