Réunion des développeurs I2P - 10 janvier 2006

15:26 <jrandom> 0) salut 15:26 <jrandom> 1) État du réseau 15:26 <jrandom> 2) Profilage du débit 15:26 <jrandom> 3) Blogs Syndie 15:26 <jrandom> 4) Connexions HTTP persistantes 15:26 <jrandom> 5) I2Phex gwebcache 15:26 <jrandom> 6) ??? 15:26 * jrandom fait signe de la main 15:26 <jrandom> notes d'état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2006-January/001247.html 15:27 <jrandom> (oui, je sais... il nous faut un 7) Une dernière chose...) 15:28 <jrandom> on attaque 1) État du réseau 15:28 <jrandom> En général, c'est toujours la même chanson, en dehors de ce qui est dans le mail. 15:28 <jrandom> Quelqu’un a-t-il quelque chose à soulever au sujet de 1) ? 15:30 <jrandom> ok, sinon, on passe à 2) Profilage du débit 15:31 <tethra> ça a l'air cool, mais puis-je demander quel est l'objectif ? 15:31 <jrandom> trouver des pairs rapides 15:31 <tethra> (pardonnez mon manque d'esprit et de tact) 15:31 <tethra> ah, cool. 15:32 <jrandom> en gros, notre ancien profilage de vitesse n'était pas terrible (voir les notes d'état de la semaine dernière pour un résumé), et celui-ci semble assez bon pour trouver des pairs que je sais être fast 15:32 <jrandom> (je sais qu’ils sont fast parce que j’ai triché et les ai mesurés avec des techniques non anonymes) 15:33 <tethra> scandaleux ! ;) 15:33 <jrandom> ((oui, quelqu’un aurait pu être fou et monter des attaques pour fausser mes mesures, mais bon, j’en doute ;) 15:33 <tethra> haha 15:33 <tethra> cool, donc cela devrait faire que les client tunnels trouvent plus facilement un pair 'good' et, vraisemblablement, mettre les pairs 'fast' sous moins de pression, alors ? 15:35 <tethra> s/'good'/fast/ 15:35 <jrandom> oui pour le premier, mais pas vraiment pour le second — cela ne réduira pas la pression sur eux, mais permettra aux gens d’en faire un usage plus efficace 15:35 <@cervantes> j’imagine que ceux qui ont des pairs fast devront espérer que le bridage des pairs soit suffisant pour encaisser la participation supplémentaire 15:36 <jrandom> par ex., au lieu d’avoir $slow-->$fast-->$fast, ce sera $fast-->$fast-->$fast 15:36 <tethra> ah, je vois 15:36 <jrandom> oui cervantes, je fais attention au profil de capacité aussi, et ça fait l’affaire 15:36 <@cervantes> parfait 15:37 <jrandom> l’interaction entre capacité et vitesse est importante — les pairs ne sont pas considérés fast s’ils ne sont pas de haute capacité, même si leur vitesse est mieux classée que celle des autres 15:37 <@cervantes> il sera intéressant de voir comment cela affecte le débit 15:37 <jrandom> (c’est pourquoi 'fast' est juste un raccourci pour 'fast and high capacity') 15:37 <@cervantes> +h 15:37 <jrandom> oui cervantes 15:39 <jrandom> ok, s’il n’y a rien d’autre sur 2, passons à 3) Blogs Syndie 15:40 <jrandom> je n’ai pas grand-chose à ajouter au-delà de ce qui est dans le mail 15:41 <@cervantes> ça a l’air très bien 15:41 <tethra> j’aime beaucoup la direction que prennent les blogs, personnellement. on pourrait dire que tout cela, c’est du bonus. 15:41 <tethra> :D 15:41 <+Complication> Un peu en retard, désolé. 15:42 <jrandom> cool, c’est similaire à ce que c’était au départ, mais je pense que la vue blog a du potentiel 15:42 <jrandom> re Complication, pas d’inquiétude, on a les logs :) 15:43 <+Complication> Je lis l’historique en ce moment :) 15:43 <jrandom> je pense qu’il y a une place pour les deux vues, j’imagine que cela dépend simplement de l’utilisateur 15:43 <jrandom> (ainsi que du contenu et de l’auteur) 15:45 <jrandom> une chose toutefois, c’est que le html n’est pas terrible. cervantes m’aide à remettre à niveau mes connaissances très basiques vers une vision plus moderne, mais il reste beaucoup de points à traiter 15:46 <jrandom> il y aura des améliorations continues à l’interface web de Syndie, et si un bénévole html voulait aider pour la mise en forme, le design, le css, les problèmes de compatibilité multi-navigateurs, etc., ce serait très apprécié 15:47 <@cervantes> à part deux balises d’ouverture <style> le code a l’air plutôt propre ;-) 15:47 <jrandom> heh oups 15:48 <@cervantes> je pense que l’accent sera mis sur un style propre et lisible et peut-être la conception de quelques templates alternatifs 15:48 <jrandom> hmm 15:49 <jrandom> c’est une chose à laquelle je pensais pour la vue blog — il serait facile de laisser les gens personnaliser certains attributs (couleurs, polices, tailles), mais je ne sais pas jusqu’où aller 15:50 <jrandom> d’un autre côté, la vue blog, comme la vue fil de discussion, n’est qu’un template au-dessus de l’archive Syndie 15:50 <@cervantes> en tout cas, vous ne voulez certainement pas permettre des templates déployables 15:50 <jrandom> donc la question est : un template pour qui ? 15:50 <jrandom> (quel niveau d’expérience faudrait-il à ceux qui utilisent le template) 15:51 <@cervantes> je pensais simplement à une option de configuration via popup que quelqu’un peut choisir pour son blog 15:51 <jrandom> hmm ? 15:51 <@cervantes> je veux « Pony Look » 15:51 <jrandom> ah, ok 15:51 <@cervantes> donc on livre Syndie avec une variété de skins 15:52 <jrandom> oui, couleurs/police/etc. prédéfinies 15:52 <jrandom> (et des icônes, etc.) 15:52 <jrandom> c’est une chose qui n’a pas encore vraiment été implémentée via la vue blog 15:54 <jrandom> bonne idée pour un sélecteur de thème simple, plutôt qu’une série d’options complexe 15:54 <@cervantes> une alternative serait que quelqu’un propose ses propres presets de template en téléchargement sur son site — qui pourraient être enregistrés dans un dossier de thèmes 15:55 <@cervantes> c’est à chacun de décider s’il veut faire confiance au skin personnalisé de l’auteur du blog 15:55 <jrandom> ... confiance ? 15:55 <jrandom> rien dans Syndie ne permettra de faire du html ou du css non sûrs 15:55 <tethra> et le javascript non sûr/etc. ? 15:55 <jrandom> les skins seraient des fichiers texte/fichiers de config/images, plutôt que du jsp 15:55 <tethra> ? 15:56 <tethra> (redirection de page vers des adresses non anonymes avec du js, par exemple ?) 15:56 <@cervantes> ça dépend si un thème peut aussi contenir des changements structurels en html 15:56 <@cervantes> d’accord, ok 15:56 <@cervantes> eh bien, cela resterait propre et simple 15:57 <jrandom> tethra : je suis... incroyablement hésitant à propos du javascript. vu le nouveau billet de blog aujourd’hui de default ? 15:57 <jrandom> "je suis juste curieux : est-ce que ça utilise AJAX ? La page ne semble pas se mettre à jour dans son ensemble..." 15:57 <tethra> nein, je ne l’ai pas vu. 15:57 <tethra> moi, je trouverais un moyen de virer tout js utilisé, personnellement. 15:58 <jrandom> puisque Syndie est *local*, c’est incroyablement rapide, et nous n’avons pas à nous soucier des mêmes problèmes de latence 15:58 <tethra> car je ne lui fais absolument pas confiance. 15:58 <tethra> hmm :/ 15:58 <jrandom> cervantes : oui, très simple — on pourrait même permettre aux gens qui voient un thème de blog qu’ils aiment de dire « voler ce thème » 15:59 <@cervantes> en théorie, on pourrait fournir une bibliothèque de fonctions « safe » pour l’utilisateur du blog — mais une fois que vous avez retiré tout ce qui est non sûr de l’implémentation d’un navigateur moyen, il ne reste que la fonction « alert(); » 16:00 <jrandom> heh 16:00 <jrandom> (et il y a toutes ces questions d’accessibilité du javascript) 16:00 <+Complication> cervantes : attention, alert() dans une boucle infinie, ça peut être mauvais :P 16:00 * jrandom est assez fier de la convivialité de Syndie avec lynx 16:00 <tethra> lynx <3 16:02 <jrandom> ok, s’il n’y a rien d’autre sur 3), passons à 4) Connexions HTTP persistantes 16:02 <jrandom> je n’ai rien à ajouter au-delà de ce qui est dans le mail... zzz, tu es là ? 16:02 <@cervantes> il y a d’autres façons d’implémenter une interface AJAX *spit*, comme une extension mozilla 16:03 <jrandom> fire2pe++ :) 16:03 <jrandom> zzz ne semble pas là, donc il faudra probablement attendre plus tard pour plus d’infos sur 4) 16:03 <@cervantes> fire2pe n’est qu’un assistant — tu veux dire syndilla ;-) 16:03 <jrandom> lol 16:04 <jrandom> (et, la version sur porte-clés USB, syndog ;) 16:04 <jrandom> ok, passons à 5) I2Phex gwebcache 16:05 <jrandom> Complication: p1ng 16:05 <+Complication> Eh bien, puisque cela faciliterait l’intégration au réseau... 16:06 <+Complication> ...j’ai récemment travaillé à ressusciter le code gwebcache déjà dans I2Phex 16:06 <+Complication> À ce stade, il fait déjà des choses très limitées (comme planter proprement) :) 16:06 <+Complication> Il embête aussi le serveur webcache d’awup avec un succès modéré 16:07 <jrandom> lol sympa 16:07 <+Complication> J’ai bon espoir toutefois de parvenir à le remanier 16:07 <+Complication> (beaucoup est actuellement prévu pour gérer des adresses IP) 16:09 <jrandom> cool, bonne chance, et dis-moi s’il y a quoi que ce soit que je puisse faire pour aider 16:09 <+Complication> Je ferai ça :) 16:10 <jrandom> ok, autre chose sur 5) I2Phex gwebcache, ou on se dirige tranquillement vers 6) ??? 16:11 <jrandom> considérez que c’est fait 16:11 <jrandom> quelqu’un a-t-il autre chose pour la réunion ? 16:11 <@cervantes> une autre tasse de thé serait bien 16:12 <tethra> heheh 16:12 <Pseudonym> où en est la feuille de route ? 16:12 <jrandom> pas de changements 16:12 <Pseudonym> que reste-t-il pour 0.6.2 ? 16:13 <jrandom> tout ce qui concerne 0.6.2 16:13 * jrandom se baisse 16:14 <Pseudonym> :-P 16:14 <@cervantes> un peu de bling bling 16:14 <Pseudonym> avons-nous une date/échéancier provisoire ? 16:14 <jrandom> spécifiquement, la nouvelle crypto et les algorithmes de création de tunnels, les nouvelles stratégies de sélection des pairs 16:14 <tethra> heheh 16:14 <jrandom> pas de dates ni d’échéanciers (du moins, pas annoncés en réunion ;) 16:15 <Pseudonym> y a-t-il plus, dans les stratégies de sélection des pairs, que le truc de débit sur lequel tu as travaillé ? 16:16 <jrandom> oui, ces changements de profilage des pairs relèvent des performances, pas des stratégies de sélection et d’ordonnancement liées à l’anonymat 16:16 <+Complication> jrandom : est-ce que je me souviens bien... si je suppose que la crypto de création de tunnels est liée aux sujets discutés sur la liste, pendant la discussion sur les attaques de prédécesseur (et autres) ? 16:17 <jrandom> oui Complication 16:17 <+Complication> s/related/relates 16:19 <+Complication> Tu vas essayer de faire fonctionner cette petite structure de données sympa ? 16:19 <jrandom> oui 16:20 <jrandom> (donc, 0.6.2 n’est pas à l’horizon de 2 semaines ;) 16:20 <+Complication> Chouette. Ça a l’air intéressant, je devrais probablement me documenter 16:21 <+Complication> J’espère que ça se passera bien 16:21 <jrandom> ça n’a été qu’esquissé sur la liste, aucune spécification formalisée pour l’instant 16:21 <tethra> désolé, de quelle structure de données sympa s’agit-il ? 16:21 <+Complication> Oh, et j’ai compris pourquoi le lien (depuis le message « moo ») ne fonctionnait pas. :D C’est freedomarchives.i2p (au pluriel, avec un « s » à la fin) 16:21 <jrandom> ce sera rétro-incompatible, donc « fluide » ne sera pas son slogan, mais avec un peu de chance ça ne fera pas trop mal :) 16:21 <jrandom> ah mince 16:22 <jrandom> tethra : une structure de données qui n’existe pas encore pour créer des tunnels 16:22 <tethra> cool 16:22 <jrandom> (voir les fils sur les prédécesseurs, vers novembre) 16:23 <tethra> quels avantages/inconvénients aura-t-elle par rapport à l’actuelle ? (s’il y en a une actuelle :o) 16:23 <jrandom> (voir les fils sur les prédécesseurs, vers novembre) ;) 16:23 <tethra> ah, ok 16:23 <+Complication> si je me souviens bien, pour rendre la création de tunnels moins transparente aux observateurs 16:23 <tethra> "" 16:23 <tethra> ;) 16:23 <jrandom> mais ce n’est pas une proposition, il n’y a rien sur la table pour 0.6.2 tant que tout ce qui précède 0.6.2 n’est pas réglé. 16:23 <jrandom> une fois que ce qui doit fonctionner fonctionne comme nous en avons besoin, alors on passe à la suite. 16:24 <Pseudonym> à part la sélection de pairs fast, qu’est-ce qui ne fonctionne pas ? 16:25 <jrandom> la sélection de pairs fast fait partie de la « bonne performance » 16:25 <jrandom> nous avons bel et bien de bonnes performances, pour un réseau anonyme, mais pas assez bonnes pour rivaliser avec les réseaux non anonymes 16:25 <jrandom> pour rivaliser, il nous faut de meilleures performances *et* fournir des fonctionnalités qu’ils ne peuvent pas obtenir ailleurs 16:26 <jrandom> (l’anonymat ne fait pas vendre) 16:26 <Pseudonym> y a-t-il plus que la sélection de pairs fast ? 16:27 <jrandom> au cours du dernier mois ou deux, en benchmarkant différents aspects d’i2p, la sélection de pairs lente semble être le plus petit goulot d’étranglement. on ne sait pas quel sera le prochain goulot d’étranglement. 16:27 <jrandom> (il y a aussi eu d’innombrables améliorations à différents endroits pour améliorer les performances) 16:27 <jrandom> (voir http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD ) 16:28 <Pseudonym> donc... publication de la nouvelle sélection de pairs cette semaine ? ;-) 16:28 <teal`c_> i2p, ça tourne bien 16:29 <jrandom> Pseudonym : oui, le nouvel algorithme de profil de pairs est dans cvs et sera déployé cette semaine avec 0.6.1.9 16:30 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:30 <Pseudonym> cool 16:31 <jrandom> sinon... 16:31 * jrandom prend de l’élan 16:32 * jrandom clôt la réunion d’un *baf*