wngr / libp2p-webrtc

WebRTC transport for libp2p (native and wasm)

libp2p-webrtc

NOTE: webrtc support has been added to rust-libp2p. browser-to-browser is not yet supported. This crate will stay as-is and not receive any maintenance efforts anymore.

WebRTC transport for rust-libp2p for both native and WebAssembly (browser). For initiating a connection between two peers, both of them need to connect to the same WebSocket signaling server (via a call to listen_on). Either one can dial the other peer by using the p2p-webrtc-star protocol. Note, that this crate is currently not interoperable with the respective js-libp2p and go-libp2p implementations.

Additional, a signaling server implementation is provided within the crate.

Quickstart

To compile this crate, you need gcc g++ libssl-dev make cmake clang pkg-config.

let base_transport = WebRtcTransport::new(peer_id, vec!["stun:stun.l.google.com:19302"]);
let transport = base_transport.upgrade()...

..

swarm
    .listen_on(
        "/ip4/127.0.0.1/tcp/8001/ws/p2p-webrtc-star"
            .parse()
            .unwrap(),
    )
    .unwrap();

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

libp2p-webrtc's Issues

Can't build in apple silicon mac

How to build it in apple silicon mac?

Host discovery

Hi, firstly, congratulations for making working implementation of the webrtc for libp2p!

I was interested in your implementation of the signalling server and I noticed that it doesn't cover exchanging the candidates for the connection. In other words, peer can connect to another peer if their addresses has been exchanged through some different channel.

What I was planning to do was to send ice candidate message to some subset of connected peers just after the websocket connection has been established with the new peer.

On the higher level, the swarm of a connected peer would produce an event, something like NewCandidate with address of the newly connected peer. That would work similarly to how snapdrop is dealing with peer discovery.

From implementation point of view it would be most reasonable to build new network behaviour (like mdns) and send candidates not even touching libp2p-webrtc transport. The problem is that the network behaviour doesn't have access to the websocket connections with peers (AFAIK).

Did you have thoughts about this problem? What are possibilities of solving it through this library?

Please let me know if my explanation was not clear or I confused any webrtc concepts.

async-tungstenite native dependancy leaks into wasm builds

async-tungstenite = { version = "0.17.1", features = ["tokio", "tokio-native-tls"] }
leaks into WASM builds. Eventually it tries to compile native TCP sockets where it fails.