When building multi-hop relayed connections, there can be multiple modes for how exactly to dial. There are two obvious modes, but both of them are currently blind spots in the circuit relay spec.

(All kinds of other modes are also possible -- these two are just the most obvious ones.)

Hop-by-hop dialing

• How it dials, given A->R1->R2->B
  1. A connects to R1
  2. A builds A->R2 connection, via R1
  3. A builds A->B connection, via R2
• Formula
  • Relay(Relay(Relay(A, R1), R2), B)
• Properties
  • A only sends the very next hop's multiaddr as the header
  • A is in full control of the circuit
  • A doesn't rely on /hop support on R1 or R2
  • More resource-intensive the more hops there are, light clients will probably rather use deferred dialing
  • Slight overhead per hop due to multiple crypto channels and stream muxers.
• Naming
  • previously dubbed "onion", which we shouldn't use anymore due to confusion with Tor.
  • proposal: matreshka (russian doll)
  • proposal: shallot (small onion, pic)

Deferred dialing

• How it dials, given A->R1->R2->B
  1. A connects to R1
  2. R1 connects to R2
  3. R2 connects to B
  4. R1 builds R1->B connection, via R2
  5. R1 builds A->B connection, via R1->B
• Formula, Header
  • Relay(A, Relay(R1, Relay(R2, B)))
• Properties
  • Depends on R1 and R2 allowing passing /p2p-circuit addresses as headers
  • Resource-saving on A, good for light clients
  • Slightly less overhead from multiple crypto channels and stream muxers
• Naming
  • previously dubbed "telescope", which is a good name. I2P's relay construction is called the same and operates similarly, but with I2P the name isn't part of the branding (as with Tor), so it's fine to use it too.