Repository navigation
id: holder discovery for blob hashes — provider table, gossip announcements, wire the blob gate #2260
Description
Parent: #2050 (investigation: BitTorrent-style chunk retrieval for graph objects), epic #2056. Follow-up A of the #2050 investigation (full text on #2050, 2026-10-29).
Problem
pkgs/id can discover servers but not content. src/discovery.rs gossip announcements (id-peer-discovery-v1, 30s announce / 120s stale) carry peer presence only — nothing says which blob hashes a peer holds. And the blob access gate in src/blob_gate.rs (fetch/observe decided by membership in a world referencing the hash; observe answers size + held ranges) is not wired into id serve because its WorldAccess reference index (hash → worlds referencing it) "has no producer yet" (blob_gate.rs module doc).
Without a hash→holders index, multi-holder retrieval (#2050 follow-up B) has nobody to schedule from, and holder queries cannot be answered safely for private worlds.
Scope
- Provider table in
pkgs/id: hash → set of (EndpointId, held-ranges summary: complete / ranges / unknown, last-seen), fed by (1) world/doc sync state — peers observed Complete for a hash, the pattern iroh-docs'ProviderNodesuses for iroh-blobs'ContentDiscoverytrait — and (2) gossip holder announcements on the existing discovery plane (per-world; full hash sets for small worlds, a compact summary format for large ones — choose and document the format). - Produce the blob_gate reference index from the world graph (artifacts/documents naming a hash) and wire
blob_eventsintoid serveso fetch/observe are gated as designed. Refusals must stay indistinguishable for unknown vs forbidden hashes; observe stays off by default and world-narrowable only downward. - A public server for a world must be able to answer holder queries for that world from its provider table (the rendezvous role in id: investigate: BitTorrent-style chunk retrieval for graph objects #2050 §2, channel 3).
Acceptance criteria
- A node that holds none of a world's blob can obtain a candidate holder list for its hash from sync state, gossip announcements, or the world's public server.
id serveenforces the blob gate on get/get_many/observe with the reference index populated; tests cover member-allowed, non-member-refused, and unknown-hash-indistinguishable cases.- Holder announcements never leak holdings of a membership-gated world to non-members.
- Stale holders expire on the discovery plane's existing announce/stale cadence shape.
Not in scope: the retrieval scheduler itself (follow-up B), global/Mainline discovery (follow-up D).
Activity
developing-today commentedon Oct 29, 2026
CODE-1123
dezren39 commentedon Nov 1, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked-up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · escalated
LocalEvents::publishwritesgroup=None;EventStore::documents()exposes no world binding;id servehas no authoritative membership source for these documents; existing discovery is a shared public topic with self-asserted peer announcements. Public holder announcements would risk leaking private-world holdings.doc/2026-11-01T17-10-00Z_investigation_id_holder_discovery/2026-11-01T17-10-00Z_investigation_id_holder_discovery.mdin the task worktree on branchqueue/5806-2260-id-holder-discovery; source refspkgs/id/src/local_events.rs:201-211,pkgs/id/src/event_store/documents.rs:31-77,pkgs/id/src/commands/serve.rs:858-863.cargo test --no-default-features --features world --test blob_gatepassed (8 passed, 0 failed) innix develop ./pkgs/id; no implementation tests, since no code changed.