Priorité : nouvelle cryptographie

Bon nombre des primitives et protocoles actuels conservent encore leur conception originale remontant à peu près à 2005 et ont besoin d’être améliorés. Depuis des années, nous avons eu plusieurs propositions ouvertes, avec des idées, mais les progrès ont été lents. Nous sommes tous d’accord que cela doit être notre priorité absolue pour 2018. Les volets principaux sont :

– De nouveaux protocoles de transport (pour remplacer NTCP et SSU). Voir Prop111. – Un nouveau protocole de chiffrement oignon pour la construction et l’utilisation de tunnels. – De nouveaux types de données NetDB afin de permettre des destinations évoluées. Voir Prop123. – Un protocole de bout en bout amélioré (remplaçant ElGamal).

Le travail sur cette priorité est regroupé en plusieurs catégories :

– Rédaction des propositions – Rédaction de mises en œuvre fonctionnelles de ces propositions que nous pouvons tester – Révision des propositions.

Nous ne pouvons diffuser des spécifications de nouveaux protocoles dans tout le réseau sans travailler sur chacune de ces catégories.

Non essentiel : réutilisation du code

Les quelques dernières années ont vu apparaître des efforts indépendants pour créer des protocoles simples et des cadres de protocoles qui atteignent plusieurs des objectifs que nous avons pour nos propres protocoles, et qui ont rapidement gagné en popularité dans la communauté en général. C’est un des avantages à commencer maintenant le travail expliqué ci-dessus. En tirant parti de ces efforts, nous obtenons un effet multiplicateur :

– Nous tirons avantage de conceptions de protocoles, de preuves de sécurité et de code écrits par d’autres, réduisant ainsi la somme d’efforts à fournir pour obtenir le même niveau de plénitude de fonctions et de garanties de sécurité.

– D’autres communautés peuvent tirer parti du travail que nous effectuons, accroissant leur intérêt à travailler avec nous et pensant à I2P dans son intégralité.

Mes propositions tireront parti en particulier du « `cadre de protocoles Noise`_ » et du « `format de paquets SPHINX`_ ». Des collaborations se présentent à l’horizon à ce sujet avec plusieurs personnes extérieures à I2P !

Priorité : collaboration du réseau visible

Nous avons lentement développé un intérêt à ce sujet au cours des six derniers mois environ. Lors de ETS2017, 34C3 et RWC2018, j’ai eu de bonnes discussions sur les manières d’améliorer la collaboration avec la communauté en général. Cela est particulièrement important pour garantir que nous pouvons recueillir autant d’examens de nouveaux protocoles que possible. Le plus gros obstacle que j’ai rencontré provient du fait que la majorité de la collaboration de développement se déroule à l’intérieur d’I2P même, ce qui augmente substantiellement l’effort exigé pour contribuer.

Les deux priorités dans cette catégorie sont :

– Mettre en place un forum de développement exploité par le projet, accessible à la fois de l’intérieur et de l’extérieur d’I2P.

– Mettre en place des listes de diffusion pour l’examen de propositions et des discussions sur ces dernières (possiblement connectées au forum ci-dessus).

D’autres objectifs qui sont classés comme non essentiels :

– Mettre en place une passerelle git-vers-mtn utilisable afin de nous permettre de solliciter efficacement des contributions provenant du réseau visible sur GitHub tout en conservant l’environnement canonique de développement sur Monotone.

– Rédiger un « exposé de position » qui explique précisément I2P au milieu universitaire et qui le situe dans le contexte de la littérature existante.

Je m’attends à ce que les collaborations avec les personnes à l’extérieur d’I2P aient lieu entièrement sur GitHub pour réduire les frictions.

Priorité : préparer des versions à longue durée de vie

I2P se trouve maintenant dans Debian Sid (leur dépôt instable) qui deviendra stable dans environ dix-huit mois, et a aussi été archivé dans le dépôt Ubuntu pour être inclus dans la prochaine version LTS en avril. Nous allons commencer à avoir des versions d’I2P qui vont traîner pendant des années et nous devons garantir que nous pourrons gérer leur présence sur le réseau.

