With the arrival of a concrete concept for how to implement hidden services using source routed onion relaying it seemed it was inevitable that this had to be part of the first implementation, and not a later feature as earlier thought.

Indra uses introducers, chosen randomly and rotated, who hold a packet of data that they can use to send a message back to the hidden service without knowing where it is. Hidden services in Tor and I2P are built on bidirectional, telescoped channels, so they have a bottleneck in that at any given time there may not be as much bandwidth to reach the hidden service as it is capable of, or needed for.

Introducers instead just accept a routing message which contains a return routing header encrypted to the hidden service, they wrap it up in the provided ciphers provided by the hidden service, and send it out using the provided routing header, which sends the message back to the hidden service.

Then the hidden service replies using the provided reply ciphers from the client, attaches the return header, then wraps this message inside a two-hop circuit (3rd is empty for this) to prevent the client unmasking the hidden service location, and it goes out over 4 hops and then arrives back at the client, with a return header ready to repeat the process, alongside whatever messages are sent back and forward.

Unlike standard hidden services, there is no middle-man, just a network of relays in between that are shuffled randomly and constantly evaluated for their odds of selection and thus payment for traffic. The introductions are switched around relatively frequently, in balance with the cost of the updates to allow new connections to be established. So long as the hidden service has credit on your session it will pass data to and fro without ever having to ask around for an introduction.

I am just about to do the return reply with reply headers as the connection message now goes from client, through two intermediate hops, to the introducer, and then another two intermediate hops and this is where the code sits right now.

The next little part is the creation of the return reply header to send to the client, and the generation of the two hop header that prevents potential unmasking by controlling the last hop. Two hops in front, and reply postage enclosed, and then the message to the service, or from the service.

It's only really one procedure, and each side, client and server, do the exact same steps in turn to form the inbound and outbound traffic path of the hidden service connection. So in a few days it will be fully tested and working.

So, end of this week I will be starting on plugging in packet segmenting and a kernel network device interface, listener and dialer, replicating/extending the tests from in memory reliable channels to semi-unreliable loop back network sockets, and starting to integrate between the p2p protocol and the relay routing protocol.

Possibly we will be close to a private alpha testnet in the next 6 weeks, without LN integrated yet but a socks 5 proxy and tunnel interface ready to connect clients to servers and peers to peers.

Very excited about getting to a point where a semi-technical user can actually see this thing in action, and there is some chance of funding and contributions in play at last.