webrtc-websys: implement `webrtc` protocol for browser-to-browser communication

[DougAnderson444]

Description

With #4248, we've implemented a websys-based version of the WebRTC-direct protocol via browser bindings. To keep the scope of the PR small, the webrtc protocol which allows for browser-to-browser connections has not been implemented. This issue tracks the implementation of that protocol in the webrtc-websys transport.

Spec is: https://github.com/libp2p/specs/blob/master/webrtc/webrtc.md

[retrohacker]

I'm interested in tackling private<->private :hand:

[DougAnderson444]

Awesome @retrohacker! I don't think there is a pull request open for this yet. Are you going to spin one up to get it going?

[retrohacker]

Yes, but currently not sure where to start :sweat:

Going to spend some time studying your PR and the spec to get a better idea.

Still new to rust and rust-libp2p

[dariusc93]

If you still interested in tackling it but need help dont be afraid to ask for it @retrohacker :)

[ferrohd]

Hi, I'm joining the wasm-wagon.

Note: I'm still learning the library, so the following could be total nonsense.

I was trying to implement the webrtc-signaling protocol defined in the specification but with no luck.

By spec, once the two parties have established a relayed connection, webrtc-signaling is run on top of it to exchange SDP offers/answers. From what I understand, in the rust-libp2p a protocol is defined by means of implementing the NetworkBehaviour trait, and that would be the case for webrtc-signaling(?).

The naive solution I thought of was to wrap relay with a custom Behaviour that relays only SDP packets. Similar to the relay protocol, there would be a client that lives at the end of a relayed connection and sends/receives SDP packets, and a relay that is a node able to relay such packets to other clients. I ran into some difficulties because relay doesn't expose the complete protocol implementation, and that would have to be rewritten as carbon copy in webrtc-signaling (not very Idiomatic™).

But at the same time, WebRTC is a transport and should be agnostic about which protocol runs on top of it, still it depends on webrtc-signaling which would be a protocol, and this is wrong(?).

What am I missing? I feel completely off track.

[ferrohd]

Is anyone working on this?

[DougAnderson444]

I don't think anyone has started working on it, no. Although there seem to be a few people interested.

For anyone who wants to start, the recommended way is to

1. fork the repo
2. start a feature branch on that fork
3. create a draft pull request, linking to this issue

This way we can all follow along, review, and contribute as time allows.

[DougAnderson444]

If you have the capacity to start, I highly recommend it!

Even if you don't know that much Rust or libp2p it's a great way to learn and gather feedback from others in the community.

[LF-Flores]

Hello @DougAnderson444! Coincidentally, all this past week I have been working with reaching browser-to-browser communication in mind (specifically, I want to achieve chrome extension to chrome extension communication).

What I have done up to this point is:

• Ran, studied and refactored (for my clarity) the browser-webrtc example, as well as the distributed-key-value-store and file-sharing examples, so I feel I understand fairly well their design.
• Studied the webrtc-websys and webrtc crates on the transport folder.
• Noticed that one (apparent to me...) obstacle to reach browser-to-browser communication is to properly setup the webrtc_websys::Transport::new method to create a cert-hash certificate just as the webrtc one currently does. Specifically:

Have something like this for the webrtc_websys case:

...
    SwarmBuilder::with_new_identity()
      .with_tokio()
      .with_other_transport(|id_keys| {
        Ok(
          webrtc::tokio::Transport::new(
            id_keys.clone(),
            webrtc::tokio::Certificate::generate(&mut thread_rng())?,
          )
          .map(|(peer_id, conn), _| (peer_id, StreamMuxerBox::new(conn))),
        )
      })?
      .with_behaviour(|_| ping::Behaviour::default())?
      .with_swarm_config(|cfg| cfg.with_idle_connection_timeout(Duration::from_secs(u64::MAX)))
      .build(),
...

(Focus on the webrtc::tokio::Certificate::generate(&mut thread_rng())? line).

Here is where I would like to ask for initial guidance. My current plan so to implement this certificate functionality in webrtc_websys but want to check if my intuition is correct.

In any case, I can create the draft pull request linking here! (pointing to merge to master, right?) :) Thanks in advance!!

[DougAnderson444]

Hey @LF-Flores, great to see you here too.

Another resource to check out if you haven't already is how the JavaScript implementation of browser-to-browser works (no need to re-invent the wheel, it should similar steps but just in Rust instead of JS)

I don't think implementing the Certificate functionality is needed, as the browser websys can already connect to the Rust WebRTC server, it's just the circuit relay parts that need to be designed and coded in. @ferrohd's idea behind a custom relay sounds interesting, I don't think there's necessarily consensus on how best to approach it though. Maybe @thomaseizinger has some suggestions before we start cracking?!

[thomaseizinger]

Another resource to check out if you haven't already is how the JavaScript implementation of browser-to-browser works (no need to re-invent the wheel, it should similar steps but just in Rust instead of JS)

Correct, you'll need to use web-sys to bind to the corresponding browser APIs, like RtcPeerConnection.