L’objectif principal est ici de déployer autant de nouveaux protocoles que possible dans l’année à venir pour respecter la sortie de la prochaine version stable de Debian. Pour ceux qui exigent un déploiement sur plusieurs années, nous devrions incorporez les changements de postcompatibilité aussitôt que possible.

Priorité : transformer les applis actuelles en greffons

Le modèle Debian encourage des paquets séparés pour des composants séparés. Nous sommes d’accord que découpler du routeur Java principal les applications Java actuellement intégrées serait bénéfique pour plusieurs raisons :

– Cela codifie la frontière entre les applications et le routeur

– Il devrait être plus facile d’exécuter ces applis avec des routeurs n’utilisant pas Java

– Cela permettrait à des tiers de créer des « offres groupées I2P » ne contenant que les applications qu’ils désirent.

En combinaison avec les priorités précédentes, cela fait plutôt avancer le projet I2P principal, par exemple, dans la direction du noyau Linux. Nous passerons plus de temps à nous concentrer sur le réseau même, laissant les développeurs tiers se concentrer sur les applications qui utilisent le réseau (ce qui est considérablement plus facile à faire après nos efforts sur les API et les bibliothèques au cours des quelques dernières années).

Non essentiel : améliorations des applis

Nous voulons travailler sur plusieurs améliorations au niveau des applis, mais nos autres priorités ne nous permettent pas actuellement d’y consacrer le temps de développement nécessaire. C’est un domaine pour lequel nous aimerions accueillir de nouveaux contributeurs ! Une fois que le découplage mentionné ci-dessus sera effectué, quelqu’un pourra beaucoup plus facilement travailler sur une application précise indépendamment du routeur Java principal.

Une des applications pour laquelle nous aimerions recevoir de l’aide est I2P Android. Nous la garderons à jour avec les versions du noyau I2P et corrigerons les bogues que nous pourrons, mais il y a beaucoup à faire pour améliorer le code sous-jacent ainsi que la convivialité.

Priorité : stabilisation de Susimail et d’I2P-Bote

Cela dit, nous voulons travailler plus particulièrement à court terme sur des correctifs pour SusiMail et I2P-Bote (certains se trouvant déjà dans 0.9.33). Elles ont reçu moins d’attention durant les quelques dernières années que les autres applis d’I2P et nous voulons y consacrer du temps pour mettre leur code à niveau et faciliter l’arrivée de nouveaux contributeurs.

Non essentiel : triage des billets

Nous avons un important arriéré de billets de problème concernant plusieurs sous-systèmes et applis d’I2P. Dans le cadre de notre effort de stabilisation mentionné ci-dessus, nous aimerions vraiment régler certains de nos problèmes de longue date. Plus important encore, nous voulons nous assurer que nos billets de problème sont correctement organisés afin que nos nouveaux contributeurs puissent trouver de bons billets sur lesquels travailler.

Priorité : soutien des utilisateurs

Un des aspects ci-dessus sur lequel nous nous concentrerons est de rester en contact avec les utilisateurs qui prennent le temps de signaler des problèmes. Nous vous remercions ! Plus le cycle de rétroaction sera court, plus la résolution de problèmes que les nouveaux utilisateurs rencontreront sera rapide, et plus il sera probable qu’ils continueront à participer à la communauté.

Nous aimerions recevoir votre aide !

Tout cela paraît très ambitieux et ça l’est ! Mais plusieurs des éléments ci-dessus se chevauchent et une planification minutieuse peut considérablement en diminuer le nombre.

Si nous aider avec l’un des objectifs ci-dessus vous intéresse, venez discuter avec nous ! Vous pouvez nous trouver sur OFTC, Freenode (#i2p-dev) et Twitter (@GetI2P).