Catatan: Halaman ini tidak up-to-date. Lihat roadmap untuk rencana saat ini.

Berikut adalah diskusi yang lebih rinci (namun masih belum lengkap) tentang bidang utama pengembangan masa depan di jaringan inti I2P, yang mencakup rencana peluncuran yang masuk akal. Ini tidak termasuk transport stego, porting ke perangkat nirkabel, atau peralatan untuk mengamankan mesin lokal, juga tidak termasuk aplikasi klien yang penting dalam kesuksesan I2P. Mungkin ada hal lain yang akan muncul, terutama karena I2P mendapat banyak peer review, tapi ini adalah 'hal besar' utama. Lihat juga roadmap. Ingin membantu? Ikut terlibat

Fungsionalitas inti

• NetworkDB dan tuning profil dan kebijakan ejeksi untuk jaringan besar

  Dalam database jaringan saat ini dan penerapan manajemen profil, kami telah mengambil kebebasan untuk menentukan beberapa shortcut. Misalnya, kami tidak memiliki kode untuk melepaskan referensi rekan dari K-bucket, karena kami tidak memiliki cukup peer untuk memasukkannya dengan masuk akal, jadi sebaliknya, kita tetap menjaga peer di dalam bucket apa yang sesuai. Contoh lain yang berkaitan dengan profil peer - memori yang dibutuhkan untuk mempertahankan profil masing-masing peer adalah cukup kecil sehingga kita bisa menyimpan ribuan profil penuh dalam memori tanpa masalah. Meskipun kami memiliki kapasitas untuk menggunakan profil yang dipangkas (yang dapat memuat 100 ribu profil di memori), kami tidak memiliki kode untuk menangani pemindahan profil dari "profil minimal" ke "profil penuh", dan sebaliknya, atau hanya mengeluarkan sebuah profil. Tidak akan praktis untuk menulis kode itu, karena kami tidak akan membutuhkannya untuk sementara waktu.

  Seiring pertumbuhan jaringan, kita akan ingin mengingat pertimbangan ini. Kita akan memiliki beberapa pekerjaan yang harus dilakukan, tapi kita bisa menundanya nanti.

Keamanan / anonimitas

• Full blown n-hop restricted routes dengan optional trusted links

  Fungsi rute terbatas yang dijelaskan sebelumnya hanyalah masalah fungsional - bagaimana cara membiarkan peer yang tidak dapat berkomunikasi dengannya. Namun, konsep untuk mengizinkan rute yang dibatasi, mencakup kemampuan tambahan. Misalnya, jika router benar-benar tidak dapat mengambil risiko berkomunikasi secara langsung dengan peer yang tidak dipercaya, mereka dapat mengatur tautan terpercaya melalui peer mereka, menggunakannya untuk mengirim dan menerima semua pesannya. Peer tersembunyi yang ingin benar-benar terisolasi juga menolak untuk terhubung dengan peer yang berusaha mendapatkannya (seperti yang ditunjukkan oleh teknik perutean garlic yang diuraikan sebelumnya) - mereka hanya bisa mengambil garlic clove yang memiliki permintaan untuk mengirim pesan ke rute peer dan tunnel yang mengeluarkan salah satu tautan terpercaya peer tersembunyi dengan petunjuk untuk meneruskannya sesuai permintaan.

