Feature request: pluggable transport for iroh-relay

[FedorKiselev76]

Hi!

First of all, thanks for the great work on iroh.

I am an active iroh user and already adapt it for my own networking use cases. I would like to expand my use of iroh in constrained networks instead of replacing it with another transport stack.

I wanted to ask whether the project would consider supporting a pluggable transport for iroh-relay, alongside the existing WebSocket transport.

Motivation

As far as I understand, the current relay transport is WebSocket-based:

TcpStream
  -> optional TLS
  -> HTTP/1.1 WebSocket upgrade
  -> WsBytesFramed
  -> relay handshake
  -> ClientToRelayMsg / RelayToClientMsg

WebSocket is a good default, and I am not suggesting replacing it. But in some constrained networks, recognizable WebSocket relay endpoints may be blocked or throttled.

It would be useful to have an optional transport that keeps the same iroh relay protocol, but uses a different outer framing.

For example:

TcpStream
  -> LengthDelimitedCodec / TcpBytesFramed
  -> relay handshake
  -> ClientToRelayMsg / RelayToClientMsg

And optionally later:

TcpStream
  -> FakeTLS / Reality-like outer layer
  -> LengthDelimitedCodec / TcpBytesFramed
  -> relay handshake
  -> ClientToRelayMsg / RelayToClientMsg

Why this seems possible

From looking at the current code, the relay protocol already seems close to transport-independent:

WsBytesFramed adapts WebSocket messages into Bytes.
handshake::clientside(...) and handshake::serverside(...) operate on BytesStreamSink.
RelayedStream<S> is generic over the inner stream.
The relay messages are already encoded as ClientToRelayMsg / RelayToClientMsg.

So maybe a TcpBytesFramed transport using length-delimited frames could be added without changing the relay protocol itself.

Something like:

WsBytesFramed<T>
TcpBytesFramed<T>

Where TcpBytesFramed could be:

[u32 length][iroh relay frame bytes]
[u32 length][iroh relay frame bytes]

Questions

1. Would this kind of pluggable relay transport fit the iroh architecture?
2. Would a length-delimited TcpBytesFramed transport be acceptable as a first step?
3. If FakeTLS / Reality-like support is useful, what would be the preferred integration point?
4. If this direction makes sense, would a prototype PR be welcome?

Thanks!

[matheus23]

We have a pluggable transport API in iroh, so this could be implemented entirely outside of the iroh repository as its own standalone crate. I suggest trying that first.

One of our team members implemented a TCP-based transport once: https://github.com/n0-computer/iroh/pull/3880/changes
That uses old APIs and was implemented inside the repository for quick prototyping, but could technically be extracted to live outside as well. Perhaps that could be a starting point for you.