feat(iroh): add initial scaffolding for WebRTC support #3440

anchalshivank · 2025-08-18T07:04:21Z

Hi team,

I’ve added the basic struct for WebRTC support to get things started.
Kindly guide me if this is a good direction or if there’s anything I should take care of early on.

Also, what signaling server setup would you recommend for Iroh’s WebRTC integration?

Thanks!

matheus23 · 2025-08-18T10:02:49Z

We're discussing this in the iroh discord: https://discord.com/channels/1161119546170687619/1406897550140772393

iroh/src/disco.rs

flub

I've had a quick scroll through and noticed a bunch of printlns and commented out code still. Could you add a note on what the stated of completion of the PR is, what the first round of review should pay attention to?

iroh/src/discovery/repomix-output.xml

anchalshivank · 2025-09-09T10:47:23Z

I've had a quick scroll through and noticed a bunch of printlns and commented out code still. Could you add a note on what the stated of completion of the PR is, what the first round of review should pay attention to?

This PR is still in progress - I’ll clean up the println! statements and remove the commented-out code before finalizing. For the first round of review, I’d like you to mainly focus on whether I am correctly sending the WebRTC offer/ICE candidate from one node to another.

Current flow

Node A is spawned.

Node B connects.

Node B uses discovery to send a ping .
We do share different message types ping, pong , call me may be . I added another message type.
I also need to confirm when shall the webrtc offer be exchanged.

I refactored the message-sending logic so that send_ping now also carries WebRTC ICE candidate information.

Points where I need guidance

Virtual socket: Matheus mentioned we should bind a socket. I’m not fully sure if the current approach is sufficient. I could not get intuition.
Refactoring correctness: Did I refactor the send_ping (and related messages) correctly so that ICE candidates are shared properly?
Transport mode setup: The PR currently focuses only on native WebRTC with a transport mode of WebrtcRelay. Could you check if I set up the transport modes correctly?
Socket binding intuition: In handle::new(), IP transports generate a socket address. For WebRTC, should I also bind it to some sort of socket, or is the transport abstraction enough?
WASM case: In WASM, there’s no real socket. How should I be thinking about this when extending the transport to work in WASM?

For now you can ignore webrtc actor (peer connection state ) as it needs to be changed

anchalshivank · 2025-09-10T04:07:33Z

iroh-base/src/node_addr.rs

    pub direct_addresses: BTreeSet<SocketAddr>,
+    /// Static Webrtc connection information for the node
+    pub webrtc_info: Option<WebRtcInfo>,
+}


My understanding:
NodeAddr is used by the discovery system to locate nodes in the network. For discovery purposes, we only need the node_id to find a node. Once found, WebRTC connections are established through the standard offer/answer exchange process.

My concern:
Since WebRTC connections require dynamic offer/answer negotiation anyway, is it necessary to store static WebRTC information like channel_id and webrtc_info (certificate fingerprints) here?

iroh-base/src/webrtc_port.rs

iroh-base/Cargo.toml

anchalshivank · 2025-09-10T04:14:52Z

iroh-relay/src/node_info.rs

 /// convert `&str` and `String` into `UserData` easily.
 #[derive(Debug, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)]
-pub struct UserData(String);
+pub struct UserData(pub String);


Needs to revert it back. It was a quick fix for compilation erros. #3250

iroh/src/magicsock/node_map/node_state.rs

anchalshivank · 2025-09-10T04:21:36Z

iroh/src/magicsock/node_map/node_state.rs

    ///
    /// The fallback/bootstrap path, if non-zero (non-zero for well-behaved clients).
    relay_url: Option<(RelayUrl, PathState)>,
+    webrtc_channel: Option<(ChannelId, PathState)>,


I think this is incorrect. I need more intuition on what node state , what to put it here

iroh/src/magicsock/transports/webrtc/actor.rs

anchalshivank · 2025-09-10T04:22:44Z

