Repository navigation
id: investigate: bridge semantics — hosted (HTTPS/WS) edition syncing with native Iroh nodes #2058
Description
Source: the Cloudflare Workers fit investigation (on #2044) open question 2. The Workers edition speaks signed objects/graph/journals over HTTPS/WebSocket; native nodes speak Iroh/QUIC. Design the bridge: who bridges, ordering and conflict semantics across the seam, replay/journal interop, and how the trust model (signatures are transport-independent) is preserved end to end.
Program: Drew's 2026-10-28 directive (full text: hatch-personal memory/topics/id-program-2026-10-28.md). Parent epic: #2056.
Working pattern: parallel investigations, then the named synthesis issue merges them into a full design. Route guidance: Workhorse by default; Specialist/Summit for synthesis and ramification-heavy work. A result that says "done" is not the endpoint — the orchestrator reviews it and may commission another round. Deliverables: a markdown design/investigation doc (mermaid/SVG diagrams welcome) linked from this issue, plus follow-up issues for anything buildable. Build a proof of concept where the design calls for one, but do NOT build the permanent feature on top of an unreviewed PoC.
Acceptance criteria
- A written bridge-semantics investigation exists: who bridges hosted (HTTPS/WS) and native (Iroh/QUIC) editions, with ordering and conflict semantics across the seam
- Replay/journal interop and the transport-independent trust model (signatures end to end) are addressed explicitly
- Open questions that block the serverless-edition design (id: design: ID serverless edition v1 (Cloudflare Workers) #2046) or chat/boards syntheses are named with owners
Activity
dezren39 commentedon Oct 29, 2026
Parent epic: #2056 — ID platform expansion (2026-10-28 directive). Filed as batch 2 from PREPARED-ACTIONS.md.
developing-today commentedon Oct 29, 2026
CODE-979
dezren39 commentedon Oct 29, 2026
Intake review
Part of the ID platform expansion program (parent epic #2056; source: the Cloudflare Workers fit investigation on #2044, open question 2). Filed by Drew 2026-10-28; no merged PR or commit resolves an investigation of this kind. Suggested approach: follow the program's working pattern — a bounded investigation write-up on this issue, feeding the named synthesis issues. Risk: bridge semantics decided implicitly by an implementation later; this investigation is the cheap place to pin ordering/conflict rules.
— repo-fleet-monitor intake enrichment (protocol §5): acceptance criteria appended to the body where missing, labels normalized,
meta/enrichedapplied.dezren39 commentedon Oct 29, 2026
Top priority — ID program wave-1. Drew directed this be picked up in the next runs (2026-10-29): enqueued directly as triage task 3360 in repo-health-code-pilot at queue priority 20 (only breakage-class work at priority 10 outranks it). Wave-1 is the ungated investigations and designs; syntheses and PoCs stay gated on their named inputs. Investigation route: Workhorse.
dezren39 commentedon Oct 29, 2026
🤖 Agent note · picked up
doc/linked from this issue plus routed follow-on work.dezren39 commentedon Oct 29, 2026
🤖 Agent note · done (investigation delivered; PR awaiting CI)
Investigation result — bridge semantics (#2058)
Verdict: the bridge is a sync peer, not a translator or a proxy. Ordering and trust already live entirely in the signed event layer (
pkgs/id/src/chain.rs: per-author sequence + backlink + signedaftercausal frontier, domain tagid.events.v1;envelope_net.rs: "The payload's signature is what makes it trusted, not the iroh node that delivered it"). The seam needs a new transport for the existing sync sessions — not new semantics — under three rules: no bridge-assigned ordering, no bridge-held trust, no authoritative snapshot.Request/Answernegotiation and the same measured LogSync/range crossover (~3.5% of chain count,sync_method.rs) — the rule is about set difference, not transport. Bridge-only additions are transport-level: resumption from the store's own(author, seq)positions (needed because DO invocations are CPU-capped and sockets hibernate), and blob bytes on a separate HTTPS/R2 leg by hash, never inside the event session.after); arrival order is not semantics and wall-clock receipt time must never become a tiebreak, or hosted and native replays of the same set diverge.event_store/). The one real seam hazard:LogSynccompares heights, not heads, so it cannot see a fork (log_sync.rs) — a bridge relationship that only ran LogSync could carry a forked prefix indefinitely while both sides report "in sync". Rule: bridge relationships must run the proof-carrying exchange on a cadence (bootstrap, after any refusal, periodically). The DO's single-writer serialization does not prevent author forks (an author signs from any device), so "last writer wins by arrival" on the hosted side would be a silent divergence — explicitly ruled out.ingest_batchchunks, positions as cursor) to fit CPU caps, with identical results (tested by the PoC, id: poc: bridge sync session — native store ↔ DO-shaped SQLite store over WebSocket, fork-proof exchange + withholding detection (from #2058) #2276). DO point-in-time bookmarks are operator disaster recovery for the hosted copy only — never a substitute for the signed journal.afterfrontiers reference missing hashes), so it is an availability attack with proof, not an integrity attack. Allowed-writer filtering stays a view rule on both editions; custodial signing keys stay rejected.Open questions blocking downstream designs (owners named)
Not blocking: SSO→ID binding / key recovery (#2258, from #2045); native multi-hop relay (#2035, PoC #2249) — distinct from this hosted seam.
Follow-on routed
PoC filed as #2276: bridge sync session native store ↔ DO-shaped SQLite store over WebSocket, reusing
ingest_batch+ resolve unchanged; acceptance covers two-way convergence, cross-seam fork detection via proof exchange, withholding detection, and replay-identity between editions. Docs PR: #2277.