iroh-relay 400 Bad Request from fedimint-client-wasm-bundler@0.1.1 in browser — protocol mismatch with iroh 0.91+

[jesuspirate]

Summary

Browser Fedimint clients using @fedimint/fedimint-client-wasm-bundler@0.1.1 and @fedimint/transport-web@0.1.2 (the latest published releases) fail to upgrade the WebSocket connection to iroh-relay servers, receiving HTTP/1.1 400 Bad Request.

Repro

1. Create a browser Fedimint client using the latest published SDK
2. Attempt to join any federation that uses iroh-relay (e.g. via use1-1.relay.n0.iroh-canary.iroh.link)
3. Observe browser console:

GET wss://use1-1.relay.n0.iroh-canary.iroh.link/relay [HTTP/1.1 400 Bad Request]
Firefox can't establish a connection to wss://use1-1.relay.n0.iroh-canary.iroh.link/relay

The HTTPS GET to https://use1-1.relay.n0.iroh-canary.iroh.link/ returns 200 with "This is an Iroh Relay server" — the server is alive, only the WebSocket upgrade fails.

Hypothesis

iroh 0.91.0 (August 2025) shipped wire-level breaking changes to the relay handshake protocol:
https://www.iroh.computer/blog/iroh-0-91-0-the-last-relay-break

Quoting the release notes:

"made changes to the handshake protocol to tighten up security and potentially remove a round-trip, and made changes to the messaging protocol"

It looks like use1-1.relay.n0.iroh-canary.iroh.link has been upgraded to iroh ≥0.91, but @fedimint/fedimint-client-wasm-bundler@0.1.1 still bundles a pre-0.91 iroh client. The two can't handshake.

Environment

• @fedimint/fedimint-client-wasm-bundler@0.1.1
• @fedimint/transport-web@0.1.2
• Firefox 134 (Chrome behaves identically per spot-check)
• Vite 5.4.21 bundler
• Multiple federations attempted (Bitcoin Principles, Bitcoin Life Federation, Afribit)
• Fedi mobile WORKS against the same federations (native iroh transport, not WebSocket relay)

Asks

1. Is there a planned SDK release that targets iroh ≥0.91?
2. Are there canary builds I should try that include the iroh bump?
3. Is there a workaround we can apply on our side (custom transport, alternative relay endpoint, etc.) while waiting for the SDK update?

Context

I'm building Chama (https://github.com/jesuspirate/chama), a Bitcoin-native non-custodial P2P commerce platform using NIP-44 + Fedimint ecash. Deploy at chama.satoshimarket.app. Browser support is critical for our June 2026 Nairobi launch.

Happy to test fixes, file detailed repros, or contribute. cc @alexlwn123 since you maintain the SDK.

Thanks for all the work on Fedimint.

[ngutech21]

I would recommend using the latest canary releases, as the most recent major release is already quite outdated.

[jesuspirate]

Thanks @ngutech21! Confirmed the canary fixes it on my end.

Tested 0.0.0-canary-cf43f9193627f8081b7144f7c057a7a112989031 (across all four packages: core, types, fedimint-client-wasm-bundler, transport-web) — the WebSocket upgrade to use1-1.relay.n0.iroh-canary.iroh.link/relay now completes cleanly with HTTP/1.1 101 Switching Protocols. No more 400. Console is silent on the relay path; client init proceeds normally.
Inspecting the WASM bundle's vendored deps shows iroh-relay-0.90 alongside the older 0.35 — which lines up with iroh's note that the iroh-canary relays will stay on 0.90 until 0.92 ships. The version match is what was missing in @0.1.1.
A couple of follow-on questions for planning around our June launch:

1. Is there a target timeline for a stable point release (0.1.2 / 0.2.0) that includes this iroh bump? Pinning against a canary commit hash works for testing but is harder to defend as a production dep.

2. When the iroh-canary relays roll forward to 0.92 (per iroh's release notes), is the plan for the SDK to track that transparently, or will a fresh SDK release be required?

Happy to keep testing canaries against the federations we care about (Bitcoin Principles, Bitcoin Life, Afribit Kibera) and flag regressions.
Closing thought, in case it's useful to other folks who hit this — when I unblocked WebSocket on the canary I discovered our own boot reachability probe had a separate bug (was attempting a 1-sat ecash round-trip from a deliberately-zero-balance wallet — guaranteed to miserably fail). That was being masked by the relay break the whole time. Fixed on our side in chama@v0.4.4. Not the SDK's problem, just noting the pattern in case someone else sees mysterious "federation unreachable" errors after the canary upgrade and wonders if there's a downstream story.

Happy to leave this open until you ship a stable release with the iroh bump, or close now if you prefer — whichever fits your workflow.

[MrImmortal09]

@jesuspirate , Thanks for testing this so thoroughly and for the detailed write-up, super helpful, especially the notes around the relay version alignment and the downstream probe issue you found in chama.

Right now, the bigger work underway on our side is moving away from wasm-pack toward fully UniFFI-based builds across the SDK stack. That transition will take a bit of time, so I don’t want to overpromise an exact stable release timeline yet for the iroh bump landing in a non-canary release.

In the meantime, if you hit anything else while testing, please feel free to ping me directly or open an issue. Extra coverage on these canaries is genuinely valuable while we work through the build/runtime transition.