Torguard - Keep your identity private online!
To Do List - I2P
Skip navigation

To Do List

I2P Project Targets

Below is a more detailed (yet still incomplete) discussion of the major areas of future development on the core I2P network, spanning the plausibly planned releases. This does not include stego transports, porting to wireless devices, or tools to secure the local machine, nor does it include client applications that will be essential in I2P's success. There are probably other things that will come up, especially as I2P gets more peer review, but these are the main 'big things'. See also the roadmap. Want to help? Get involved!

Core functionality [link]

Security / anonymity [link]

Performance [link]

Core functionality

To do this, peers who have no IP address simply connect to a few peers, build a tunnel through them, and publish a reference to those tunnels within their RouterInfo structure in the network database.

When someone wants to contact any particular router, they first must get its RouterInfo from the network database, which will tell them whether they can connect directly (e.g. the peer has a publicly reachable interface) or whether they need to contact them indirectly. Direct connections occur as normal, while indirect connections are done through one of the published tunnels.

When a router just wants to get a message or two to a specific hidden peer, they can just use the indirect tunnel for sending the payload. However, if the router wants to talk to the hidden peer often (for instance, as part of a tunnel), they will send a garlic routed message through the indirect tunnel to that hidden peer which unwraps to contain a message which should be sent to the originating router. That hidden peer then establishes an outbound connection to the originating router and from then on, those two routers can talk to each other directly over that newly established direct connection.

Of course, that only works if the originating peer can receive connections (they aren't also hidden). However, if the originating peer is hidden, they can simply direct the garlic routed message to come back to the originating peer's inbound tunnel.

This is not meant to provide a way for a peer's IP address to be concealed, merely as a way to let people behind firewalls and NATs fully operate within the network. Concealing the peer's IP address adds a little more work, as described below.

With this technique, any router can participate as any part of a tunnel. For efficiency purposes, a hidden peer would be a bad choice for an inbound gateway, and within any given tunnel, two neighboring peers wouldn't want to be hidden. But that is not technically necessary.

Security / anonymity

As Connelly proposed to deal with the predecessor attack (2008 update), keeping the order of peers within our tunnels consistent (aka whenever Alice creates a tunnel with both Bob and Charlie in it, Bob's next hop is always Charlie), we address the issue as Bob doesn't get to substantially sample Alice's peer selection group. We may even want to explicitly allow Bob to participate in Alice's tunnels in only one way - receiving a message from Dave and sending it to Charlie - and if any of those peers are not available to participate in the tunnel (due to overload, network disconnection, etc), avoid asking Bob to participate in any tunnels until they are back online.

More analysis is necessary for revising the tunnel creation - at the moment, we simply select and order randomly within the peer's top tier of peers (ones with fast + high capacity).

Adding a strict ordering to peers in a tunnel also improves the anonymity of peers with 0-hop tunnels, as otherwise the fact that a peer's gateway is always the same would be particularly damning. However, peers with 0-hop tunnels may want to periodically use a 1-hop tunnel to simulate the failure of a normally reliable gateway peer (so every MTBF*(tunnel duration) minutes, use a 1-hop tunnel).


Performance related improvements are listed on the Performance page.