Réunion des développeurs I2P - 20 décembre 2005

15:20 <jrandom> 0) salut 15:20 <jrandom> 1) État du réseau 15:20 <jrandom> 2) Mises à jour I2PSnark 15:20 <jrandom> 3) IU du blog Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) salut 15:20 * jrandom fait un signe de la main 15:20 <jrandom> notes d'état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ok, passons à 1) État du réseau 15:22 <jrandom> Je n'ai pas grand-chose à ajouter au-delà de ce qui est dans les notes d'état. 15:22 <+Complication> S'il n'y avait pas les OOM (Out Of Memory, manque de mémoire) occasionnels, j'oserais dire que c'est bon 15:22 <jrandom> les tests de charge sont très prometteurs, ce qui suggère que nous avons beaucoup de marge pour améliorer les performances 15:23 <+Complication> Et je suppose que les OOM 15:23 <jrandom> heh, des OOM liés à i2psnark ? ou d'avant ? 15:23 <+Complication> contribuent à l'instabilité, lorsque des instances de i2p-bt, i2psnark ou i2p-rufus font... des choses. 15:24 <zzz> ma théorie est que l'augmentation du trafic torrent affecte quelque peu la fiabilité d'IRC 15:24 <+Complication> (je ne devrais peut-être pas appeler l'étrangeté de SAM un OOM, puisque je n'y ai pas regardé de près, mais c'est sûrement l'un des facteurs) 15:24 <jrandom> hmm, je ne suis pas sûr, l’état de irc était similaire à avant les dernières mises à jour de snark 15:25 <+Complication> La bande passante a été stable, en particulier les tunnels aussi... juste des crashs de temps en temps 15:26 <zzz> Quoi qu’il en soit, je suis optimiste : les correctifs de construction de tunnel qui arrivent en 0.6.1.8 amélioreront l'expérience IRC des gens 15:26 <+Complication> Pour des raisons connues, qui disparaîtront j'espère en temps voulu :) 15:26 <jrandom> ouais, je le pense aussi zzz, donc nous publierons probablement une version d’ici un jour ou deux 15:26 <+legion> Eh bien irc est peut-être trop sensible, peut-être qu’utiliser quelque chose comme jabber serait mieux ? 15:26 <zzz> surtout pour les personnes sur des machines et/ou connexions plus lentes 15:27 <jrandom> jabber ne changerait rien 15:27 <+Complication> Surtout avec la redondance de tunnel à 2 15:28 <+bar> je dirais que irc est un excellent merd-o-mètre pour déterminer la météo du réseau 15:28 <+legion> Ouais, il suffit qu’un petit vent souffle et irc se vautre 15:28 <+bar> exactement :) 15:28 <+Complication> Je remarque qu’après la correction du shitlisting, "Recent" a tendance à toujours dépasser "Known" 15:29 <+Complication> Est-ce parce que "Known" n’inclut pas les pairs sur la shitlist, alors que "Recent" les inclut ? 15:29 <jrandom> ouais, irc donne une bonne vue des choses, car il montre des variations substantielles selon les utilisateurs (par ex. dreamtheaterfan a toujours des soucis, etc.) 15:30 <jrandom> hmm, ça se tient Complication 15:30 <+Complication> (je ne suis pas sûr, je suppose) 15:30 <jrandom> (puisque les pairs sur la shitlist sont retirés du netDb, mais leurs profils ne sont pas supprimés) 15:32 <+Complication> Alors les indicateurs semblent OK (je voulais juste demander au cas où ils ne le seraient pas) 15:33 <jrandom> ok, autre chose sur 1) État du réseau ? 15:33 <jrandom> sinon, passons à 2) Mises à jour I2PSnark 15:33 <tealc_> quel genre de mises à jour sont disponibles ? 15:34 <jrandom> voir http://dev.i2p.net/pipermail/i2p/2005-December/001240.html pour un bref aperçu ;) 15:34 <jrandom> en gros I2PSnark peut désormais gérer plusieurs torrents à la fois sur une seule destination I2P, dispose d’une interface web, et est intégré à la console du router 15:35 <tealc_> j’utilise les derniers builds cvs et i2psnark provoque beaucoup d’erreurs de tas mémoire ou je ne sais quoi 15:35 <+Complication> ...et il gère aussi les torrents créés par Azureus avec des méta-balises bizarres. 15:35 <+Complication> Sur lesquels il se bloquait auparavant. 15:35 <jrandom> ah, oui, il reste encore des trucs que je débogue là-dedans tealc_ 15:35 <jrandom> (comme mentionné dans les notes d’état hebdomadaires ;) 15:35 <jrandom> ah oui Complication 15:36 <jrandom> oh, aussi, les gens d’Azureus ont corrigé un bug dans leur tracker qui empêchait I2PSnark de l’utiliser 15:36 <jrandom> (donc les personnes faisant tourner des trackers azureus avant B16 devraient mettre à jour dès que possible) 15:37 <+bar> j’aimerais avoir la possibilité de désactiver facilement le démarrage automatique d’i2psnark (pour des scénarios de faible bande passante, etc.) 15:38 <jrandom> ça devrait être assez facile à ajouter 15:38 <+bar> parfait 15:39 <jrandom> ok, autre chose sur 2) Mises à jour I2PSnark ? 15:40 <jrandom> sinon, passons à 3) IU du blog Syndie 15:40 <zzz> double bravo pour le nouveau i2psnark - beau boulot 15:41 <jrandom> merci, mjw a fait le gros du travail, rendant snark si facile à étendre 15:41 <jrandom> ok, comme mentionné dans les notes d’état, syndie a maintenant une nouvelle IU de blog 15:42 <jrandom> Je pense que cela offrira un équilibre entre listes blanches et listes noires, pour gérer les différents problèmes de spam auxquels les gens peuvent être confrontés 15:43 <jrandom> nous le déploierons dans la prochaine version, afin que vous puissiez vous y plonger d’ici un jour ou deux 15:43 <+legion> Le spam va-t-il vraiment devenir un gros problème bientôt ? 15:44 <+Complication> legion : comme quelqu’un a bien voulu le démontrer, ça pourrait 15:44 <jrandom> bof, les listes noires s’occupent des auteurs qui floodent, et les listes blanches de ceux qui créent plein d’auteurs 15:44 <dust> (l’anonymat fait ressortir le pire chez certaines personnes) 15:44 <jrandom> (donc le spam n’est pas un problème) 15:45 <+Complication> (Bien que je pense que le gars régénérait des clés pour éviter une mise sur liste noire permanente, ce qui est un certain ralentissement.) 15:45 <+Complication> Bien que ce ne soit pas un gros ralentissement, et donc je suis tout à fait d’accord que les listes blanches sont bien aussi. :) 15:46 <+bar> peut-être qu’une solution de type hashcash pourrait être envisageable plus tard, si nécessaire 15:46 <jrandom> si nécessaire, mais je ne vois pas pourquoi ça le serait 15:46 <+bar> d’accord, pour l’instant, moi non plus 15:46 <+Complication> bar : du style "ne pas afficher à moins qu’ils aient pris la peine de faire du calcul" ? 15:47 <+bar> oui, quelque chose dans ce goût-là 15:47 <+Complication> Ça semble possible, même si probablement inutile. 15:47 <+bar> sans doute. 15:47 <jrandom> si un groupe de spammeurs inondait avec plein de nouveaux auteurs tout le temps, les gens pourraient toujours faire connaître de nouveaux auteurs en publiant leurs signets et références de blogs dans leur propre blog 15:47 <+Complication> Ou plutôt, espérons-le inutile. 15:48 <+Complication> Il pourrait être bon de voir si Syndie peut accueillir une telle fonctionnalité, si jamais le besoin se présentait. 15:49 <jrandom> ouais, il peut, avec des en-têtes dans l’article de blog ou dans la méta-info du blog 15:49 <jrandom> euh, metadata (maudit bt !) 15:51 <jrandom> ok, s’il n’y a rien d’autre sur 3) Syndie, passons à 4) ??? 15:51 <jrandom> quelqu’un a autre chose à aborder pour la réunion ? 15:51 <+legion> oui deux choses 15:52 <+legion> d’abord clunk 15:52 <jrandom> cool, oui clunk semble intéressant 15:52 <+legion> Comme je l’ai mentionné plus tôt aujourd’hui sur i2p-chat, j’ai travaillé pour le faire compiler avec cygwin et/ou mingw. 15:53 <+legion> Pour l’instant seul le client est cassé, le reste, y compris le serveur, compile et semble fonctionner 15:53 <jrandom> chouette 15:54 <tealc_> i2p pourrait s’avérer être un vrai sac de nœuds pour le programme de surveillance sans limites de George Bush. On se voit dans les camps de la mort, apportez les cartes hein 15:54 <+legion> J’ai essayé non seulement de trouver pourquoi le client est cassé, mais aussi de le corriger. Pour le moment je suis coincé. 15:56 <+legion> L’autre chose dont je voulais parler, c’est : pourrait-on inclure un tunnel par défaut vers mon serveur jabber dans la prochaine mise à jour ? Juste pour faciliter les choses à ceux qui veulent essayer jabber. 15:57 <tethra> 20:34:37 <jrandom> si un groupe de spammeurs inondait avec plein de nouveaux auteurs tout le temps, les gens pourraient toujours faire connaître de nouveaux auteurs en publiant leurs signets et références de blogs dans leur propre blog <--- peut-être que quelque chose dans le style de la manière de polecat de combiner la confiance pourrait jouer un rôle ici ? (c.-à-d. à la fois pour bloquer les spammeurs -et- promouvoir les auteurs populaires.) 15:57 <tethra> </$0.02> 15:58 <+polecat> Ce serait un exemple primitif de mon idée de réseau de confiance, avec une heuristique de transfert de confiance à 100 %, oui. 15:58 <jrandom> legion : hmm, ajouter une configuration désactivée est assez simple pour les nouveaux utilisateurs, mais ce qui me rend hésitant concerne le filtrage du protocole (et quelles infos chaque client fuit). quelle est ton expérience avec différents clients ? 15:59 <jrandom> ouais, il y a beaucoup de marge pour intégrer des métriques de confiance dans syndie 16:01 <+legion> Eh bien autant que je sache jeti ne fuit pas, à part son transfert de fichiers, qui est désactivé dans la configuration de mon serveur de toute façon. Il est possible que la prochaine version de jeti le corrige. À part ça je ne sais pas pour les autres clients. 16:02 <+legion> Je sais par contre que la discussion de groupe est solide, quels que soient les clients ; c’est juste le contact en dehors de la discussion de groupe avec certains clients qui pourrait fuiter, bien que je ne sois pas sûr. 16:03 <jrandom> hmm, la fuite n’est pas vraiment un booléen, c’est une question de /quelles informations/ les clients fuient, pas de savoir s’ils fuient des informations 16:04 <+legion> Exact, je faisais bien sûr référence à toute information critique comme des adresses IP, bien que de bons clients, si jamais ils fuient cette information, ne devraient la signaler que comme 127.0.0.1 ou localhost 16:06 <+legion> Donc je recommanderais d’utiliser uniquement des clients connus qui ne fuient pas, comme jeti. 16:07 <zzz> pourrais-tu ajouter une colonne "vérifié-ne-fuit-pas" à ton tableau des clients ? 16:07 <jrandom> ce serait utile si tu pouvais documenter ce que jeti fuit et ne fuit pas (dans l’esprit de ce que postman a préparé pour le proxy smtp et pop) 16:08 <+legion> Selon le développeur de jeti, il ne fuit rien qui compromettrait l’anonymat de quelqu’un. Ça, c’est certain sans aucun doute. J’ai aussi parcouru son code source et je n’ai rien trouvé qui me ferait penser le contraire. 16:09 <jrandom> que le développeur l’affirme peut être une chose, mais ce que le développeur comprend de l’anonymat est une autre question ;) 16:09 <+legion> Oui zzz je pourrais ajouter une telle colonne 16:09 <jrandom> Je ne doute pas que jeti se comporte correctement, mais nous devons savoir ce que cela signifie 16:10 <zzz> il semble que l’absence de fuite ne puisse être vérifiée que par traçage du protocole 16:10 <zzz> pas en regardant le code source ou en demandant au développeur 16:12 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:12 <+bar> juste un rappel de ne pas oublier jbigi amd64 16:13 <+bar> (mais je parie que c’est sur ta todo list) 16:13 <jrandom> ouais :) 16:13 <jrandom> (Windows amd64, c’est-à-dire, Linux amd64 fonctionne déjà) 16:13 <jrandom> mais, s’il n’y a rien d’autre... 16:14 * jrandom prend son élan 16:14 <+bar> oui, Windows amd64. 16:14 * jrandom *baf*s la réunion est close