That's a clearnet "Bob" on the right hand side of that diagram, not a hidden service.

You can clearly see that there is two hops to the Rendezvous point and another three hops from there to the hidden service.

From here:

https://community.torproject.org/onion-services/overview/

In Indranet, the randomly chosen intermediary does not do routing but only delivers regularly updated routing header packets to deliver to nodes requesting them, and these requests run over a standard 5 hop circuit (out and back with two in between), hiding the location of the client, which then can use this packet at the front of their messages to the hidden service.

The header packet provided by these nodes, which will be called "Introducers" contains the forward path, the first, second the destination hops, wrapped in encryption that only the first hop can decode. Note that this outbound path is paid for by the hidden service also, but the client adds and extra 3 hops which provides the hidden service with a return path for the messages.

It's good to have people asking meaningful questions, since this explanation made me realise that as it stands, alone, the client can construct return path that could unmask the hidden service's real IP address.

The first thought that pops into my head is that this means the exit must prefix its return path BEFORE the provided return path.

So actually, Indra winds up with 9 hops in the hidden service circuit if that is how it will be implemented.

It may work out better since it's 6 hops versus 9, to go with the same basic model as Tor. That was how I originally envisioned it, but this new idea has a big hole that I didn't think of. It might not require 3, but only two hops in the server's first part of the return header, not the full 3.

Those seem to be the two options with the source routed connections, 8 hops or 6 intermediated by a rendezvous point.

The difference between them may not be so great as to make any real effective difference.

Oh, of course, 6 sounds better than 8, but on the other hand, the rendezvous point's load level may cause congestion to these packets as it is busy also generally relaying traffic around.

It seems to me like the alternatives need a suite of tests to determine what is better. And there may be another idea yet that gets around this problem, still hiding the last two hops of the return path but allowing a shorter overall path. Nothing occurs to me right now thinking about it.

The main advantage of the 8 hop path would simply be that the rendezvous traffic would not be as dependent on the responsivity of the rendezvous points, since they would be probabilistically selected from the nodes the peer knows are not too busy.

Thanks for the detailed replies! I deleted my comment asking about 3 vs 6 hops because I remembered that hidden service routes do have more than 3 hops in between (while routes to clearnet destinations are 3 hops). Glad it ended up being a helpful question anyways :)

Sorry that was a bit of a stream of consciousness. After explaining the problem to the Super Shadowy Sponsor guy I decided that even still the notion of introducers serving up new forward paths is still better overall.

The reason being that at any one time, all of the rendezvous points chosen by the hidden service could be very busy, not only with the hidden service traffic but also the general network relaying traffic.

And the sum bandwidth capacity of the chosen rendezvous points may not be nearly as high as the exit node can handle. Relays can advertise claimed capacities to the network, but this can be lies, whereas averaging it out over the whole network puts the inbound capacity at the average of the network as a whole, which is likely higher than a worst case rendezvous point relays sum capacity at a given time, by definition. Latency is a major enemy in my design thinking. I want to create a protocol that can become as ubiquitous as TCP/IP itself, which is something of an unfair competition, but it helps me evaluate design options under one razor that can rule out bad options quickly due to their latency cost.

The network would not be able to quickly adapt to this, as introducer points can only have their updates at the speed of the p2p DHT network's propagation rate. So until the hidden service changes its rendezvous points, traffic to it could be limited by an unfortunate choice of rendezvous points.

In contrast, the 8 hops, 3 forward provided by the hidden service, two first hops back by the hidden service, and 3 more including the last layer for returning to the client, can be chosen by both sides out of less busy relays based on both the p2p DHT network propagation of congestion information, and the direct data gathered via onion circuit paths about the level of utilisation of each of the relays. In fact, this information would be a logical component of the chatter between relays, reporting to each other their utilisation level.

The gathering of such data on an anonymity network is full of gotchas related to leaking contemporary data about the exits, especially, that a client is connecting to. As such, only exit relays used by a client report their current utilisation value, but because the client is constantly chosing new exit points for services that have many relays providing, this traffic can update the information of the client about the recent congestion state of the relays and feed into their probabalistic selection of nodes for any given message.

So, overall, I'm leaning very heavily towards the 2 hop first layer to be provided by the hidden service, and the 3 hops provided in the outbound message for delivering the return, because it fits in better with the congestion mitigation strategies that provide a stronger guarantee of low latency for users.

I originally wasn't going to focus much on this facility in the protocol, but when the "oh but they could just deliver short time valid outbound paths" thought occurred, I got all excited because it seemed at first like a better option than static and slowly changing rendezvous points forwarding traffic between the endpoints. But I think that in terms of reliability and latency minimisation, the 8 hop idea works out better.