Relay server: support listening on both WebRTC and WebSocket

[r-zig]

Description

Proposed solution:
Add configuration and implementation to allow the relay server to bind to both WebRTC and WebSocket addresses.
Use case:

Clients behind different NAT/firewall setups.
Improved interoperability with different types of libp2p implementations.
Related work:

Demonstration of JavaScript WebRTC peers connecting through the Rust relay server:
js-libp2p-examples Issue #226
js-libp2p-examples PR #227

Motivation

This work is part of a comprehensive test of WebRTC support across different libp2p implementations. The current focus is on enabling JavaScript peers to connect via a Rust relay server. In the future, the goal is to extend these tests to include scenarios where JavaScript and Rust private peers can interoperate using WebRTC through the relay. Supporting both WebRTC and WebSocket transports on the relay server will improve connectivity options and interoperability for clients using different protocols.

Current Implementation

Currently, the relay server does not listen on either WebRTC or WebSocket transports. This is needed for JavaScript peers—and, in the future, Rust peers using WebRTC—to connect to the relay server.

Are you planning to do it yourself in a pull request?

Yes

[elenaf9]

Thanks for opening the issue @r-zig.

I agree that it might make sense for a relay node to also support WebRTC and Websockets. However, I don't think that the relay example within rust-libp2p necessarily needs it.

Generally, I think we should try to keep our examples simple, e.g., in the relay example, it should just demonstrate basic configuration of a node with the relay behavior. Users can always add additional transports themselves if they need it.

That said, we also have misc/relay which is a more complex server implementation that also already supports websockets. I think adding also WebRTC support there would make sense. Did you look into that crate already @r-zig?

[r-zig]

Hi @elenaf9,
I just looked in the misc folder but didn’t find a /relay folder. I assume you meant /server — is that correct?

[elenaf9]

I just looked in the misc folder but didn’t find a /relay folder. I assume you meant /server — is that correct?

Ah yes, misc/server.

[r-zig]

Based on the Opts.config parameter, it looks like the server requires an IPFS configuration file to run properly. Is it specifically designed to work with IPFS, or is it intended as a general-purpose libp2p server?
requiring an IPFS config would limit the ability to use this relay server in scenarios where participation in the IPFS network is not desired. What would you suggest — modifying this server to be more general-purpose, or creating a new relay folder with my changes?
Thanks

[rose2221]

would like to work on this!

[elenaf9]

Based on the Opts.config parameter, it looks like the server requires an IPFS configuration file to run properly. Is it specifically designed to work with IPFS, or is it intended as a general-purpose libp2p server? requiring an IPFS config would limit the ability to use this relay server in scenarios where participation in the IPFS network is not desired. What would you suggest — modifying this server to be more general-purpose, or creating a new relay folder with my changes? Thanks

Sorry for the late reply. The server per default connects to the IPFS network, but it has a config option to disable kademlia:

rust-libp2p/misc/server/src/main.rs

Lines 34 to 36 in 4dc9431

	/// Whether to run the libp2p Kademlia protocol and join the IPFS DHT.
	#[arg(long)]
	enable_kademlia: bool,

But generally speaking, I don't think that the server needs to satisfy every use-case. It offers an implementation that is common for public libp2p nodes, but if certain features are missing or not needed users can/ should have their own implementation.