RFC 0009: Iroh Gateway transport

[bjesuiter]

Summary

Adds Iroh as an optional, experimental OpenClaw Gateway transport so clients can pair and reconnect without requiring a VPN such as Tailscale.

Review focus

• Whether the first implementation should use native Gateway protocol framing over Iroh QUIC streams or an Iroh-to-localhost bridge.
• Exact Iroh fields for the setup-code payload.
• Whether paired client records should store and enforce client Iroh EndpointIds.
• Which Iroh endpoint configuration fields should be exposed 1:1 under gateway.iroh.endpoint.
• Whether browser/WASM support should be required for the first experiment or left as future work.

RFC lifecycle

• Status: draft
• Maintainer discussion thread: https://discord.com/channels/1456350064065904867/1517996004778180780
• Implementation issue: created only if accepted

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 23, 2026, 3:28 PM ET / 19:28 UTC.

Summary
Adds a draft RFC proposing optional experimental Iroh Gateway transport for OpenClaw Gateway pairing and reconnect without requiring VPN access.

Reproducibility: not applicable. this is a design RFC for a new optional Gateway transport, not a current behavior bug. The concrete check is source and GitHub state: current main lacks the Iroh RFC and already contains a different RFC 0009.

Review metrics: 2 noteworthy metrics.

• RFC files added: 1 added, 0 changed, 0 removed. The PR is documentation-only, so review should focus on RFC process, numbering, and design acceptance.
• 0009 queue state: 1 current-main RFC plus 5 open search hits. Maintainers need an explicit numbering decision before another RFC can land in the 0009 slot.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🌊 off-meta tidepool
Patch quality: 🦐 gold shrimp
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Renumber the RFC to an unused ID before merge.
• Keep status as draft until maintainers accept the Iroh Gateway transport direction.

Risk before merge

• [P1] Merging as-is would leave duplicate RFC 0009 files on main.
• [P1] The RFC is still draft with a blank implementation issue, which the README allows during review but not at merge time.
• [P1] Accepting this RFC would set direction for remote Gateway exposure, Iroh endpoint config, persisted key handling, token pinning, and audit expectations, so maintainers need to own that product/security decision.

Maintainer options:

1. Accept, Renumber, Then Merge (recommended)
   If maintainers accept the Iroh Gateway direction, choose an unused RFC number and update filename/frontmatter/lifecycle metadata before merge.
2. Hold Draft Review
   Keep the PR open as a draft while maintainers decide whether this remote Gateway transport belongs in the roadmap.
3. Defer Iroh Direction
   Close or pause the PR if maintainers do not want Iroh Gateway transport to become near-term OpenClaw direction.

Next step before merge

• [P1] The remaining action is maintainer RFC acceptance and numbering judgment, not an autonomous repair lane.

Security
Cleared: The diff is Markdown RFC text only and adds no executable code, dependencies, workflows, secrets handling, or supply-chain behavior.

Review findings

• [P2] Renumber this RFC before merge — rfcs/0009-iroh-gateway-transport.md:1

Review details

Best possible solution:

Keep the PR open for maintainer RFC review; if accepted, assign an unused RFC number, update lifecycle metadata and the implementation issue, then merge the accepted design.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a design RFC for a new optional Gateway transport, not a current behavior bug. The concrete check is source and GitHub state: current main lacks the Iroh RFC and already contains a different RFC 0009.

Is this the best way to solve the issue?

No for merge as-is. An RFC is the right vehicle, but this branch needs maintainer acceptance, an unused RFC number, and lifecycle metadata updates before it is merge-ready.

Full review comments:

• [P2] Renumber this RFC before merge — rfcs/0009-iroh-gateway-transport.md:1
  Current main already contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md, and other open RFCs still reference the 0009 slot. Merging this added file as another 0009 RFC would leave ambiguous RFC IDs, so the file and frontmatter need an unused RFC number before merge.
  Confidence: 0.96

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 89cf322325b0.

Label changes

Label justifications:

• P3: This is a draft design-only RFC with no runtime change and low immediate user impact.
• merge-risk: 🚨 other: Merging as-is would record duplicate RFC numbering and unaccepted remote-Gateway product/security direction.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The PR changes only an RFC document in the RFC repository, so runtime behavior proof is not applicable before design acceptance.

Evidence reviewed

What I checked:

• Target AGENTS.md check: No AGENTS.md exists in the target openclaw/rfcs checkout, so no target-specific AGENTS policy applied. (89cf322325b0)
• PR head adds draft Iroh RFC: The proposed file is draft, has a blank implementation issue, and points rfc_pr at this PR. (rfcs/0009-iroh-gateway-transport.md:7, 4d19511ad372)
• RFC lifecycle policy: README says draft RFCs should not merge, and accepted RFCs need accepted status plus an implementation issue before merge. (README.md:80, 89cf322325b0)
• Current main already has RFC 0009: Current main contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md, so this PR's added 0009 file collides with an existing RFC number. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1, 89cf322325b0)
• Canonical search: Open 0009 search found adjacent RFC queue items, but none implements or supersedes Iroh Gateway transport.
• Gateway exposure context: Current main policy text already treats Gateway exposure as an operator-facing posture area, which is adjacent to this RFC's remote Gateway exposure direction. (rfcs/needs_refactoring/policy-conformance.md:87, 89cf322325b0)

Likely related people:

• kevinlin-openai: Blame and log history tie the current RFC lifecycle and metadata guidance to this contributor. (role: RFC process contributor; confidence: high; commits: e366ea9825a4, bbb4058da234, f4fdf38f4717; files: README.md, rfcs/0000-template.md)
• Gio Della-Libera: Recent main history includes the merged RFC 0009 file and Gateway exposure policy context relevant to this proposal's numbering and security posture. (role: adjacent RFC and Gateway exposure contributor; confidence: high; commits: 89cf322325b0, 0e353436f90b, e46c2a113cc9; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md, rfcs/needs_refactoring/policy-conformance.md)
• Dallin Romney: Recent history updated README/template sidecar structure that governs new RFC shape and supporting material. (role: recent RFC structure contributor; confidence: medium; commits: 3aa7d727383f, 0cee55564c0c; files: README.md, rfcs/0000-template.md, rfcs/0007-e2e-qa-lab-scorecard-consolidation.md)
• Omar Shahine: Recent main history includes renumbering and frontmatter alignment work for another RFC, relevant to resolving the duplicate-number blocker. (role: recent RFC renumbering contributor; confidence: medium; commits: bab3348050f7, f346050b2878, 4b98ff01752e; files: rfcs/0002-approval-prompt-markdown.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.