Skip to content

Relay server: support listening on both WebRTC and WebSocket #6029

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
r-zig opened this issue May 22, 2025 · 4 comments · May be fixed by #6030
Open

Relay server: support listening on both WebRTC and WebSocket #6029

r-zig opened this issue May 22, 2025 · 4 comments · May be fixed by #6030
Labels
decision-pending Marks issues where a decision is pending before we can move forward.

Comments

@r-zig
Copy link
Contributor

r-zig commented May 22, 2025

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

@r-zig r-zig linked a pull request May 22, 2025 that will close this issue
4 tasks
@elenaf9
Copy link
Member

elenaf9 commented May 22, 2025

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?

@elenaf9 elenaf9 added the decision-pending Marks issues where a decision is pending before we can move forward. label May 22, 2025
@r-zig
Copy link
Contributor Author

r-zig commented May 23, 2025

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
Copy link
Member

elenaf9 commented May 23, 2025

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
Copy link
Contributor Author

r-zig commented May 23, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decision-pending Marks issues where a decision is pending before we can move forward.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants