[circuit-relay] Relay discovery

[dryajov]

Currently we're sending only one dst address to the circuit-relay, however, the relay can discover other addresses for that peer, either through the dht or by checking it's peer-book and try all it's known addrs. Alternatively (I like this better) we can also send multiple dst addrs that the peer is reachable on, from the dialer.

Edits:
Reworded

[daviddias]

In other words:

• Currently, libp2p-circuit only supports dialing with known relays (explicit on the multiaddr)
• We want to support in the future
  • Relay discovery through DHT
  • Relay discovery through trying to mount the Relay protocol with known peers

We won't support relay discovery for the first iteration.

[dryajov]

The current js implementation actually tries to mount every incoming peer muxed connection on the hop protocol and records it as a relay if it succeeds. This same mechanism is used to connect to bootstrapped relay nodes, as in - there is no circuit specific logic to connect to bootstrap circuit nodes.

[ghost]

I think eventually we'd want something like Service Routing? Where you ask the DHT to give you nodes which speak a given protocol.

Or extend Peer Routing with capabilities that are beyond "has block X", e.g. "speaks transport Y", "speaks protocol Z version 1.x",

[dryajov]

Yep, absolutely. For now this sort of passive discovery can probably fill the gap?

[RangerMauve]

Is every peer going to be capable of acting as a relay, or are there going to be community driven relay nodes out in the open?

Is there any documentation on how a peer would advertise their available interfaces on the DHT?
Should peers include relay routes among their advertised interfaces?

For the web, in order for a relay to be usable for dialing into a browser, will the browser already have to have an active connection to the relay?

[dryajov]

@RangerMauve In theory, every peer can act as a relay (configurable through options). My guess is that we'll also have some dedicated relay nodes - probably bootstrap nodes and such, as well as community ran nodes. In reality, even the browser should be able to relay connections - tho that is not yet a tested feature.

Is there any documentation on how a peer would advertise their available interfaces on the DHT?

Not as far as I know, however there are several proposals elsewhere for general purpose service discovery, tho nothing concrete yet, AFAIK. @Stebalien might have some insights here.

Should peers include relay routes among their advertised interfaces?

Thats a good question, we haven't settled on anything here yet AFAIK, but allowing nodes to communicate which relays they're connected to would help speeding up connecting to them as well as reduce network load.

One more thing worth noting here, is that there are essentially two types of relays - active and passive. An active relay would dial the destination peer, if no connection already exist to that peer, whereas a passive relay will only relay to already connected peers.

For the web, in order for a relay to be usable for dialing into a browser, will the browser already have to have an active connection to the relay?

Yes, the browser requires to have a connection to some relay in order to be "dialable".

[RangerMauve]

@dryajov Thank you for the details.
Could you possibly link me to any of these service discovery proposals?
It's kind of hard to find stuff when it's spread across dozens of repositories. :P

[RangerMauve]

Re: peers advertising relay routes

Peers already have a set of multiaddrs which they give people, since AFAIK a circuit is a multiaddr, it would be useful for a peer to advertise full circuits in order to speed up connectivity.

For browsers, it would make sense to only advertise multiaddrs with circuits since they can't accept incoming connections. (websocket/webrtc -star seems really sketchy to me because they're centralization points)

[RangerMauve]

Also, what API would one use in js-ipfs in order to discover whether a peer supports being a passive or active relay?

[dryajov]

Could you possibly link me to any of these service discovery proposals?

• Service Discovery instead of Protocol Negotiation specs#32
• feature request: add a /relay/ls protocol to swarm that yields open connections from a peer ipfs/notes#237

At least the ones I know of, I'm sure there are a few more - this is one of those things we've talked about from different perspectives, but so far haven't consolidated into anything concrete.

Peers already have a set of multiaddrs which they give people, since AFAIK a circuit is a multiaddr, it would be useful for a peer to advertise full circuits in order to speed up connectivity.

Yeah, that could be one way of doing.

For browsers, it would make sense to only advertise multiaddrs with circuits since they can't accept incoming connections.

We don't currently advertise /p2p-circuit addresses on the DHT for example, but you do get the multiaddr set with /p2p-circuit addrs (at least in js and hence the browser, I believe go is a bit different), which I believe is provided by identify (tho I might be wrong). So, in other words, that already happens, the browser does list its circuit address in its multiaddr set.

[dryajov]

There is nothing yet that would tell you if the relay is active or passive, again, the rational was that it would eventually be part of some sort of capabilities protocol, so that info was never included, tho now that I think about it, perhaps it would have made sense to advertise that as part of the CAN_HOP message.

[mpetrunic]

Closing as stale, efforts are now focused on #1029