iroh/src/magicsock/node_map.rs

 pub(super) struct NodeMapInner {
    by_node_key: HashMap<NodeId, usize>,
    by_ip_port: HashMap<IpPort, usize>,
+    by_webrtc_port: HashMap<WebRtcPort, usize>,


I also need guidance on this part. If this is correct or needs changes

anchalshivank · 2025-09-10T04:23:58Z

iroh/src/endpoint.rs

We can ignore this file for now

iroh/src/magicsock.rs

iroh/src/disco.rs

iroh/Cargo.toml

flub

Not a comprehensive review at all, I'm just trying to orient myself a bit and start build up a mental picture of how WebRTC things work and how you integrated it.

flub · 2025-09-17T07:44:46Z

iroh-base/src/webrtc_port.rs

+/// the specific channel/connection to that node).
+///
+/// This is particularly useful when:
+/// - A node needs to maintain multiple WebRTC connections to the same peer


When would we need to maintain multiple WebRTC connections between the same two peers? My mental model was that a single WebRTC connection would transport QUIC datagrams, which can be for any number of QUIC connections. So I wasn't expecting to ever need more than one WebRTC connection between two nodes.

You are correct. I will fix this

flub · 2025-09-17T07:54:11Z

iroh-base/src/webrtc_port.rs

+/// to the same peer node. It's a 16-bit unsigned integer, allowing for up to 65,536 unique
+/// channels per node pair.
+///
+/// The channel ID space is managed by the WebRTC implementation and should be:


If managed by the WebRTC implementation why does the example show creating this from a static number? That's confusing to me. Or is it trying to show something else?

These comments need to be corrected. The main idea is that a port should be uniquely identified by both channel_id and node_id

iroh-base/src/webrtc_port.rs

flub · 2025-09-17T07:57:30Z

iroh-base/src/node_addr.rs

            relay_url: None,
+            channel_id: None,
            direct_addresses: Default::default(),
+            webrtc_info: None,


Why are these two separate fields?

This needs to be fixed.
I think we do not need webrtc info and channel id here

flub · 2025-09-17T07:59:17Z

iroh/Cargo.toml

+n0-watcher = {path = "../../n0-watcher"}
 nested_enum_utils = "0.2.1"
-netwatch = { version = "0.8" }
+netwatch = { path = "../../net-tools/netwatch" }


Is there a corresponding net-tools PR?

No, to run locally there were some dependency issue

flub · 2025-09-17T08:55:04Z

iroh/src/magicsock.rs

-                    let Some(msg) = msg else {
-                        trace!("tick: magicsock receiver closed");
-                        self.msock.metrics.magicsock.actor_tick_other.inc();
+            _ = shutdown_token.cancelled() => {


Please leave the indentation in place. Formatting in macro's is a bit pants, but let's keep it as close as we can to normal formatting. And also try and keep this diff as readable as possible, so we can see just the new branches of the select.

iroh/src/magicsock/transports/webrtc.rs

flub · 2025-09-17T09:17:21Z

iroh/src/magicsock/transports/webrtc.rs

+
+                let data = WebRtcData {
+                    channel_id: channel_id.clone(),
+                    delivery_mode: WebRtcDeliveryMode::Reliable, // TODO: Make configurable


Datagrams are unreliable. Should we not be sending these all as Unreliable? By sending QUIC datagrams inside a reliable channel we have both QUIC and WebRTC doing buffering and re-ordering. This is generally bad for congestion controllers who will start to misbehave. Yes, the relay channel has this problem too - but here we have the option of doing something better it seems.

From what I understand, in WebRTC with a live P2P connection, poll_recv just returns whatever data arrives on the channel. In the actor, that channel forwards the data straight to the msock layer, and then it shows up in process_datagram.

I think there is no quic ordering happening

I’m also a bit confused about how the WebRTC handle should be exposed to the user ,once I have a clearer picture of that, I think I’ll better understand where this QUIC reordering happens.

I think there is no quic ordering happening

The general model of iroh (for the purpose of this discussion) is that it sends QUIC datagrams over several unreliable transports. Primarily this is UDP, the transport QUIC was originally designed for. So we want to keep our transports as close to the behaviour of UDP as possible.

The user gets a QUIC API to create streams and send user data. The QUIC stack manages all things network when it builds QUIC packets and puts them in datagrams: it handles the rate at which to send them, re-sending if needed, buffering if out of order etc. So all we want from WebRTC is to give us an unreliable datagram transport to put QUIC datagrams on.

So the user never gets to see or interact with WebRTC. It's a transport iroh uses under the hood. A user should be entirely unaware of WebRTC (ideally, they will probably be aware that on native we have to bind a socket for it as I understand). The only thing it enables is that iroh can establish direct QUIC connections when at least one of the nodes is in a web browser.

flub · 2025-09-17T09:27:27Z

iroh/src/magicsock/transports/webrtc/actor.rs

+pub(crate) enum WebRtcActorMessage {
+    CreateOffer {
+        local_node: PublicKey,
+        peer_node: PublicKey,


Please use the NodeId type alias when appropriate everywhere.

The docs of NodeId should give you guidance: https://docs.rs/iroh/latest/iroh/type.NodeId.html

iroh/src/magicsock/transports/webrtc/actor.rs

feat(iroh): add initial scaffolding for WebRTC support

fb83cc8

n0bot bot added this to iroh Aug 18, 2025

github-project-automation bot moved this to 🏗 In progress in iroh Aug 18, 2025

anchalshivank added 3 commits August 19, 2025 16:17

feat(iroh): add basic webrtc implementation

908eef3

Merge branch 'main' into feature/webrtc-wasm-support

676a6b3

feat(webrtc): implement actor and sender

54e9423

matheus23 reviewed Aug 27, 2025

View reviewed changes

iroh/src/disco.rs Outdated Show resolved Hide resolved

feat(webrtc): add webrtc poll_recv, webrtc transport and webrtc sender

257bdb5

anchalshivank requested a review from matheus23 September 2, 2025 15:10

anchalshivank added 5 commits September 4, 2025 02:04

feat(webrtc): add various builder for different transports

3496a19

Merge branch 'main' into feature/webrtc-wasm-support

a559b35

fix(webrtc): fix compile errors

219915a

feat(webrtc): add webrtc initiation in ping action for disco

d4ce636

feat(webrtc): exchange offer via disco

4a358f2

flub reviewed Sep 9, 2025

View reviewed changes

iroh/src/discovery/repomix-output.xml Outdated Show resolved Hide resolved

chore(webrtc): remove repomix.xml

b87d3f8