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 August 5, 2026, 6:45 PM ET / 22:45 UTC.

ClawSweeper review

What this changes

The draft RFC proposes an experimental Iroh-based Gateway transport so clients can pair and reconnect without a VPN.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

This remains a distinct, coherent draft RFC for a new Gateway transport and needs maintainer product direction; it is not implemented on current main. The proposed RFC number is already assigned, so the document also needs an unused identifier before it can merge.

Priority: P3
Reviewed head: 4d19511ad372e4392066464425847ae0bd3ec803
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The RFC is coherent but remains blocked on an RFC-number collision and maintainer direction for a new public transport.
Proof confidence	🌊 off-meta tidepool	Not applicable: This design-only RFC has no changed runtime behavior to demonstrate.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This design-only RFC has no changed runtime behavior to demonstrate.
Evidence reviewed	4 items	Current RFC allocation: Current main already assigns RFC 0009 to Hosted Feeds for Plugins and Skills, so the proposed Iroh document cannot retain the 0009 identifier. RFC lifecycle: Draft RFCs remain unmerged until acceptance, an implementation issue, and an updated accepted status; this PR explicitly remains a draft proposal. Allocation provenance: The existing RFC 0009 entered main in the hosted-feeds merge commit, tying the number collision to current repository history.
Findings	1 actionable finding	[P2] Assign an unused RFC number
Security	None	None.

How this fits together

OpenClaw Gateway is the server clients connect to for agent access. This RFC would add Iroh as an optional remote transport between paired clients and the existing Gateway authorization layer.

flowchart LR
  Client[Paired client] --> Ticket[Iroh setup ticket]
  Ticket --> Transport[Iroh transport]
  Transport --> Gateway[OpenClaw Gateway]
  Gateway --> Authorization[Gateway authorization]
  Authorization --> Services[Agent services]

Loading

Decision needed

Question	Recommendation
Should OpenClaw sponsor Iroh as an experimental Gateway transport, and should the first design use native Gateway framing over Iroh streams or an Iroh-to-localhost bridge?	Sponsor a native-stream experiment: Assign an unused RFC number and define native framing, pairing identity, endpoint configuration, and browser scope before implementation.

Why: The RFC deliberately leaves the public transport, pairing identity, browser scope, and security boundary unresolved; repository evidence cannot choose that product contract.

Before merge

• Add real behavior proof - Not applicable: This design-only RFC has no changed runtime behavior to demonstrate.
• Assign an unused RFC number (P2) - Current main already contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md; this document must receive an unallocated identifier before it can merge. This prior finding remains unfixed on the reviewed head.
• Resolve merge risk (P1) - Accepting an optional remote Gateway transport without an agreed framing, endpoint-identity, and authorization contract could create incompatible client setup and a new remote-exposure boundary.

Findings

• [P2] Assign an unused RFC number — rfcs/0009-iroh-gateway-transport.md:1

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
RFC scope	1 file, +112 lines	The branch is documentation-only and proposes a public transport/configuration direction rather than runtime code.

Merge-risk options

Maintainer options:

1. Resolve the transport contract before merge (recommended)
   Assign an unused RFC identifier and obtain maintainer agreement on framing, endpoint identity, and compatibility/security boundaries before accepting the proposal.
2. Defer the RFC
   Keep the proposal in draft until an owner sponsors a supported Iroh transport direction.

Technical review

Best possible solution:

Assign an unused RFC identifier and record a maintainer-approved first transport contract that preserves existing Gateway access paths and defines its authorization boundary.

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

Not applicable: this is a design-only RFC, not a report of broken current behavior.

Is this the best way to solve the issue?

Unclear: the RFC names unresolved framing and trust choices, so maintainer agreement is required before a first implementation can be considered the best solution.

Full review comments:

• [P2] Assign an unused RFC number — rfcs/0009-iroh-gateway-transport.md:1
  Current main already contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md; this document must receive an unallocated identifier before it can merge. This prior finding remains unfixed on the reviewed head.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P3: This is a speculative design RFC with no reported runtime regression or accepted implementation work.
• merge-risk: 🚨 compatibility: The proposal would add a Gateway transport, pairing identity, and configuration surface that must coexist with existing client access paths.
• merge-risk: 🚨 security-boundary: A new remote Gateway exposure path needs an explicit decision on authorization, endpoint identity, and setup-code handling.
• 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: This design-only RFC has no changed runtime behavior to demonstrate.

Evidence

What I checked:

• Current RFC allocation: Current main already assigns RFC 0009 to Hosted Feeds for Plugins and Skills, so the proposed Iroh document cannot retain the 0009 identifier. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1, af708f0ddb6f)
• RFC lifecycle: Draft RFCs remain unmerged until acceptance, an implementation issue, and an updated accepted status; this PR explicitly remains a draft proposal. (README.md:78, af708f0ddb6f)
• Allocation provenance: The existing RFC 0009 entered main in the hosted-feeds merge commit, tying the number collision to current repository history. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:11, 89cf322325b0)
• No current Iroh RFC: The current checkout has no Iroh-specific RFC or implementation; the proposal is not redundant with main. (rfcs, af708f0ddb6f)

Likely related people:

• giodl73-repo: Authored the merged hosted-feeds RFC that currently owns the 0009 identifier. (role: current RFC 0009 author; confidence: high; commits: 89cf322325b0; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
• Dallin Romney: Recent history shows RFC structure and sidecar-layout work in the repository. (role: recent RFC process contributor; confidence: medium; commits: 3aa7d727383f; files: README.md, rfcs/0000-template.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Assign an unused RFC number.
• Record maintainer agreement on the first transport framing and trust contract.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.

History

Review history (14 earlier review cycles; latest 8 shown)

• reviewed 2026-08-03T17:34:23.332Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unallocated RFC number before merge
• reviewed 2026-08-03T21:16:57.715Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unallocated RFC number before merge
• reviewed 2026-08-04T14:08:49.996Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unallocated RFC number before merge
• reviewed 2026-08-04T18:04:47.049Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unallocated RFC number before merge
• reviewed 2026-08-04T19:17:15.109Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unallocated RFC number before merge
• reviewed 2026-08-05T10:30:04.571Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Use an unallocated RFC number
• reviewed 2026-08-05T12:28:39.494Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unused RFC number
• reviewed 2026-08-05T16:32:59.868Z sha 4d19511 :: needs real behavior proof before merge. :: [P2] Assign an unused RFC number