id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249

Activity

1. dezren39

   added

   app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)

   on Oct 29, 2026
2. developing-today commented on Oct 29, 2026

   

   developing-todayBot

   on Oct 29, 2026 – with developing.today

   Contributor

   More actions

   CODE-1115
3. github-actions

   assigned

   dezren39

   on Oct 29, 2026
4. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   on Nov 3, 2026
5. dezren39 commented on Nov 3, 2026

   

   dezren39

   on Nov 3, 2026

   MemberAuthor

   More actions

   🤖 Agent note · state: triaged — gate check and scope record (queue task 7864)

   Verdict: still live, not superseded, and correctly gated. No implementation starts now.

   Fresh state (2026-11-03T13:4xZ, gh reads)

   • id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 OPEN, labels app/id only, unchanged since 2026-10-29T11:53Z. No branch or PR owns it: repo-wide code search finds no iroh-gossip usage outside doc/ spikes; the only PR mentioning id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 is docs(id): bridge semantics investigation — hosted (HTTPS/WS) ↔ native (Iroh) seam (#2058) #2277 (merged docs: bridge semantics investigation, id: investigate: bridge semantics — hosted (HTTPS/WS) edition syncing with native Iroh nodes #2058).
   • Its declared gate, id: design: ID messaging/relay protocol v1 #2036 (ID messaging/relay protocol v1), now has a merged design: PR design(id): #2036 messaging/relay protocol v1 #3833 merged 2026-11-02T15:51Z, doc doc/2026-11-01_design_id2036.md on main. id: design: ID messaging/relay protocol v1 #2036 itself stays open as the synthesis parent.
   • The design sets a second, narrower gate on this issue (§6, verbatim): "The bridge PoC id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 may proceed only against phase 3's reviewed envelope and must not become production code before review."
   • Phase 3 is id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 (relay envelope + hop records over iroh-gossip for chained messages) — OPEN and status/blocked as of 2026-11-03T13:29Z. Its blocker is a queue bookkeeping defect, not a design question: task 5786 sits blocked and holds the canonical dedupe key, so the validated part-A packet (hidden_files/packet-3796-part-a-types.json) deduped onto it and no successor was created (issue comment 2026-11-03T12:18Z).
   • Phases around it: id: protocol v1 phase 1 — session header + segment checkpoint event kind (#2036) #3794 closed (phase 1 landed), id: protocol v1 phase 2 — PoC: intermittent-signature live stream for collaborative editing (#2036) #3795 parked (phase 2), id: protocol v1 phase 4 — retention and compaction for the event store (#2036) #3797 in progress (phase 4).

   Why the PoC cannot start

   The issue's own deliverable list requires origin-signed envelopes + prev-hash chaining, signed hop records appended per relay, dedupe by message ID, and an enforced hop cap. Those are exactly the artifacts #3796 defines. Building the five-node harness first would decide the envelope and hop-record shape inside PoC code — the failure mode #2036 §6 and the #2035 deliverable rules forbid ("do NOT build the permanent feature on top of an unreviewed PoC").

   Scope, recorded for when the gate opens (do not implement now)

   • Location: a new PoC under pkgs/id spikes (no production crate wiring); existing iroh work is only doc/2026-10-11T.../spikes/*, which are reference, not a base.
   • Topology: A, B, C, D mutually visible; E reachable only via D; E isolated from A/B/C at the application layer.
   • Behaviour: chained-class fan-out over iroh-gossip; D bridges to/from E by the same rule (fan-out to visible neighbours excluding the arrival neighbour); origin signature over content/prev-refs/group/sequence; hop record outside the signed envelope; dedupe by message ID; four-hop cap.
   • Measurements to record in the PoC report: delivery completeness to E; duplicate rate at E when a second bridge appears; direct vs one-bridge-hop latency.
   • Refusal vectors: tampered relayed copy rejected at ingest; two-bridge duplicates collapse to one delivery; relay forwards at most once per message and refuses its own prior hop.
   • Report links back to id: design: ID messaging/relay protocol v1 #2036; explicitly not the permanent feature.

   Ordering / blockers

   1. id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 part A — envelope, stable message ID, hop-record types (task 5786: re-scope or cancel-and-re-enqueue, per the 12:18Z correction note).
   2. id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 part B — gossip topic derivation, membership/ingest gate, validate-before-forward seam, bridge integration test.
   3. id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 — this PoC, against the reviewed id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 envelope.
   4. Review of the PoC report before anything here becomes production code.

   Resume condition: #3796 closed/merged (envelope reviewed). Until then this issue is dependency-blocked; the queue task closes as triaged and no worker should claim it for implementation.
6. dezren39

   added

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   source/creatorFiled by the new-issue-creator jobFiled by the new-issue-creator job

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   task/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item

   and removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   on Nov 3, 2026
7. developing-today commented on Nov 3, 2026

   

   developing-todayBot

   on Nov 3, 2026 – with developing.today

   Contributor

   More actions

   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/none). 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
8. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   on Nov 3, 2026
9. dezren39 commented on Nov 3, 2026

   

   dezren39

   on Nov 3, 2026

   MemberAuthor

   More actions

   🤖 Agent note · triaged (task 8601, lane code-k, direct)

   • Agent: queue worker (repo-worker-code), lane code-k
   • Session / ID: task 8601
   • Found via: queue claim (coverage pass re-queue)

   Triage verdict — still live; the design gate has cleared since the last triage, and the practical predecessor is now issue #3796.

   What changed since task 7864's gate check (2026-11-03T13:45Z):

   • The id: design: ID messaging/relay protocol v1 #2036 design gate is cleared. Issue id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 forbade starting until id: design: ID messaging/relay protocol v1 #2036's protocol v1 design was reviewed, so the PoC could not make the protocol's decisions itself. That design now exists and landed: synthesis record on issue id: design: ID messaging/relay protocol v1 #2036 plus the fuller design note merged via PR design(id): #2036 messaging/relay protocol v1 #3833 (MERGED, re-verified by task 8583 at 20:24Z today). id: design: ID messaging/relay protocol v1 #2036 stays OPEN only as the protocol v1 parent while its phases land.
   • But the PoC's direct predecessor is still open. The five-node relay PoC verifies origin-signed envelopes, signed hop records and dedupe — that format is phase issue id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 (relay envelope + hop records), still OPEN with its own queue task. Phase 1 id: protocol v1 phase 1 — session header + segment checkpoint event kind (#2036) #3794 is CLOSED; id: protocol v1 phase 2 — PoC: intermittent-signature live stream for collaborative editing (#2036) #3795 (a different, live-stream PoC) and id: protocol v1 phase 4 — retention and compaction for the event store (#2036) #3797 are also OPEN. Building id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249 before id: protocol v1 phase 3 — relay envelope + hop records over iroh-gossip for chained messages (#2036) #3796 lands would re-create exactly the protocol-deciding problem the gate existed to prevent, one level down.
   • Nothing is started: no branch or PR owns id: poc: five-node bridge relay over iroh-gossip — chained fan-out via a single bridging member #2249, and no iroh-gossip usage exists outside doc/ spikes (task 7864's search, unrebutted since).

   Ordering (recorded per the packet): #3796 lands → #2249 is unblocked and ready to implement as written (its acceptance checklist is complete and needs no rescoping). No new packet is enqueued from this triage — the blocker is a live sibling with its own task, and #2249 will re-queue through coverage; this note is the ordering record the next claim should resume from.

   Issue stays OPEN. Status: triaged.
10. dezren39

    added

    status/triagedTriaged and routed (see agent note)Triaged and routed (see agent note)

    and removed

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    on Nov 3, 2026