Add back the relay

[tomaka]

#723 removed the implementation of relay which was outdated and unusable.
It should be put back.

[johan-bjareholt]

What's the progress on this? I have a use-case for this on a Rust project and would like to try prototyping it.

[tomaka]

There needs to be some API design because we need to "inject" relayed connections inside the RawSwarm.

[tomaka]

An approach could be to:

• Add a method to RawSwarm that allows injecting an "already-dialed" connection (which would in practice be a relayed substream). In other words, a method that accepts a TTransport::Output.

• On top of that, the Swarm would wrap around the Transport before passing it to the RawSwarm, so that its Output becomes some sort of Either type. All regular connections are wrapped inside Either::First, and all relayed substreams are wrapped inside Either::Second. This way, we can use the aforementioned method to directly inject a relayed substream.

• Add an associated type to NetworkBehaviour and a variant to NetworkBehaviourEvent in order t allow the behaviour to request the Swarm that it injects a substream. Adding an associated type is quite a large disruption to the API, but I guess it's ok.

• The user would have to pass their encryption layer upgrade and multiplexing layer upgrade to the RelayConfig, so that the relay can upgrade inner substreams. Alternatively, we could modify the Swarm in order to pass these upgrades at initialization.

The part that's still unclear to me is how do we handle requests for dialing addresses as /relay/.... Should they really be handled transparently? That is, do we allow addresses containing /relay/ to travel around the wire the same way as regular addresses and handle them the same way?

[tomaka]

Alternatively, we could somehow improve the Transport trait so that it's capable of plugging the relay mechanism by itself.

Instead of having the Swarm and RawSwam require Transport<Output = (PeerId, impl StreamMuxer)>, we could instead require Transport<Output = impl SomeTrait> , where SomeTrait is a trait that has some logic attached to it.

[tomaka]

Add an associated type to NetworkBehaviour and a variant to NetworkBehaviourEvent in order t allow the behaviour to request the Swarm that it injects a substream. Adding an associated type is quite a large disruption to the API, but I guess it's ok.

That cannot work.

It is theoretically possible to have a relay inside of a relay inside of a relay inside of a relay (and so on), meaning that we cannot possibly handle this in a strongly-typed manner. There must be some boxing going on there.

The new variant in NetworkBehaviourEvent should simply be a Box<AsyncRead + AsyncWrite + Send + Sync + 'static> in my opinion.

[Pierozi]

Hi, this relay implementation is regarding Circuit HOP only or also the ability for a node to dial over a p2p-circuit.

because I noticed some code related to inside ./misc/multiaddr/src/protocol.rs but I can't make it work through an existing relay.

[tomaka]

This PR covers both.

The code in the multiaddr crate can parse multiaddresses that contain p2p-circuit, but the actual relaying is what this PR implements.

[mxinden]

I am continuing this effort on the side on https://github.com/mxinden/rust-libp2p/tree/relay.

There needs to be some API design because we need to "inject" relayed connections inside the RawSwarm.

My current approach is to wrap the Transport (e.g. TcpTransport), being able to:

1. Intercept dial requests with a relayed address.

2. Inject incoming requests with the local node being the destination.

3. Intercept listen_on requests pointing to a relay, ensuring to keep a constant connection to the relay, waiting for incoming requests with the local node being the destination.