• Hashcash untuk routerIdentity, destinasi, and pernintaan tunnel

  Dalam jaringan, kita akan ingin beberapa cara untuk mencegah orang untuk mengkonsumsi terlalu banyak sumber daya atau menciptakan begitu banyak peer untuk melakukan serangan Sybil . Teknik tradisional seperti meminta peer melihat siapa yang meminta sumber daya atau menjalankan peer tidak sesuai untuk digunakan di dalam I2P, karena hal itu akan membahayakan anonimitas sistem ini. Sebagai gantinya, kami ingin membuat permintaan tertentu menjadi "mahal".

  Hashcash adalah salah satu teknik yang bisa kita gunakan untuk secara anonim meningkatkan "biaya" dalam melakukan aktivitas tertentu, seperti menciptakan identitas router baru (hanya dilakukan sekali pada pemasangan), membuat tujuan estinasi baru (dilakukan hanya sekali saat membuat service), atau meminta agar peer berpartisipasi dalam tunnel (sering dilakukan, mungkin 2-300 kali per jam). Kami tidak tahu biaya "sebenarnya" dari setiap jenis sertifikat, namun dengan beberapa penelitian dan eksperimen, kami dapat menetapkan tingkat dasar yang cukup mahal, namun ini bukan merupakan beban yang berlebihan bagi orang-orang yang memiliki sedikit sumber daya.

  Ada beberapa algoritma lain yang dapat kita jelajahi untuk membuat permintaan sumber daya "nonfree", dan penelitian lebih lanjut di bagian itu adalah hal yang tepat.

• Operasi terowongan tingkat lanjut (batching / mixing / throttling / padding)

  Bagi pengamat eksternal pasif yang kuat serta pengamat internal berkolusi besar, perutean tunnel standar adalah rentan terhadap serangan analisis lalu lintas - hanya dengan melihat ukuran dan frekuensi pesan yang dilewatkan di antara router. Untuk melawannya, pada intinya kita akan mengalihkan sebagian tunnel ke dalam cascade campurannya sendiri - menunda pesan yang diterima di gateway dan meneruskannya dalam batch, mengatur ulang mereka seperlunya, dan menyuntikkan pesan dummy (tidak dapat dibedakan dari pesan tunnel "nyata" lainnya oleh peer di dalam path). Telah ada sejumlah besar penelitian tentang algoritma yang dapat kita andalkan sebelum menerapkan berbagai strategi pencampuran tunnel.

  Selain aspek anonimitas operasi tunnel yang lebih bervariasi, ada juga dimensi fungsional. Setiap peer hanya memiliki sejumlah data yang dapat mereka tuju untuk jaringan, dan untuk menjaga agar tunnel tertentu tidak mengkonsumsi porsi bandwidth yang tidak masuk akal, mereka ingin memasukkan beberapa throttle di tunnel. Sebagai contoh, sebuah tunnel mungkin dikonfigurasi untuk throttle sendiri setelah melewatkan 600 pesan (1 per detik), 2.4MB (4KBps), atau melebihi rata-rata (8KBps untuk menit terakhir). Kelebihan pesan mungkin tertunda atau dihapus. Dengan ini semacam throttling, peer dapat memberikan dukungan QoS seperti-ATM untuk tunnel, menolak untuk setuju untuk mengalokasikan lebih banyak bandwidth daripada peer telah tersedia.

  Selain itu, kita mungkin ingin menerapkan kode untuk secara dinamis mengalihkan tunnel untuk menghindari rekan-rekan yang gagal atau untuk menyuntikkan tambahan hop ke path. Ini dapat dilakukan dengan mengirim pesan dengan garlic routing untuk setiap peer yang tertentu dalam tunnel dengan petunjuk untuk mendefinisikan kembali hop berikutnya di dalam tunnel.

• Berhenti & pergi mix w / garlics & terowongan

  Di balik batching per-terowongan dan strategi pencampuran, ada kemampuan lebih lanjut untuk melindungi terhadap ari penyerang yang kuat, seperti memungkinkan setiap langkah di jalan melakukan garlic routing untuk mendefinisikan keterlambatan atau jendela di mana kepadanya pesan diteruskan. Ini akan memungkinkan perlindungan terhadap serangan persimpangan jangka panjang, seperti peer bisa mengirim pesan standar yang terlihat sempurna untuk kebanyakan peer yang memberikannya, kecuali di peer yang mana clove yang terbuka termasuk petunjuk penundaan.

Kinerja

Kinerja terkait perbaikan tercantum di halaman Performance .