É aquele momento do ano de novo! Estamos embarcando no nosso programa de verão de desenvolvimento, em que focamos em avançar algum aspecto do i2p. Pelos próximo três meses, vamos encorajar os contribuidores, novos e já existentes, a pegarem uma tarefa e se divertir!
No ano passado, focamos em ajudar os usuários e desenvolvedores a alavancar o I2P, melhorando a API de ferramentas e dando mais atenção as aplicações que rodam sobre o I2P. Neste ano, nós queremos melhorar a experiencia do usuário, trabalhando no aspecto que mais afeta a todos: Performance.
Despite onion-routing networks often being called "low-latency" networks, there is significant overhead created by routing traffic through additional computers. I2P's unidirectional tunnel design means that by default, a round trip between two Destinations will involve twelve participants! Improving the performance of these participants will help to both reduce the latency of end-to-end connections [1], and increase the quality of tunnels network-wide.
MOAR speed!
Our development programme this year will have four components:
Measure
We can't tell if we improve performance without a baseline! We'll be creating a metrics system for collecting usage and performance data about I2P in a privacy-preserving way, as well as porting various benchmarking tools to run over I2P (e.g. iperf3).
Optimise
There's a lot of scope for improving the performance of our existing code, to e.g. reduce the overhead of participating in tunnels. We will be looking at potential improvements to:
- Cryptographic primitives
- Network transports, both at the link-layer (NTCP, SSU) and end-to-end (Streaming)
- Peer profiling
- Tunnel path selection
Advance
We have several open proposals for improving the scalability of the I2P network (e.g. Prop115, Prop123, Prop124, Prop125, Prop138, Prop140). We will be working on these proposals, and begin implementing the finalised ones in the various network routers. The more feedback these proposals receive, the sooner we can roll them out, and the sooner I2P services can start using them!
Research
I2P is a packet-switched network, like the internet it runs on top of. This gives us significant flexibility in how we route packets, both for performance and privacy. The majority of this flexibility is unexplored! We want to encourage research into how various clearnet techniques for improving bandwidth can be applied to I2P, and how they might affect the privacy of network participants.
Take part in Summer Dev!
We have many more ideas for things we'd like to get done in these areas. If you're interested in hacking on privacy and anonymity software, designing protocols (cryptographic or otherwise), or researching future ideas - come and chat with us on IRC or Twitter! We are always happy to welcome newcomers into our community, both inside and outside the I2P network. We'll also be sending I2P stickers out to all new contributors taking part! If you want to chat about a specific idea, contact GetI2P, i2p or str4d on Twitter. You can also find us in #i2p-dev on OFTC or Freenode.
We'll be posting here as we go, but you can also follow our progress, and share your own ideas and work, with the hashtag #I2PSummer on Twitter. Bring on thesummer!
[1] Low-latency onion-routing networks are vulnerable to traffic confirmation attacks, so it would be reasonable to ask whether improved performance equates to reduced privacy. Some latency can help privacy if applied correctly via random delays or batching (neither of which are currently employed by any general-purpose onion-routing network). However, if a tunnel has uniform overall latency, then traffic confirmation attacks should be just as viable with or without that latency; thus there should be little statistical difference when the latency is reduced uniformly.
