Réunion des développeurs I2P - 15 mars 2005

13:07 <jrandom> 0) salut 13:07 <jrandom> 1) État du réseau 13:07 <jrandom> 2) Feedspace 13:07 <jrandom> 3) ??? 13:07 <jrandom> 0) salut 13:07 * jrandom fait coucou 13:07 <jrandom> notes d'état hebdomadaires en ligne @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html 13:08 <Teal> salut 13:08 <jrandom> (ouais, je suis en retard cette fois, mais presque !) 13:08 <frosk> salut 13:08 <jrandom> autant passer directement au 1) état du réseau 13:08 <jrandom> le réseau est, genre, en ligne, et tout 13:09 <jrandom> le débit global est toujours aussi bas qu'avant, avec un nombre substantiel de messages et fragments perdus 13:09 <bla> salut 13:09 <ant> <dm> mauvais 13:09 <Teal> des pistes sur le pourquoi ? 13:10 <jrandom> Teal: bien sûr, lis les notes d'état ? :) 13:10 <+detonate> salut 13:11 <jrandom> il y a encore ~ 25 personnes sur des versions plus anciennes, et il est probable qu’elles y resteront jusqu’à ce qu’on les retire du réseau 13:11 <jrandom> en tout cas, on devrait pouvoir contourner ça, donc les avoir là est en fait utile, je suppose 13:11 <jrandom> (même si ce serait bien qu’ils mettent à jour... ;) 13:11 <cervantes> (salut) 13:11 <frosk> ce sont probablement des moutons qui ont installé I2P parce qu’ils en ont entendu parler quelque part et voulaient essayer du « p2p anonyme » 13:12 <ant> <BS314159> oui, si une dégradation de la qualité du réseau peut arriver à cause de bugs, c’est aussi possible par malveillance 13:12 <newkid> C’est ma première réunion, mais j’ai lu les notes, et le problème semble lié à ce que j’ai expliqué avant la réunion 13:12 <Pseudonym> savons-nous quels problèmes spécifiques causent les anciens nœuds et pourquoi ? 13:12 <jrandom> bs314159: n’attribue jamais à la malveillance ce qui peut être attribué à jrandom qui écrit du mauvais code ;) 13:13 <jrandom> Pseudonym: oui, voir le changelog 13:13 <newkid> J’exécute deux nœuds, séparés de quelques millisecondes, et ils ne se considèrent pas « rapides » l’un l’autre la plupart du temps 13:13 <jrandom> d’accord newkid 13:13 <jrandom> le calculateur de vitesse tel que déployé est, eh bien, assez pourri 13:13 <jrandom> il ne recueille pas assez de données pour avoir la moindre confiance dans les valeurs 13:13 <bla> Hmm.. C’est au mieux mauvais ;) 13:13 <jrandom> c’est à peu près aussi dénué de sens que les « débits instantanés » que vous pouvez voir sur /oldconsole.jsp 13:14 <jrandom> j’essaie de nouveaux calculateurs, et il y a une amélioration, mais l’algorithme pose problème 13:14 <jrandom> à savoir, il n’autorise pas les pairs à haute capacité à devenir des pairs rapides sans que ces pairs rapides sortent du groupe haute capacité 13:15 <bla> jrandom: Chaque nœud obtient-il les données de « rapidité » des autres nœuds directement (« P2P »), ou via des tunnels ? 13:15 <jrandom> (a.k.a. les K premiers pairs placés dans le groupe rapide y resteront) 13:15 <jrandom> bla: via des tunnels, nous ne pouvons pas faire confiance aux mesures directes, car cela permettrait des attaques d’anonymat triviales 13:15 <godmode0> "alfYl6RvHzw=" = "21538-900" 13:15 <godmode0> "alV9ye/y/Us=" = "23565-200" 13:15 <godmode0> c’est du sha1 ? 13:15 <jrandom> (p. ex. être vraiment très lent pour tout le monde sauf Alice) 13:15 <+detonate> ils y resteront pour toute la durée de vie du router ? 13:15 <jrandom> godmode0: nous sommes en réunion là 13:16 <godmode0> oups désolé 13:16 <jrandom> detonate: jusqu’à ce que l’un d’eux échoue ou rejette un tunnel (a.k.a. leur classement de capacité les fait sortir du groupe haute capacité) 13:16 <+detonate> ok 13:17 <bla> bla: Hmm.. Cela ressemble à un problème qui — pour obtenir _vraiment_ assez de données — doit être>>log(N) sur le réseau. 13:17 <jrandom> je joue avec quelques idées pour obtenir plus de données, mais je ne l’ai pas encore mis à jour 13:17 <bla> En termes de charge, oui. 13:18 <jrandom> eh bien, un des points critiques est certainement quand la charge du réseau dépasse la capacité du réseau 13:18 <jrandom> je pense que nos calculateurs de capacité peuvent gérer ça toutefois 13:18 <cervantes> jrandom: est-ce que -3 utilise réellement cette méthode de sélection de pairs rapides ? 13:18 <+polecat> Avec un peu de chance, puisque le transfert de données entre pairs dispose de contrôles d’équité, il n’y aura aucun moyen d’augmenter la charge de trop... 13:19 <bla> jrandom: Eh bien, plus précisément : nous devons nous assurer que l’algo de « trouver qui est rapide » reste en O(log(N)) 13:19 <jrandom> cervantes: oui, mais comme je l’ai dit, il n’autorise pas la promotion des pairs entre rapide et haute capacité 13:19 <jrandom> polecat: contrôles d’équité ? 13:19 <cervantes> puisque je viens de réaliser que j’avais activé le proxy, et que je naviguais sur le web normal sans m’en rendre compte (je me disais bien que ma connexion était un peu molle) ;-) 13:20 <cervantes> s/live web/outerweb 13:20 <jrandom> bla: je ne suis pas sûr que nous devrions dépendre de N. Pas besoin de trouver l’« optimal » (le plus rapide du réseau), seulement « suffisamment rapide pour gérer nos données » 13:20 <@smeghead> il semblerait que i2pProxy.pac soit dangereux même pour son créateur :) 13:20 <jrandom> heh bien vu cervantes :) 13:20 <jrandom> lol 13:20 <cervantes> donc ça a certainement amélioré les choses sur mon nœud à la maison qui souffrait vraiment avant 13:21 <ant> <BS314159> jrandom: peux-tu le randomiser ? 13:21 <cervantes> smeghead: hehe voyons, je n’utilise pas ça ! tu me crois fou ! 13:21 <ant> <BS314159> c.-à-d. créer un taux de transition spontané ? 13:21 <jrandom> BS314159: nous utilisons des niveaux (tiers), et nous randomisons à l’intérieur des niveaux 13:22 <jrandom> BS314159: des taux spontanés, c’est essentiellement ce que nous avons maintenant, et ils fluctuent beaucoup 13:22 <jrandom> (we == 0.5.0.2-0) 13:22 <ant> <BS314159> je crois que je ne comprends pas le problème. laisse tomber. 13:23 <jrandom> c’est difficile de le faire de façon sûre et précise, mais je pense qu’il y a assez de données à exploiter. on verra bien 13:23 <bla> jrandom: En tout cas, trouver quelques bons nœuds ressemble furieusement à une optimisation de type « colonie de fourmis » 13:24 <bla> jrandom: Parce qu’une fois que tu as des pairs rapides, tu es susceptible d’utiliser ceux-là pour découvrir qui d’autre est rapide. 13:24 <jrandom> proposerais-tu davantage de sondages actifs dans cette veine ? 13:24 <jrandom> ah, en fait, ce n’est pas vrai 13:25 <jrandom> c’est la différence entre les tunnels client et les tunnels exploratoires 13:25 <bla> jrandom: Et donc, tu ferais essentiellement une optimisation gloutonne (greedy) (comme les colonies de fourmis) 13:25 <jrandom> les tunnels client sont construits avec des pairs rapides, les tunnels exploratoires sont construits avec n’importe quel pair non défaillant 13:25 <jrandom> (choisi aléatoirement) 13:26 <bla> jrandom: Hmm.. Pour l’anonymat, c’est bien. Cependant, pour trouver rapidement de bons partenaires de tunnel à utiliser, il vaudrait mieux utiliser des pairs rapides dans les tunnels expl.... Le compromis, encore 13:26 <jrandom> d’un autre côté, il y a peut‑être quelque chose dans cette veine pour aider à optimiser la sélection des pairs 13:26 <jrandom> oh, oui, clairement tu aurais de meilleures performances en utilisant les pairs rapides, mais alors tu n’explorerais plus :) 13:27 <jrandom> les tunnels exploratoires ne sont pas utilisés pour des messages client de bout en bout, seulement pour des messages netDb (base de données du réseau), des messages de maintenance de tunnel et des messages de test de pair 13:27 <bla> jrandom: Je vois, donc effectivement, tu utilises des tunnels expl. aléatoires pour éviter de tomber dans des optima locaux ? 13:27 <jrandom> donc le débit réel des tunnels exploratoires n’a pas d’importance (tant que les données finissent par passer) 13:27 <jrandom> oui 13:29 <bla> jrandom: Ok, je vois. D’un autre côté : quand j’utilise mes tunnels client pour transférer des données (comme télécharger depuis un eepsite), il me semble (intuitivement) que les données de timing/débit sur cela pourraient servir à une sorte « d’évaluation passive des pairs », non ? 13:29 <jrandom> absolument bla, et pour le moment nous n’exploitons pas encore ces données dans la sélection par vitesse 13:29 <bla> jrandom: c.-à-d. comme moyen auxiliaire d’obtenir plus de données sur les pairs 13:30 <jrandom> une partie oui, mais une autre sera plus difficile à récupérer (puisque la bibliothèque de streaming est externe) 13:30 <jrandom> nous devrions clairement prendre ce que nous pouvons pour augmenter la confiance 13:30 <ant> <BS314159> ça ne dépendra pas du maillon le plus lent dans tout tunnel ? 13:31 <ant> <BS314159> ce qui rend très difficile l’usage pour des sauts>0 ? 13:31 <jrandom> BS314159: oui, mais ça s’annulera en moyenne, puisque les pairs sont sélectionnés aléatoirement au sein du niveau rapide 13:31 <jrandom> c’est pareil pour toute mesure distante 13:34 <jrandom> ok, voilà où on en est actuellement. Avec un peu de chance, nous aurons de nouveaux calculateurs et stats pour un build -4 ou -5 dans les prochains jours, pour voir comment cela se comporte sur le réseau en production 13:34 <jrandom> quelqu’un a autre chose pour 1) État du réseau ? 13:34 <bla> jrandom: Il peut sembler que j’insiste énormément dessus, mais ça me paraît être un problème très fondamental pour qu’un grand réseau I2P fonctionne... 13:35 <jrandom> bla: c’est certainement important, mais souviens-toi, nous n’avons pas besoin d’une sélection optimale des pairs. juste suffisante 13:35 <ant> <aum> bonjour tout le monde 13:36 <jrandom> tout ce qui nous importe, c’est trouver des pairs capables de gérer un tunnel, et s’assurer que ces tunnels peuvent gérer nos données 13:36 <jrandom> bonjour aum, juste à temps pour la réunion :) 13:36 <bla> jrandom: Je vois. Merci pour l’explication ! 13:36 <jrandom> bien sûr, tu as raison : ce serait génial si on /pouvait/ trouver la sélection optimale des pairs ;) 13:37 <jrandom> et il y a clairement beaucoup de place pour que des étudiants élaborent des idées et écrivent des papiers 13:37 <frosk> ce serait un super sujet de thèse :) 13:37 <+detonate> à quel point penses-tu qu’il serait praticable d’ajuster activement les paramètres de la sélection des pairs jusqu’à ce que ça converge vers quelque chose qui marche, en faisant abstraction de l’impossibilité de déboguer un tel système ? :) 13:38 <jrandom> detonate: la sélection manuelle des pairs est une vraie galère (PITA), car les pairs rapides se congestionnent parfois, te demandant de lever le pied, etc. 13:38 <+detonate> ah 13:39 <jrandom> je sais qu’on pourrait creuser ça sans fin, c’est pourquoi j’ai fixé un jalon : transférer avec succès un gros fichier spécifique via des tunnels standards, sans déconnexion 13:39 <+detonate> d’accord 13:40 <Teal> La victoire à tout prix ! 13:40 <jrandom> (d’un autre côté, il y a quelques fonctionnalités non documentées du système de sélection des pairs pour pondérer manuellement des pairs individuels, mais je ne les recommande pas ;) 13:40 <jrandom> ok, c’est à peu près tout pour le 1), passons au 2) Feedspace 13:41 * jrandom passe le micro à frosk 13:41 <frosk> oh, ok, salut 13:42 <Myo9> Salut Frosk. 13:42 * jrandom sort le projecteur haute intensité 13:42 <frosk> donc, tout le monde devrait jeter un œil à http://feedspace.i2p (clés chez orion ou sur le blog de jrandom) 13:42 <frosk> mon compagnon de dev (que je révèle maintenant sous le nom de ku) et moi avons commencé à écrire du code et avons eu de nombreuses discussions animées 13:42 <frosk> aussi, http://feedspace.i2p/wiki/CallForComments a une nouvelle révision du document Feedspace :) 13:43 <frosk> salut Myo9 13:43 <frosk> oh oui, Feedspace est notre nouveau (et définitif) nom pour ce qui s’appelait auparavant i2pcontent ou fusenet :) 13:43 <jrandom> r0x0r 13:43 <frosk> comme les notes d’état l’indiquent, nous sommes toujours très intéressés par des retours sur la conception générale de tout 13:44 <frosk> que personne ne soit timide à le remettre en question :) 13:44 <frosk> et le site web liste aussi quelques « postes à pourvoir », nous pourrions utiliser des coups de main sur de nombreux aspects du système et du projet 13:45 <frosk> nous avons un calendrier assez serré et aucun de nous n’est développeur à plein temps sur le projet malheureusement 13:45 <frosk> donc je crois que c’est tout, des questions ? :) 13:45 <ant> * aum n’arrive pas à joindre orion.i2p ou le blog de jrandom, donc ne peut pas atteindre feedspace.i2p 13:46 <frosk> hm oui, le site web a aussi une roadmap, mais les dates là _vont_ changer :) 13:46 <legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug 13:46 <legion> voilà, aum 13:46 * jrandom vient d’ajouter feedspace à http://dev.i2p.net/i2p/hosts.txt 13:46 <jrandom> (et cvs) 13:46 * frosk devient temporairement aveugle 13:46 <jrandom> legion: ne colle jamais ça sur une seule ligne, c’est trop grand pour tenir 13:47 <ant> <aum> merci 13:47 <frosk> jrandom peut probablement committer la clé dans son hosts.txt peut‑être ? :) 13:47 <jrandom> oui, c’est dessus maintenant, j’avais oublié :) 13:48 <frosk> quoi qu’il en soit, le plan est d’avoir quelque chose de simple et fonctionnel (et 100 % sans bug !) prêt pour I2P 0.6.1, et nous ajouterons des trucs sympas ensuite 13:49 <jrandom> heh wikked 13:49 <frosk> s/out/ready for real-world testing/ 13:49 <frosk> je ne peux toujours pas dire si c’est réaliste ou non, mais j’espère que oui, sinon on continuera à couper des fonctionnalités ;) 13:49 <ant> <BS314159> puisque je ne peux pas atteindre feedspace.i2p, je vais poser une question basique 13:50 <ant> <aum> cette clé n’est pas correcte, seulement 441 caractères 13:50 <jrandom> oui, aum, irc la tronque, prends http://dev.i2p.net/i2p/hosts.txt 13:51 <+detonate> frosk: j’ai une suggestion en attendant 13:51 <+detonate> mettre quelque chose sur la console du router I2P qui récupère une liste de mises à jour depuis le serveur web I2P, pour que les gens sachent quand mettre à jour leurs routers, etc :) 13:51 <legion> ah désolé pour ça. De toute façon je l’ai déjà ajoutée à mon hosts.txt aussi. 13:51 <ant> <aum> merci jrandom 13:51 <ant> <BS314159> lequel des systèmes suivants vois‑tu Feedspace remplacer : Usenet, Gnutella, Google, LiveJournal, WWW 13:52 <jrandom> , l’église 13:52 <jrandom> er.. 13:52 <cervantes> jrandom: ah tu m’as pris en plein commit de hosts 13:52 <ant> <BS314159> c.-à-d. est‑ce un forum de messages, un système de partage de fichiers, un système d’indexation de contenu, un système de pages dynamiques et/ou un système de diffusion statique 13:53 <ant> * aum désactive le throttling dans routerConsole et voit si ça aide 13:54 <frosk> BS314159: nous prendrons en charge les blogs, forums et carnets d’adresses partagés (pour la première version, d’autres applications sont possibles) 13:54 <frosk> ça ne remplace pas les pages web à proprement parler 13:54 <frosk> mais ça pourrait certainement être utilisé pour du « partage de fichiers » 13:54 <+detonate> donc de la syndication de contenu ? 13:54 <jrandom> cela remplacerait probablement le contenu web statique, en permettant une publication web persistante pour les personnes qui ne peuvent pas faire tourner des eepsites 13:54 <frosk> c’est de ça qu’il s’agit 13:55 <jrandom> (en deux mots : Usenet+SSK) 13:55 <frosk> ouais 13:55 <ant> <BS314159> ok 13:55 <Ragnarok> pas si persistant que ça 13:56 <jrandom> Ragnarok: selon la politique du syndicateur, en effet 13:56 <+detonate> il se passe quelque chose avec stasher ? 13:56 <frosk> ça peut être aussi persistant que le syndicateur le plus zélé :) 13:56 <jrandom> (cf. DejaNews ;) 13:56 <ant> <aum> detonate: stasher est en pause, j’écris un tout nouveau truc appelé quartermaster 13:57 <+detonate> je vois 13:58 <jrandom> frosk: que peut‑on faire pour aider ? 13:59 <jrandom> les gens devraient-ils s’inscrire et bidouiller le wiki, envoyer un e‑mail, poster sur le forum ? 13:59 <jrandom> oh, peut‑être qu’on peut demander à cervantes d’ajouter une nouvelle catégorie de forum ? 13:59 <frosk> je pense qu’en fait un forum serait très bien à ce stade 14:00 <frosk> pour une discussion plus privée, vous pouvez nous écrire tous les deux à ku@mail.i2p et frosk@mail.i2p 14:01 <cervantes> hrrrm ... vous allez y mettre des critiques de jeux ? 14:01 <jrandom> heh 14:01 <jrandom> w3rd 14:01 <cervantes> parce que sinon... vous êtes les bienvenus pour avoir une nouvelle section de forum 14:01 <frosk> je pensais à des critiques du top 20 musical, cervantes 14:02 <jrandom> (au fait, miroir de l’appel à commentaires @ http://dev.i2p.net/~jrandom/feedspace.txt) 14:02 <cervantes> :) 14:04 <cervantes> frosk: feedspace ou feed space ou Feedspace ou Feed Space ou FeedSpace ? 14:04 <frosk> cervantes: Feedspace 14:05 <frosk> hâte de nombreuses discussions sur le forum alors :) je n’ai rien d’autre pour ce point, quelqu’un d’autre ? 14:05 <jrandom> ok cool, merci pour la mise à jour frosk 14:06 <@smeghead> ou FEeDspace ? 14:06 <ant> <cervantes> frosk: quand tu as un moment, envoie‑moi en privé une description en une ligne pour la section du forum 14:06 <legion> hmm en parlant de nouveaux forums, lol. Je monte un nouveau site de forum. Même si j’ai encore beaucoup à bidouiller dans le code phpbb, ça devrait être fini d’ici cette semaine. ;) 14:06 <jrandom> cool legion 14:06 <jrandom> ça nous amène justement au 3) ??? 14:06 <jrandom> quelqu’un a autre chose à soulever ? 14:06 <jrandom> aum: des nouvelles de Q ? 14:07 <frosk> je, euh, non 14:07 <ant> <aum> le développement de Q avance bien, rien à annoncer pour l’instant 14:07 <jrandom> w3rd 14:07 <ant> * aum est à 90 % sur net.i2p.i2ptunnel.I2PTunnelXMLServer 14:07 <ant> <BS314159> j’ai une question simple à propos de netDb 14:07 <ant> <aum> tout fonctionne maintenant sauf 'i2p.tunnel.close' 14:07 <legion> mes forums permettront aux membres d’avoir des avatars de taille décente, de discuter de contenu partagé, à peu près de tout. 14:08 <jrandom> wikked 14:08 <ant> <BS314159> il est dit sur la page que les entrées sont stockées sur les pairs les plus proches de SHA256(router identity + YYYYMMdd) 14:08 <jrandom> oui BSpi 14:08 <@smeghead> legion: ce sera aussi dangereux pour la sécurité que ton client bt ? 14:08 <ant> <BS314159> est‑ce que cela signifie qu’il y a une pointe de trafic à chaque 00:00 GMT ? 14:08 <ant> * aum commence en fait à être plus à l’aise en Java, ayant atteint une « masse critique cognitive » 14:09 <jrandom> BS: les points de données expirent plus fréquemment qu’ils ne migrent 14:09 <jrandom> un LeaseSet (ensemble de baux dans I2P) n’est valable que 10 minutes, par exemple 14:09 <bla> jrandom: Y a‑t‑il un appel en ligne de commande que je puisse faire, pour obtenir des estimations de vitesse de chacun des pairs du réseau sur, disons, les 60 dernières secondes ? 14:09 <legion> lol, des forums, un danger pour la sécurité ? 14:10 <@smeghead> legion: oui, et si tu ne sais même pas ça, je suis déjà convaincu que tes forums seront un danger pour la sécurité 14:10 <jrandom> bla: oui, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/* 14:10 <jrandom> (je crois) 14:10 <legion> oh et la prochaine version de mon client bt ne devrait pas causer de tels problèmes... 14:10 <jrandom> il faudra peut‑être ajouter quelques niveaux de log dans logger.config, laisse‑moi vérifier 14:10 <@smeghead> legion: Cervantes a fait une tonne de modifications à phpBB pour le verrouiller pour l’usage I2P 14:10 <ant> <BS314159> Ça me paraît maladroit que ça arrive tout d’un coup à une heure donnée. Si ça se produisait en continu, ce serait... plus fluide. Ça donnerait aussi moins de temps à un attaquant pour monter une attaque, puisque des morceaux de données seraient erronés en moins de 24 heures 14:11 <jrandom> non, ça écrit sur stdout 14:11 <frosk> jrandom: que penses‑tu de la roadmap I2P actuellement, si on peut demander ? tu penses que c’est réaliste ? 14:11 <legion> Hmm je me demande si je peux obtenir une copie des mods de cervantes ? 14:11 <jrandom> frosk: je la mets à jour quand je ne me sens plus à l’aise avec 14:12 <frosk> ok 14:12 <+detonate> tu sais, il existe un installateur Windows pour Python 2.4, un pour wxPython, et il y a l’archive i2p-bt, je ne vois pas vraiment pourquoi quelqu’un prendrait/ferait confiance à une sortie tierce 14:12 <legion> Sinon je vais juste continuer à bidouiller le code source de phpbb... 14:12 <jrandom> BS: les pairs ne regarderaient au mauvais endroit que jusqu’à 30 s, grâce à la synchronisation des horloges 14:12 <@smeghead> legion: amuse-toi bien 14:12 <legion> eh bien pourquoi quelqu’un utiliserait et lancerait kazaa ? 14:13 <bla> jrandom: Je demande parce que... 14:13 <legion> Ou morpheus ? 14:13 <jrandom> (parce qu’ils ne savent pas mieux ?) 14:13 <legion> Ces deux-là contiennent de l’adware/etc... 14:13 <+detonate> ils sont ignorants ? 14:14 <legion> oui et il y a des millions d’utilisateurs ignorants dehors. ;) 14:14 <ant> <BS314159> legion: on dirait que tu veux livrer I2P avec des spyware. Vraiment, un coup de génie. 14:14 <bla> jrandom: ...j’ai parcouru SpeedCalculator.java et CapacityCalculator.java, et j’aimerais expérimenter avec les estimateurs 14:14 <cervantes> legion: reste à jour avec les correctifs officiels, et mets un htaccess sur les zones d’admin 14:14 <jrandom> wikked bla 14:14 <legion> Quoi ? Certainement pas... Je déteste les malwares... 14:14 <cervantes> la plupart de mes mods concernent la prévention du spam 14:14 <ant> <aum> puis-je soulever un point plus critique ? 14:14 <legion> C’est tout ? cervantes ? 14:15 <jrandom> quoi de neuf aum ? 14:15 <@smeghead> legion: et tes utilisateurs qui détestent aussi les malwares ? pourquoi ne fais-tu rien pour apaiser leurs inquiétudes ? 14:15 <ant> <dm> BS314159: es-tu un hotfix Windows ? 14:15 <ant> <aum> est-ce juste moi, ou bien il y a encore de l’instabilité dans i2p ? j’ai des tas de problèmes même avec les eepsites principaux, irc etc. 14:15 <bla> jrandom: En plus, l’idée de « fingerprinting passif » me trotte maintenant dans la tête (un peu ;): si je reçois des données via un tunnel, cela me dit quelque chose sur la bande passante/capacité de tous les pairs dans ce tunnel :... 14:15 <jrandom> aum: vois les notes d’état hebdomadaires 14:16 <cervantes> legion: renomme toutes les pages d’inscription, connexion, publication et édition de profil en quelque chose de non standard 14:16 <bla> jrandom: Ça m’en dit pas mal sur le pair le plus proche de moi, un peu moins sur les pairs à un saut, et ainsi de suite de moins en moins. 14:16 <cervantes> ça aidera à tenir les vers à distance 14:16 <jrandom> bla: oui, j’ai lu cet article sur le timing, et l’article d’attaque tor d’hier avec beaucoup d’intérêt 14:17 <Myo9> Cervantes, publieras-tu quelques-uns de tes mods ? 14:17 <Myo9> s/ant/any/ 14:17 <jrandom> il y a des inquiétudes de ce genre dans le calculateur de capacité avec les différents niveaux de rejet 14:18 <bla> jrandom: D’une certaine manière, ça me donne un certain degré de « croyance » dans la bande passante/capacité d’un pair (ce degré de croyance dépend de la distance à chacun des membres du tunnel, et du degré de croyance que j’ai sur la BP/cap. des nœuds les plus proches de moi) 14:18 <legion> merci pour les conseils cervantes :) 14:18 <bla> jrandom: Et il se trouve que je connais des gens qui en savent beaucoup sur les réseaux bayésiens (Bayesian Belief Networks)... ;)) 14:18 <@smeghead> encore une fois, legion ignore la question 14:18 <+thetower> Je pense qu’on va tous devoir faire une trêve avec legion et le laisser écrire ce qu’il veut, personne n’est forcé de l’utiliser. 14:18 <jrandom> hmm, que veux‑tu dire par distance bla ? 14:18 <ant> <dm> que fabrique legion ? 14:19 <bla> jrandom: Je vais en parler avec eux, concernant le fingerprinting passif (remarque : je n’entends pas « fingerprinting » au sens négatif du terme) 14:19 <jrandom> wikked 14:19 <jrandom> les suggestions sur la meilleure manière de sélectionner des pairs « de qualité » sont les bienvenues 14:19 <cervantes> Myo9: je pourrais tout à fait. 14:19 <legion> De toute façon il n’y a pas beaucoup d’utilisateurs I2P Windows pour l’instant et pas tant que ça qui utilisent ma distribution binaire i2p-bt. Bientôt ma prochaine version sera prête et publiée, elle n’aura pas de tels problèmes... Comme il y aura une distribution binaire et une source. 14:19 <@smeghead> pourquoi quelqu’un voudrait utiliser un logiciel provenant de quelqu’un qui ne prend même pas les mesures de base pour répondre aux préoccupations de ses utilisateurs en matière de sécurité et d’anonymat me dépasse 14:20 <ant> <aum> frosk: en quel langage écris-tu Feedspace ? (pardonne-moi si je t’ai déjà demandé) 14:20 <cervantes> ce n’est pas un « patch » propre ou quoi que ce soit 14:20 <bla> jrandom: distance... Disons que j’ai un tunnel entrant X -> Y -> moi, et que je sais _beaucoup_ de choses sur les propriétés de Y, alors les stats sur ce que je reçois via ce tunnel m’en disent pas mal sur X 14:20 <frosk> aum: java (et je te pardonne ;) 14:20 <cervantes> J’ai juste corrigé des trucs et des problèmes à mesure qu’ils surgissaient 14:20 <bla> jrandom: À l’inverse, si j’ai peu de données/croyance sur les propriétés de Y, les stats de transfert ne m’en disent pas beaucoup sur X encore ; j’ai d’abord plus à apprendre sur Y 14:20 <cervantes> 14:20 <cervantes> http://forum.i2p/index.php?c=4 14:21 <cervantes> nouvelle section : Feedspace 14:21 <jrandom> w00t 14:21 <frosk> yay 14:22 <legion> de toute façon, assez de discussion sur ma version, toute discussion supplémentaire à ce sujet devrait se faire sur le canal #itorrent 14:22 <bla> jrandom: C’est vrai. Cependant, compte tenu d’une grande quantité de données (et en espérant que le temps de mesure n’est pas _beaucoup_ plus grand que l’échelle de temps sur laquelle les propriétés des nœuds changent), je suis convaincu qu’il doit y avoir de l’information dans les stats de trafic/tunnel 14:22 <@smeghead> legion: on peut en discuter au point de réunion # 3) toute affaire qui concerne i2p 14:23 <@smeghead> legion: et je pense que ton logiciel est une préoccupation sérieuse et mérite un avertissement aux utilisateurs 14:23 <legion> d’accord, ok 14:23 <jrandom> bla: certainement, il nous suffit d’intégrer le RTT depuis OutboundClientMessageOneShotJob 14:23 <jrandom> (et ensuite déterminer la meilleure façon de calculer et d’appliquer une décroissance aux données) 14:24 <legion> Alors smeghead si tu devais faire une telle release, que ferais-tu différemment ? 14:24 <@smeghead> legion: la façon dont tu esquives continuellement les questions et essaies de différer la discussion sur le sujet est très inquiétante 14:25 <@smeghead> legion: d’abord, publie la source de ton binaire actuel, même si ce n’est « que i2p-bt avec le patch de smeghead », et rédige sur ton site une explication concernant ton fork 14:25 <bla> jrandom: que signifie le RTT là ? 14:26 <@smeghead> legion: ce serait utile aussi de faire comme i2p-bt, et de fournir un changelog indiquant toutes les modifications que tu as faites 14:27 <jrandom> bla: les messages client de bout en bout sont souvent (par défaut, toujours) regroupés dans un enrobage garlic, contenant un DeliveryStatusMessage supplémentaire qui revient à l’expéditeur (via des tunnels, bien sûr), permettant l’utilisation de AES+sessionTags au lieu de ElGamal 14:28 <bla> jrandom: (oui) 14:28 <+detonate> comme je l’ai dit, tu pourrais juste fournir un lien vers la page de téléchargement pour les trois choses nécessaires au fonctionnement d’i2p-bt, c’est simple et tu obtiens exactement la même chose, je ne vois pas vraiment d’utilité à part un cheval de Troie 14:28 <jrandom> plus tard, nous mettrons à jour I2CP (et le SDK) pour permettre à la bibliothèque de streaming de fournir la même donnée sans nécessiter le DeliveryStatusMessage 14:29 <@smeghead> detonate: je suis d’accord, il aurait simplement dû soumettre un patch à l’i2p-bt officiel, le fork était complètement inutile et a suscité immédiatement de la suspicion 14:30 <+detonate> en effet 14:30 <@smeghead> *suspicion 14:31 <jrandom> ok, quelqu’un d’autre a quelque chose à évoquer pour la réunion ? 14:31 <ant> <drakoh> salut les gens ! je voulais savoir, y a‑t‑il quelque chose de spécial avec le réseau ? 14:32 <@smeghead> à cause de la nature d’i2p, les applications développées pour lui nécessitent une plus grande mesure d’ouverture envers les utilisateurs finaux et de coopération entre développeurs 14:32 <jrandom> drakoh: vois les notes d’état hebdomadaires 14:32 <bla> quit 14:32 <ant> <drakoh> non je veux dire quelque chose d’étrange ... 14:32 <@smeghead> les utilisateurs d’I2P seront toujours naturellement paranoïaques à un certain degré, et il est de notre devoir de faire ce que nous pouvons pour dissiper toutes les inquiétudes possibles 14:32 <ant> <drakoh> comme j’ai perdu tous mes pairs 14:33 <jrandom> oui, d’accord smeghead. pour un logiciel d’anonymat ou de sécurité, surtout dans un domaine truffé de chevaux de Troie comme le partage de fichiers, il est essentiel d’être ouvert. 14:33 <jrandom> drakoh: ok, attends, on pourra déboguer ça une fois la réunion terminée 14:33 <ant> <drakoh> oups désolé 14:33 <jrandom> ok, en parlant de la fin de la réunion... 14:34 * jrandom conclut 14:34 * jrandom *baf* clôt la réunion