Réunion de développement I2P - 04 mars 2016

15:00:05 <zzz> 0) salut 15:00:23 <zzz> 1) structure pour ces réunions 15:00:32 <zzz> 2) discussion de la feuille de route 15:00:37 <zzz> 0) salut 15:00:41 <zzz> salut 15:00:54 <str4d> salut 15:01:02 <xcps_> salut! 15:01:27 <orignal_> quoi de neuf ? 15:02:18 <zzz> veuillez consulter le fil sur http://zzz.i2p/topics/2021 et la feuille de route actuelle sur http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) structure pour ces réunions 15:03:22 <zzz> devrait-on aller directement à la feuille de route ou parler d'abord des priorités de haut niveau ? 15:03:53 <str4d> Je choisirais la seconde d'abord 15:04:41 <zzz> ok, donc dans le fil, j'ai proposé deux priorités — faire croître le réseau et accroître la sécurité 15:04:55 <zzz> comment cela vous paraît-il comme principes de haut niveau ? 15:05:25 <zzz> décidons d'abord de ce qui est important 15:05:32 <EinMByte> Elles sont comme prévu, je pense 15:05:48 <EinMByte> « faire croître le réseau » doit être pris au sens large, toutefois 15:05:57 <str4d> Je pense que ce sont de très bons thèmes généraux 15:06:03 <zzz> anonimal a proposé tout un tas d'autres choses dans le fil, mais ce n'était pas vraiment ce que je visais 15:06:13 <xcps_> augmenter la sécurité devrait toujours être le plus important à mon humble avis 15:06:28 <zzz> d'autres principes à considérer pendant l'examen de la feuille de route ? 15:06:28 <str4d> Ce que, à mon humble avis, nous devons faire ici, c'est déterminer ce que cela signifie réellement en termes de livrables potentiels 15:06:40 <EinMByte> Donc « faire croître le réseau » devrait aussi signifier « attirer davantage l'attention de la recherche » 15:07:00 <zzz> faire croître le réseau recouvre une énorme variété de choses — voir le fil 15:07:09 <str4d> EinMByte, ouais, je pense que je l'ai peut-être mentionné dans le fil 15:07:36 <zzz> Nous définirons bientôt ce que cela signifie. Pour l'instant, mettons-nous d'accord sur ce qui est important. 15:07:58 <str4d> L'ergonomie est très importante pour moi et, à mon avis, contribue aux deux domaines ci-dessus 15:07:58 <zzz> tout est possible si nous continuons à croître. une fois que nous cessons de croître, nous sommes morts 15:08:05 <zzz> d'accord str4d 15:08:41 <str4d> À court terme pour augmenter notre base d'utilisateurs, et à plus long terme pour accroître notre visibilité publique, la facilité d'utilisation pour les chercheurs, etc. 15:09:11 <EinMByte> Notez aussi que la croissance est la seule façon d'attirer des chercheurs 15:09:25 <zzz> plus d'utilisateurs apportent plus de devs, plus de chercheurs, plus de contenu, etc., etc. 15:09:37 <EinMByte> Les grands réseaux sont généralement plus intéressants à étudier 15:10:05 <EinMByte> Donc je pense que nous pouvons tous nous mettre d'accord sur ces 2 priorités 15:10:16 <zzz> l'essentiel de notre croissance l'an dernier est venu de Vuze. Ce qui est très bien, mais j'aimerais aussi avoir une croissance plus « native » 15:10:43 <zzz> mais peut-être que la croissance via des applications intégrées, ou en se concentrant sur les applications en général, est le chemin le plus facile vers la croissance 15:10:48 <str4d> Oui 15:11:04 <EinMByte> zzz: Pour beaucoup de gens, il est plus facile d'utiliser une application qui exécute I2P en arrière-plan et gère la configuration pour eux 15:11:12 <sadie> salut - un peu en retard à la fête 15:11:20 <zzz> salut sadie ravi que tu aies pu venir 15:11:23 <str4d> Cela, à mon avis, viendra d'améliorations d'ergonomie à la fois pour l'UI et les API 15:11:42 <str4d> Sur ce dernier point, nous avons déjà travaillé dans divers fils 15:11:48 <zzz> d'une certaine manière, ce sont les applis qui sont expertes en UI, laissons-les intégrer i2p et l'exposer (ou le cacher) comme elles l'estiment préférable 15:11:58 <str4d> Mmm 15:12:08 <EinMByte> str4d: C'est une autre solution au même problème, oui. Et je la préfère parce qu'intégrer I2P partout ne passe pas à l'échelle, à mon avis 15:12:30 <str4d> C'est un peu l'approche que je suivais avec Android 15:13:04 <EinMByte> Il faut un moyen de s'assurer que les gens n'ont pas une instance I2P pour chaque application 15:13:12 <zzz> ok, autre chose sur 1) ou passe-t-on à l'examen de la feuille de route elle-même ? 15:14:00 <str4d> Je pense que tout le monde ici semble globalement d'accord 15:14:08 <str4d> (au moins pas d'opposition :P) 15:14:14 <zzz> laissez-moi copier les lignes du fil. Pas comme parole d'évangile, juste pour référence 15:14:25 <zzz> Faire croître le réseau 15:14:25 <zzz> Inclut : Marketing, projets communs, intégrer plus de choses, aider les autres à intégrer i2p, ergonomie, améliorations du site web, plus de traductions, conférences et présentations, articles et récits, UI, Android, applications Android, meilleure évasion GFW, orchid, plus de libs et d'outils pour les devs client, meilleur support pour d'énormes sites web, prise en charge du dev de router alternatif, alliances, accélérations et efficacité, capacité, augmentation des limites, entrer 15:14:25 <zzz> dans Debian, ... 15:14:25 <zzz> Augmenter la sécurité 15:14:25 <zzz> Inclut : Migration crypto, protocole d'abonnement, nouveaux protocoles de transport, transports modulaires, LS2, NTCP2, nouveau DH (Diffie-Hellman), révocation de clés, stockage de clés, relecture de code, Sybil, corrections de bugs, nommage, SSL, ... 15:14:46 <zzz> ok, passons à 2) la feuille de route elle-même 15:15:10 <zzz> l'URL est http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 est presque bouclée, sortie dans environ 10 jours, donc regardons les 4 prochaines versions 26-29 pour cette année 15:16:00 <zzz> ce qui devrait nous mener jusqu'au ccc 15:16:15 <EinMByte> Si quelque chose est sous 2017, par ex., cela signifie-t-il qu'on ne s'y penche qu'à ce moment-là, ou que l'on commence l'implémentation à ce moment-là ? 15:16:41 <str4d> En termes de choses que nous devons absolument faire, je placerais la migration crypto et le travail sur Sybil en haut de la liste 15:16:42 <zzz> 1mb, nous voulons clairement commencer dès maintenant les gros sujets de 2017, comme nouvelle crypto/DH, NTCP2, etc. 15:17:04 <EinMByte> Aussi, les attaques d'éclipse sont un problème en ce moment, à mon avis 15:17:05 <zzz> donc la feuille de route pourrait inclure des travaux préparatoires pour cela 15:17:23 <str4d> EinMByte, ouais, je rangeais ça sous Sybil 15:17:36 <EinMByte> L'idée de rotation à minuit ne marche pas et il devrait y avoir de meilleures alternatives, je suppose 15:17:52 <zzz> d'accord 15:18:05 <EinMByte> str4d: Bien sûr, c'est raisonnable de les classer comme le même type d'attaque 15:18:44 <str4d> EinMByte, j'en ai discuté avec quelques personnes à RWC 15:18:48 <str4d> J'ai quelques idées, mais difficile d'en parler ici 15:18:51 <EinMByte> zzz: Donc si nous voulons commencer NTCP2/... d'ici 2017 nous devrons planifier des travaux préliminaires 15:18:58 <zzz> oui 1mb 15:19:02 <str4d> Oui 15:19:20 <str4d> Je veux que la planification et la recherche soient sur la feuille de route :) 15:19:28 <zzz> voilà le problème. Je devrais travailler sur la 26 en ce moment et je ne sais pas ce qu'il y a dedans 15:19:39 <orignal_> est-il possible d'ajouter du padding aléatoire à NTCP existant ? 15:20:01 <str4d> orignal_, pas que je me souvienne, mais vérifie le fil NTCP2 15:20:02 <zzz> passons donc 10 minutes à planifier la 26, puis on pourra passer au plus long terme 15:20:13 <str4d> ok 15:20:14 <zzz> dites-moi ce que je devrais faire aujourd'hui 15:20:30 <EinMByte> C'est vrai, concentrons-nous là-dessus d'abord 15:20:34 <zzz> ok voyons ce qu'il y a sur la liste 25 qui n'est pas arrivé 15:20:50 <zzz> wrapper n'est pas arrivé, kytv est awol 15:20:54 <EinMByte> « améliorations crypto » est assez large 15:21:12 <zzz> ce qui s'est réellement passé sur les améliorations crypto, ce sont quelques accélérations 25519 15:21:34 <zzz> donc la liste .25 est en fait tout dedans sauf wrapper 15:22:00 <zzz> mais il y a plus à faire sur Sybil donc gardons ça sur la liste 26 15:22:08 <str4d> Super 15:22:25 <str4d> Nous avons repoussé GMP 6 à .26 à cause du besoin de plus de tests 15:22:35 <zzz> quoi d'autre sur la liste 26 maintenant devrait y être ou être déplacé 15:23:05 <EinMByte> À terme empêcher Sybil sera probablement beaucoup de travail, donc ça me semble du long terme 15:23:10 <EinMByte> (dans le sens où il nous faut d'abord une bonne revue de la littérature) 15:23:15 <zzz> orignal, oui, ntcp avec padding c'est ntcp2 15:23:21 <str4d> EinMByte, l'outil de détection Sybil n'est encore utilisé pour rien, c'est là qu'il faut plus de planification :) 15:23:49 <zzz> hottuna4 est indisponible pendant un mois, pas sûr quand ce mois se termine, donc gmp6 pourra ou non entrer dans la 26 15:24:02 <str4d> Ok 15:24:37 <str4d> Améliorations du protocole d'abonnement pour le carnet d'adresses : ce serait très bien à ajouter dès que possible, afin que les propriétaires d'anciennes Dest puissent migrer vers Ed25519 15:24:37 <EinMByte> Je pense que les CRL n'ont pas vraiment besoin d'un point d'interrogation 15:24:47 <str4d> Mais combien de temps cela prendra-t-il réellement ? 15:25:14 <zzz> nous aurons besoin bientôt d'une mise à jour d'état de tuna, je pense que l'échéance pour intégrer les gros éléments pour la 26 serait fin mars / première semaine d'avril 15:26:10 * str4d ne comprend pas encore très bien l'histoire des CRL, zzz pourrait-il développer ? 15:26:14 <zzz> la 25 aura la capacité de lire des CRL depuis le disque, donc nous pouvons les inclure dans la mise à jour 15:26:35 <zzz> mais ce n'est pas très utile car dans une mise à jour nous pouvons simplement supprimer le certificat et cela fait la même chose 15:26:56 <zzz> donc pour diffuser des CRL aux gens sans avoir à faire une mise à jour, nous les mettrions dans le flux 15:26:57 <str4d> J'essaie juste de comprendre le cas d'usage 15:27:09 <zzz> le cas d'usage, c'est que quelqu'un est compromis 15:27:20 <str4d> Ne faisons-nous toujours pas de cert pinning (ancrage de certificat) ? 15:27:30 <zzz> non 15:27:56 <zzz> donc j'en ai fait 90 % et il me reste juste à mettre la CRL dans l'espace de noms 15:28:46 <zzz> le pinning est délicat et dangereux 15:29:05 <zzz> CryptoCat a fait le « suicide par pinning » 15:29:17 <zzz> où ils avaient fait du pinning mais un intermédiaire a changé 15:30:49 <zzz> je ne pense pas que le pinning remplace les cls 15:30:51 <zzz> crls 15:31:21 <zzz> les CRL ne servent pas qu'à SSL, il y a les clés de reseed et d'update 15:31:58 <zzz> pouvons-nous garder les CRL sur la liste pour la 26 alors ? c'est presque fini 15:32:20 <str4d> Ce qui m'inquiète concernant le pinning, c'est que quelqu'un pourrait faire, par exemple, quelque chose de type Quantum Insert pour rediriger un nom de domaine de reseed, et simplement mettre n'importe quel certificat SSL valide satisfaisant l'exigence sur le nom de domaine, et les routers l'accepteraient 15:33:05 <str4d> Et concernant les CRL, si nous les utilisons pour désactiver un certificat particulier, par quoi ce certificat est-il remplacé ? 15:33:25 <zzz> rien. dans la prochaine version il y aurait vraisemblablement un remplacement 15:33:45 <str4d> On s'enfonce un peu dans les détails 15:34:07 <str4d> Je pense que là où je voulais en venir, c'est qu'il faut y réfléchir un peu plus 15:34:24 <zzz> ok donc gardons les CRL pour la 26 mais discutons-en les détails dans la semaine ou deux à venir 15:34:30 <zzz> car ce n'est pas clair à 100 % 15:34:38 <zzz> on avance 15:34:42 <zzz> quoi d'autre sur la liste 26 15:34:43 <str4d> ok 15:34:50 <EinMByte> ok 15:35:08 <zzz> protocole d'abonnement 15:35:28 <zzz> c'est la clé pour la migration crypto des sites 15:35:40 <EinMByte> remplacement de hosts.txt ou que veux-tu dire ? 15:36:22 <zzz> oui, c'est l'idée de hosts.txt comme un flux, avec quelque chose comme foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, modifier le protocole d'abonnement du carnet d'adresses avec des métadonnées clé-valeur signées 15:36:49 <zzz> la proposition est assez aboutie, mais en attente depuis environ 18 mois 15:37:07 <EinMByte> D'accord, mais la taille du fichier hosts ne deviendrait-elle pas trop grande 15:38:02 <EinMByte> Peut-être ajouter un paramètre since, pour exclure tous les hôtes insérés avant un moment donné 15:38:07 <EinMByte> (pour éviter de télécharger la liste entière si ce n'est pas nécessaire) 15:38:22 <zzz> à l'origine cela faisait partie du plan de migration crypto, mais c'était difficile et ce n'était pas la partie la plus importante 15:38:49 <zzz> mais c'est l'élément principal restant pour la migration crypto des signatures 15:39:26 <str4d> EinMByte, on a déjà ça en quelque sorte avec etag 15:39:28 <zzz> c'est encore une de ces choses proposées avec beaucoup de détails, mais sans réel accord, donc ça n'a pas commencé 15:39:42 <EinMByte> str4d: Est-ce utilisé, toutefois ? 15:39:46 <str4d> EinMByte, oui 15:40:00 <EinMByte> Oh, laisse tomber. dans ce cas 15:40:03 <str4d> Ce ne serait pas différent de l'agencement actuel 15:40:20 <zzz> donc on le met sur la liste 26 et on commence dès que possible. pas sûr que l'on puisse aller assez loin pour la 26 mais j'essaierai. nous devons revoir le fil sur zzz.i2p 15:40:22 <str4d> mais au lieu que les entrées de nom de domaine ne se répètent jamais, elles se répéteraient maintenant dans le « flux » 15:40:42 <EinMByte> Y a-t-il une raison particulière pour conserver le format bizarre, toutefois ? 15:41:05 <EinMByte> Il me semblerait plus facile d'utiliser simplement quelque chose de standard 15:41:06 <zzz> peut-être. compatibilité avec les anciens clients. mais nous devrions revoir et décider de manière certaine si c'est important 15:41:20 <zzz> aucun d'entre nous n'a regardé cela depuis peut-être un an 15:41:28 <zzz> donc on va dépoussiérer ça et y jeter un œil 15:41:32 <EinMByte> zzz: La compatibilité pourrait être gérée en fournissant également l'ancien fichier hosts.txt pendant un certain temps 15:41:41 <str4d> Il y a aussi la question plus large de ce qu'il faut faire par ex. de tous les noms « perdus » 15:41:53 <str4d> Mais cela sort du cadre de la discussion actuelle 15:41:57 <zzz> ouaip. il nous faudrait aussi impliquer les autres impls 15:42:18 <EinMByte> str4d: Je pense que c'est quelque chose à décider lorsque nous aurons un nouveau système de noms (si jamais nous en avons un jour) 15:42:26 <str4d> Pour l'instant, je veux un moyen pour les domaines actuellement actifs de mettre à jour leurs dests 15:42:26 <zzz> ok, cela reste sur la liste pour la 26 pour l'instant. prochain point — trucs Sybil 15:42:45 <zzz> pouvons-nous rendre Sybil automatique ? Vous avez tous lu l'article de Philip Winter j'espère ???? 15:42:50 <str4d> Et plus tôt nous intégrerons le code cœur, plus tôt nous pourrons l'activer dans un an environ 15:43:50 <EinMByte> zzz: Quel article ? J'ai clairement raté quelque chose 15:44:27 <zzz> voir @__phw sur Twitter pour le lien 15:45:02 <zzz> nous travaillons avec lui grâce à une introduction de sadie au ccc 15:45:03 <EinMByte> zzz: ça : http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> si cela a été publié dans les deux dernières semaines, c'est ça 15:45:59 <EinMByte> Eh bien, c'est un eprint de février de cette année 15:46:09 <zzz> je ne pense pas que nous soyons prêts pour l'automatique. eux non plus, pas vraiment 15:46:22 <zzz> ils envoient juste un e-mail une fois par jour aux dirauths 15:46:36 <zzz> c'est tout heuristique et un peu magique des deux côtés 15:46:49 <EinMByte> Donc il a probablement mis l'eprint en ligne après publication 15:46:57 <zzz> donc j'aimerais repousser l'automatisation plus tard dans l'année 15:47:07 <str4d> EinMByte, 25 Feb est la version que j'ai 15:47:14 <EinMByte> zzz: Alors comment cela fonctionnerait-il exactement dans un cadre décentralisé ? 15:47:44 <str4d> Nous devons faire les choses de bas en haut plutôt que de haut en bas 15:48:06 <str4d> c.-à-d. que chaque router devrait inclure des « candidats Sybil potentiels » dans les profils de pairs 15:48:13 <zzz> EinMByte, je ne sais pas. c'est difficile 15:48:20 <str4d> basé par ex. sur les temps en ligne, etc. 15:48:30 <EinMByte> Détecter les attaques Sybil est faisable je pense, les prévenir sur la base de cette détection est très difficile dans un réseau décentralisé 15:48:30 <EinMByte> Mais j'aime le défi 15:48:34 <zzz> nous avons aussi besoin de gravy, qui travaille sur une refonte centralisée de son installation 15:48:43 <str4d> Il y a aussi la possibilité d'avoir une configuration un peu plus centralisée 15:48:45 <str4d> Oui, ça 15:48:45 <EinMByte> str4d: À ce stade, il faut commencer à attribuer de la confiance à chaque router 15:48:52 <EinMByte> ce qui, en soi, serait tout un système anti-Sybil 15:49:07 <str4d> Et faire en sorte que les routers s'abonnent à une liste de Sybils potentiels 15:49:07 <zzz> un peu comme les dagon proposals 15:49:09 <str4d> EinMByte, c'est en gros ce que sont les peer profiles maintenant toutefois 15:49:31 <str4d> où la « confiance » est actuellement définie comme « a routé de manière fiable pour moi par le passé » 15:49:42 <EinMByte> str4d: Oui, et ils ont causé quelques attaques jusqu'à présent :) 15:50:15 <str4d> Oui 15:50:23 <EinMByte> De plus, les peer profiles ne permettent pas vraiment d'exclure un pair du réseau 15:50:31 <EinMByte> La prévention Sybil permettrait en quelque sorte cela 15:50:35 <str4d> Le profilage des pairs et la sélection des pairs est un autre point qui, je pense, doit être priorisé 15:50:46 <str4d> EinMByte, elles le peuvent 15:51:01 <zzz> donc je propose de changer l'élément Sybil de la 26 en « amélioration continue » mais de repousser la partie « automatique » à plus tard 15:51:01 <str4d> Pas pour le moment 15:51:11 <str4d> Je dis juste que c'est là que nous le mettrions 15:51:34 <EinMByte> str4d: Oui, c'est possible. 15:51:37 <str4d> (en termes d'intégrer la détection Sybil et des techniques plus avancées dans le lexique et l'architecture d'I2P) 15:51:53 <EinMByte> En tout cas, je n'abandonnerais pas la décentralisation. C'est la plus belle partie d'I2P à mon avis 15:52:14 <str4d> Oui 15:52:27 <EinMByte> (et la centralisation conduit de toute façon à diverses attaques pratiques) 15:52:43 <zzz> passons à la suite. améliorations de streaming ? je ne sais pas trop ce que c'est, peut-être juste l'élément perpétuel « faire mieux » 15:52:49 <str4d> zzz, oui, on peut continuer à travailler sur cette page routerconsole, puis l'accrocher aux peer profiles et à la sélection une fois que nous aurons décidé d'une stratégie 15:53:00 <zzz> je ne vois pas quoi faire de spécifique sur le streaming. quelqu'un ? 15:53:01 <EinMByte> Parfois, ajouter une autorité centrale peut faciliter votre preuve de sécurité, mais provoquer un échec de sécurité en pratique 15:53:20 <str4d> De la recherche et des optimisations seraient bien 15:53:28 <EinMByte> zzz: Des améliorations évidentes que nous pourrions faire là ? 15:53:30 <str4d> Ce serait un bon candidat pour de la recherche externe 15:53:46 <zzz> nous avons vraiment besoin d'un meilleur banc de test 15:53:51 <EinMByte> str4d: Je suis d'accord. 15:53:55 <zzz> ajouter des délais / pertes, réordonnancement, etc. 15:54:04 <EinMByte> Nous devrions probablement étendre notre page « questions de recherche ouvertes » avec ça et d'autres choses 15:54:40 <zzz> je n'ai pas beaucoup d'idées « blue sky » sur ma liste pour le streaming. il faut que ce soit piloté par les résultats des tests 15:54:50 <EinMByte> Il y a peut-être des améliorations à faire dans l'allocation des tunnels ? 15:55:05 <str4d> zzz, il y a un projet GH qui simule « l'Internet » avec des conteneurs qui peuvent faire ça, si je me souviens bien 15:55:08 <zzz> et si on faisait de cet élément un « banc de test de streaming » 15:55:17 <str4d> Je ne sais pas à quel point ce serait facile, il nous faudrait une nouvelle JVM par conteneur :P 15:55:25 <str4d> EinMByte, mmm 15:55:48 <EinMByte> str4d: shadow pourrait être utilisé, je pense. Pas sûr que cela puisse être intégré avec Java mais c'est sur la TODO list de kovri 15:55:52 <str4d> Ce n'est pas vraiment du streaming, c'est au niveau datagramme 15:56:22 <zzz> le truc d'allocation de tunnel est l'idée de psi de faire choisir les tunnels par le client 15:56:34 <EinMByte> str4d: Oui, je soupçonne qu'il y a plus à optimiser là 15:56:46 <EinMByte> zzz: Je ne pense pas vraiment que les utilisateurs soient les meilleurs algorithmes d'optimisation, mais peut-être 15:57:10 <zzz> c'est une corruption violente de notre superposition, et je ne vois aucun moyen de le faire. mais c'est ce que propose psi 15:57:19 <EinMByte> ... ou probablement « client » ne veut pas dire utilisateur 15:57:32 <zzz> client == côté client de I2CP 15:57:44 <str4d> Le truc, c'est que 15:57:54 <str4d> Tor fournit cette capacité via leur Control Socket 15:57:58 <EinMByte> Ok donc ça veut dire ça 15:57:59 <str4d> Et c'est très utile pour les chercheurs 15:58:10 <str4d> Mais ils ont aussi une architecture beaucoup plus plate 15:58:19 <str4d> Alors que nous isolons différents clients les uns des autres via I2CP 15:58:31 <EinMByte> zzz: Je m'attendrais à ce que le router ait plus d'informations pertinentes. Le client pourrait transmettre des exigences supplémentaires 15:58:41 <zzz> nous avons aussi les hooks lua de psi pour les chercheurs, qui n'ont jamais été fusionnés (ni dans Java ni dans kovri), mais c'est toujours une option 15:59:14 <zzz> voyez, pour l'instant le côté client ne connaît même pas les tunnels, donc il n'a certainement aucune capacité à les choisir 15:59:16 <str4d> En parlant à nickm à RWC, il a dit qu'il était beaucoup plus facile pour Tor de maintenir une interface Control Socket qu'un système de plugins 15:59:17 <EinMByte> Je sais que shadow est utilisé en pratique par des chercheurs 15:59:22 <EinMByte> Lua, je ne sais pas 15:59:55 <EinMByte> zzz: Donc probablement que la même chose peut être obtenue en passant les informations pertinentes via I2CP ? 16:00:17 <zzz> 1mb, oui, mais ce serait vraiment moche 16:00:44 <str4d> On pourrait toujours le restreindre avec un indicateur -research ou quelque chose du genre 16:00:54 <str4d> (dans router.config) 16:01:06 <str4d> Ainsi la plupart des utilisateurs ne seraient pas exposés à la mocheté 16:01:13 <zzz> kovri/i2pd n'ont pas encore ces barrières d'API rigides entre client/router, c'est plus facile pour les 16:01:20 <zzz> *eux 16:01:28 <str4d> Et nous pouvons définir « .research » dès le départ comme signifiant « Nous nous réservons le droit de modifier ces API » 16:01:44 <str4d> c.-à-d. que les chercheurs devraient utiliser l'indicateur .research avec une version particulière 16:01:57 <str4d> Retour au sujet réel de la discussion : 16:01:59 <EinMByte> zzz : À propos des tunnels. Ça dépend. Je pense qu'il serait logique de transmettre des informations sur l'usage prévu du tunnel. 16:02:20 <zzz> (Pour info, cette réunion durera encore 25 minutes max, à continuer dimanche) 16:02:33 <EinMByte> zzz: C'est surtout plus facile pour nous parce que shadow est écrit en C, je pense 16:02:42 <str4d> Je pense qu'il faudrait repousser cela dans la catégorie « nécessite plus de recherche » 16:02:44 <zzz> le problème est que ce ne sont pas seulement vos tunnels qui doivent être choisis mais aussi les tunnels de l'extrémité distante 16:02:48 <EinMByte> Ok. Passons à la suite alors. 16:03:08 <zzz> ok, c'est tout ce qu'il y a sur la liste 26 maintenant. Que devrait-on ajouter ? 16:03:11 <EinMByte> zzz: L'extrémité distante ne gère-t-elle pas cela 16:03:36 <zzz> non, nous faisons du routage source (c.-à-d. nous choisissons le lease de l'extrémité distante dans son leaseset pour son inbound) 16:04:08 <zzz> regardez la liste 27-29. que faudrait-il tirer vers la 26, le cas échéant ? 16:04:44 <str4d> Je veux commencer les travaux préparatoires pour les nouvelles LS et le netdb 16:04:46 <zzz> c'est là que se trouve tout le « travail initial sur xxx pour 2017 », mais aussi beaucoup de choses de 2016 16:05:23 <EinMByte> zzz: J'avais mal compris ce que tu voulais dire par far-end, laisse tomber 16:05:31 <str4d> Plus tôt nous stabiliserons cela et l'intégrerons dans la base de code, plus tôt le réseau aura un large support pour cela 16:06:42 <EinMByte> Notez que nous (kovri) voulons des spécifications 16:06:52 <EinMByte> Sinon il sera difficile de suivre l'implémentation 16:07:31 <zzz> bien sûr. tout ce qui est une nouvelle spécification, nous devons tous travailler dessus ensemble 16:07:36 <EinMByte> str4d: Commençons par lister ce que LS2 devrait réellement prendre en charge 16:07:53 <EinMByte> (si cela n'a pas déjà été fait) 16:09:40 <zzz> fondamentalement, LS2 n'est que quelques éléments 16:09:59 <zzz> ajouter un peu d'espace pour des flags 16:10:09 <zzz> et permettre la crypto future 16:10:52 <zzz> mais j'ai toutes ces propositions sur un meilleur multihoming, plus une recherche de service à la Grothoff 16:11:00 <zzz> anycast 16:11:01 <EinMByte> Avons-nous une liste spécifique quelque part pour référence ? 16:11:11 <zzz> c'est rassemblé sur zzz, une seconde 16:11:23 <str4d> EinMByte, Je travaille lentement à rassembler tout cela sur le site web 16:11:41 <zzz> peut-on accélérer ça str4d ? genre la semaine prochaine ou dans deux ? 16:11:47 <str4d> Cela devrait aller dans la liste .26 16:11:50 <str4d> Hmm 16:11:53 <str4d> Possiblement 16:11:59 <str4d> J'ai besoin de plus d'yeux dessus 16:11:59 <zzz> sans les propositions sur une simple liste, c'est beaucoup trop difficile 16:12:08 <EinMByte> str4d: En fait, pour certaines de ces choses, une fonctionnalité de wiki serait utile 16:12:24 <EinMByte> (l'idée est que cela irait plus vite) 16:12:48 <zzz> pour commencer il nous faut une liste 16:12:50 <str4d> EinMByte, exactement 16:12:56 <zzz> n'essayons pas de tout faire à la fois 16:13:11 <str4d> J'essaie de passer d'un HTML côté serveur requis à (actuellement) rST 16:13:31 <str4d> J'ai besoin que des gens regardent ce que j'ai pour vérifier que a) c'est utilisable et b) on ne perd rien de ce que nous avons actuellement 16:13:39 <str4d> Actuellement, c'est appliqué uniquement aux docs de spéc 16:13:40 <zzz> mettons ce sujet des propositions sur la liste pour la 26 et nous parlerons plus tard de ce que cela signifie. Mais il nous faut des avancées là-dessus dès que possible. 16:13:55 <str4d> Mais une fois que cela est solidifié, l'étendre aux propositions est trivial 16:13:56 <zzz> je les veux sur le site web. peu importe la forme. 16:14:46 <EinMByte> Je suis prêt à relire des propositions, mais il arrive parfois que je ne trouve tout simplement aucun texte 16:15:10 <EinMByte> (certaines choses sur le site web sont en quelque sorte cachées, je pense) 16:15:37 <zzz> d'accord 16:16:05 <zzz> nous devons déplacer des choses de zzz.i2p vers le site web avec une certaine organisation 16:16:13 <EinMByte> str4d: Passer de HTML à quelque chose qui peut être facilement converti vers divers formats est une bonne chose 16:16:28 <EinMByte> zzz: Oui, absolument 16:16:35 <str4d> EinMByte, ce dont j'ai besoin d'une relecture est dans i2p.www.str4d 16:16:36 <EinMByte> Peut-être un processus fixe pour toutes les propositions 16:16:57 <zzz> ok. c'est sur la liste pour la 26. détails à suivre. str4d, au travail. je ne m'attendrais pas à beaucoup de retours. Propose un nouveau système et nous nous y conformerons tous 16:17:02 <str4d> et sur http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte, si tu veux travailler avec moi pour finaliser ça, je pourrais terminer peut-être pour .25 16:17:23 <zzz> quoi d'autre pour la 26 ? on doit conclure 16:17:36 <str4d> ( EinMByte, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec spécifiquement) 16:18:14 <zzz> ce sont des choses très court terme. J'ai besoin de savoir quoi faire lundi 16:18:27 <zzz> dernier appel pour la 26 16:18:41 <str4d> Je pense que les trucs d'abonnements prendront un certain temps 16:18:49 <str4d> Donc je serais content que ce soit l'élément principal 16:18:52 <zzz> d'accord. 16:19:54 <zzz> ok. réunion dimanche à la même heure. nous commencerons par vrp/h1. merci de revoir le ticket 1119 à l'avance. après cela, nous parlerons de 27-29, si le temps le permet. 16:20:06 <EinMByte> str4d: Y en a-t-il qui, selon toi, nécessitent le plus d'attention ? 16:20:27 <zzz> nous pourrons aussi revenir brièvement sur la 26 dimanche si nécessaire 16:20:43 <str4d> EinMByte, il s'agit essentiellement de décider si le format pour rédiger les propositions est utilisable, et s'il limite ce qui finit sur le site web (en format HTML ou TXT) 16:20:45 <zzz> donc l'ordre du jour dimanche sera 1) vrp/h1/1119 ; 2) 26 ; 3) 27-29 16:20:57 <zzz> merci à tous 16:21:25 * zzz *bafs* la réunion est close 16:27:50 <EinMByte> str4d : C'est probablement OK tant que cela peut être converti vers la plupart des autres formats :)