iroh icon indicating copy to clipboard operation
iroh copied to clipboard
verified publisher icon n0-computer

feat(iroh): add initial scaffolding for WebRTC support

Open anchalshivank opened this issue 4 months ago • 2 comments

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!

anchalshivank avatar Aug 18 '25 07:08 anchalshivank

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

matheus23 avatar Aug 18 '25 10:08 matheus23

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

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

  2. Refactoring correctness: Did I refactor the send_ping (and related messages) correctly so that ICE candidates are shared properly?

  3. 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?

  4. 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?

  5. 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 avatar Sep 09 '25 10:09 anchalshivank