Repository navigation
id: investigate global (Mainline DHT) content discovery for public worlds #2263
Description
Parent: #2050 (investigation: BitTorrent-style chunk retrieval for graph objects), epic #2056. Follow-up D of the #2050 investigation. Investigation-sized; gated on follow-up A (in-network holder discovery) landing first.
Question
Should pkgs/id add global holder discovery for public content, using the approach n0 demonstrates in the experimental iroh-content-discovery repo: announce SHA-1(BLAKE3 hash) on the BitTorrent Mainline DHT (announce_peer/get_peers), translate returned host:port pairs to EndpointIds via a small signed-record UDP address-index service, verify candidates with a size query, then hand off to the iroh-blobs downloader? (Write-up: iroh.computer blog, "Iroh global content discovery", 2026.)
Why it needs its own investigation
- Privacy/trust: a Mainline announcement publicly states "an endpoint at this IP claims this hash". Right for public boards/files; wrong for membership-gated worlds. Needs a per-world opt-in model (default off) and a clear statement of what the address-index service learns and stores (in-memory, expiring records, signed by the endpoint key).
- Fit:
pkgs/idalready ships optional Mainline address lookup (iroh-mainline-address-lookup, Cargo featuredht) — this is Mainline content discovery, a different use of the same network; evaluate sharing the DHT node/socket machinery. - The experiment is upstream-immature: assess what adopting it commits us to maintaining if n0's experiment stalls.
Deliverable
An investigation doc (on this issue or linked, per repo convention) covering: the announce/lookup flow as it would work for id's public worlds; the privacy model and per-world opt-in design; address-index deployment options (run our own vs rely on discovered services); maintenance risk; and a recommendation (adopt / adapt / skip) with the follow-on implementation issue filed if the recommendation is adopt/adapt.
Acceptance criteria
- Doc answers the three bullets above with evidence (code read of the experiment repo, not just the blog).
- Recommendation is explicit; if adopt/adapt, exactly one implementation issue is filed and linked; if skip, the in-network channels from id: investigate: BitTorrent-style chunk retrieval for graph objects #2050 follow-up A are stated to be sufficient and why.
Activity
developing-today commentedon Oct 29, 2026
CODE-1126
dezren39 commentedon Oct 29, 2026
Intake review — fleet monitor, 2026-10-29
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked-up
2 remaining items
developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 5, 2026
Raw-conversation cross-link (WS-F2 mining pass, 2026-11-04). The scaling constraint this investigation must answer, in Drew's words from the peer-discovery plan review:
Three questions the investigation should treat as acceptance criteria, not background:
Related bounds already in the tracker from the other direction: #2944 (peer table bounding, closed) and #4004 (presence node-count bound, open) bound what one node stores; this comment is about what the network carries.