The relay protocol could be split in two about specs HOT 6 CLOSED

I agree. We wouldn't even need a CAN_HOP in this case.

Thoughts @vyzo?

from specs.

I think this was discussed during the spec development and rejected as an idea?
It's nice to be able to see if the relay hops without CAN_HOP but other than that it doesn't add much.
Also, it will be a bear to deploy as it would break existing nodes badly.

from specs.

Well, we can always support both so we don't need to break anything. However, as you said, this may be a pain to implement/deploy.

Really, my motivation is that this would allow us to split the implementation into a separate transport and relay.

from specs.

Based on discussions in libp2p/go-libp2p-circuit#67, I think the core problem is that the relay protocol doesn't model allocations.

So when a client connects to a relay, the relay has no idea if this is a NAT'ted client wishing to allocate a slot in the relay, or if it's a node wanting to connect to establish a channel to a relayed peer.

We can draw inspiration from the TURN spec (RFC5766), which models "allocations" explicitly. I think the hop/stop separation doesn't get to the root of the issue.

IMO a more correct design would be:

• A /libp2p/relay/allocate protocol that NAT'ted peers use to acquire and renew a slot in a relay, enabling them to announce a relayed address for themselves.
  A /libp2p/relay/channel protocol, that clients use to open streams against NAT'ted peers, and that the relay uses to relay that stream over to the allocated peer.

See libp2p/go-libp2p-circuit#67 (review) for related discussion.

from specs.

Has any thought been given to how a relay should respond if it doesn't want to relay data to the requested peer? (For example, no allocation has been (or will be) made to the requested peer, due to whatever policies the relay uses.)

HOP_BACKOFF is described as a temporary backoff, rather than a refusal to relay to that peer. HOP_NO_CONN_TO_DST comes close, but I can imagine situations where the relay does have a connection to the destination, but wants to reserve its scarce bandwidth or data cap for relaying only to its closest friends.

from specs.

Instead of negotiating /libp2p/relay/circuit/0.1.0 then requesting a mode, it could be a good idea to have two different protocols instead. For example /libp2p/relay/circuit/0.1.0/hop and /libp2p/relay/circuit/0.1.0/stop.

This has been incorporated in the circuit relay v2 protocol (#325), thus I am closing here. Thanks for raising it @tomaka. In my eyes this is a great improvement to the v1 specification.

So when a client connects to a relay, the relay has no idea if this is a NAT'ted client wishing to allocate a slot in the relay, or if it's a node wanting to connect to establish a channel to a relayed peer.

This is handled in the circuit relay v2 protocol via Reservations.

HOP_BACKOFF is described as a temporary backoff, rather than a refusal to relay to that peer. HOP_NO_CONN_TO_DST comes close, but I can imagine situations where the relay does have a connection to the destination, but wants to reserve its scarce bandwidth or data cap for relaying only to its closest friends.

For now this is modeled via the PERMISSION_DENIED status in the circuit relay v2 specification. Error messages can be extended by more specific entities in the future.

from specs.