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

13:06 <@jrandom> 0) salut 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) mises à jour mail.i2p 13:06 <@jrandom> 3) mises à jour i2p-bt 13:06 <legion> donc c'est lié aux serveurs IRC ? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) salut 13:06 <@jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> salut 13:07 <+postman> salut 13:07 <frosk> bonjour 13:07 <@jrandom> legion: non, lié à des bugs i2p, en cours de correction 13:07 <bla> salut 13:07 <legion> ok 13:07 <@jrandom> en parlant de bugs en cours de correction, passons à 1) 0.5.0.2 :) 13:07 <cervantes> 'lo 13:07 <cervantes> -- Déconnecté 13:08 <@jrandom> héhé 13:08 <ant> <mihi> salut tout le monde 13:08 <@jrandom> 0.5.0.2 est sortie, et même si votre connexion IRC peut laguer par moments, elle se rétablira ;) 13:08 <@jrandom> ouah salut mihi 13:09 <cervantes> hey mihi 13:09 <@jrandom> les notes d'état donnent une vue d'ensemble de la situation et des priorités les plus immédiates 13:10 <@jrandom> la chose inquiétante que j’essaie de traquer se voit sur http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> Pour ma part, je peux dire que 0.5.0.2 a déjà amélioré la fiabilité _énormément_ par rapport à 0.5.0.1 : les erreurs où les destinations ne pouvaient pas être contactées n’apparaissent presque plus 13:10 <@jrandom> ces nombres devraient être très très faibles, mais ils ne le sont pas, malheureusement 13:10 <@jrandom> mortel, bla 13:11 <@jrandom> oui, la 0.5.0.2 est clairement une amélioration, et tout le monde devrait mettre à jour au plus vite 13:11 <bla> 375,932.22 ces 10 dernières minutes ici.... 13:11 <@jrandom> en fait, la valeur en soi n’est pas vraiment le problème, c’est leur fréquence 13:11 <@jrandom> (événements par période) 13:12 <@jrandom> ces messages peuvent probablement être attribués aux routers 0.5, et en partie aux routers 0.5.0.1, d’où mon souhait que les gens mettent à jour au plus vite 13:12 <@jrandom> il se peut que ce soit autre chose, mais j’aimerais l’écarter 13:12 <bla> jrandom: j’en reçois environ 200 par heure ici 13:13 <@jrandom> bla: j’en ai 93 cette heure-ci, mais le pic est bien plus élevé (des milliers) 13:13 <@jrandom> de toute façon, cette statistique particulière est publiée dans le netdb 13:13 <bla> jrandom: Que dirais-tu d’exclure 0.5-0 du réseau au niveau logiciel lors de la sortie de 0.5.0.3? 13:14 <@jrandom> comme ça on peut tous regarder quelles valeurs ont les autres ;) 13:14 <@duck> 309,854.24 pic 5,473,314.59 13:15 <@duck> je colle la mauvaise, hein 13:15 <@jrandom> bla: clairement. J’ai ajouté du code dans la révision 0.5.0.2 pour une certaine compatibilité ascendante que 0.5.0.1 et 0.5 n’ont pas 13:16 <@jrandom> duck: dur d’avoir un nombre non entier d’événements ;) 13:16 <bla> jrandom: Bien. Au moins ça te permet de tester ton hypothèse que les messages invalides sont dus à 0.5-0 de manière contrôlée 13:16 <@jrandom> bla: oui, même si ce serait bien que les gens mettent à jour avant ;) 13:17 <@jrandom> (donc pour ceux qui lisent à la maison : http://www.i2p.net/download est votre ami ;) 13:17 <maestro^> jr: ces nombres pour les écarts de router.invalidMessageTime en ms ? 13:17 <@jrandom> maestro^: oui 13:18 <@jrandom> (aka des valeurs vraiment follement décalées) 13:18 <legion> Voici un petit rapport réseau [version|Nombre de nœuds][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> oui, vous avez été super pour les mises à jour 13:18 <legion> Donc il y a encore quelques personnes sur 0.5 et beaucoup sur 0.5.0.1 13:18 <maestro^> donc une idée d’où ils peuvent laguer ? 13:18 <bla> jrandom: Freenet a un indicateur dans chaque version qui spécifie la version minimale de nœud avec laquelle elle communiquera. Le nouveau code de compatibilité ascendante, c’est quelque chose comme ça ? 13:19 <@jrandom> maestro^: beaucoup, beaucoup d’idées sur pourquoi les utilisateurs 0.5 et 0.5.0.1 laguent. 13:19 <@jrandom> bla: similaire 13:19 <maestro^> ou est-ce une dérive d’horloge sur les nœuds ? 13:20 <@jrandom> maestro^: décalage d’horloge, quelques bugs de sérialisation, le bug à 100% CPU 13:20 <@jrandom> ok, c’est généralement mon focus en ce moment, essayer de remonter la fiabilité des messages 13:21 <@jrandom> quelqu’un a des questions/commentaires/inquiétudes sur 0.5.0.2 ? 13:21 <ant> * mihi a un router 0.4.2.5 ici sur le disque dur, pas démarré depuis le 22 déc... mais il pense qu’il ferait mieux de le supprimer... 13:21 <@jrandom> héh 13:21 <@jrandom> oui, ça ne parlera pas à beaucoup de routers ;) 13:21 * postman a une copie de sauvegarde de sa dernière installation 0.4 :) 13:21 <ant> <mihi> pour moi la question serait mise à jour ou suppression. 13:22 <@jrandom> supprimer 13:22 <@jrandom> (sauvegarder toutes les clés de destination) 13:22 <@jrandom> il n’y a plus de procédure de mise à niveau depuis les versions antérieures à 0.5 13:22 <legion> Peut-être publier une autre mise à jour, disons 0.5.0.2-1, qui n’autorise que les connexions depuis 0.5.0.2 ou plus récent, ce serait bien ? 13:22 <@jrandom> legion: ça segmenterait le réseau 13:22 <@jrandom> les gens devraient juste mettre à jour. 13:23 <@jrandom> (et nous devrions contourner ceux qui ne le font pas) 13:24 <legion> oui jusqu’à ce que les personnes avec des nœuds obsolètes mettent à jour ;) 13:24 <@jrandom> segmenter le réseau nous nuit à tous, pas seulement à eux 13:25 <legion> Peut-être qu’une notification de mise à jour dans la console du router ou quelque chose qui leur dise qu’ils utilisent des versions obsolètes ? 13:25 <@jrandom> oui, ce serait clairement chouette 13:25 <@jrandom> avec un peu de chance, ça pourra être relié aussi au mécanisme de mise à jour 13:26 <legion> ouais, je sais, la segmentation c’est mauvais... 13:26 <@jrandom> smeghead travaille sur certains composants clés de ça, mais je ne sais pas si cela inclut la notification / le téléchargement 13:26 <@jrandom> (donc si quelqu’un veut aider à travailler là-dessus, contactez-nous !) 13:27 <@jrandom> ok, on passe à 2) mises à jour de mail.i2p 13:27 <@jrandom> postman: ping 13:27 <+postman> oui 13:27 <bla> jrandom: smeghead faisait des trucs liés à la signature si je me souviens bien (comme ça quand tu reçois un avis de mise à jour, tu sais au moins que c’est réel, et pas du phishing/spyware/truc pourri) 13:28 * postman prend le micro 13:28 <legion> hmm, peut-être s’il y avait une fonction de mise à jour automatique intégrée, où les mises à jour seraient téléchargées via i2p et les nœuds téléchargeraient simplement la mise à jour, puis feraient un redémarrage en douceur. 13:28 <@jrandom> oui, bla 13:28 <ant> <Gatak> Oh, au fait. I2P fonctionnerait-il derrière un NAT même si on ne peut pas ouvrir de port ? 13:28 <@jrandom> Gatak: pas encore. certaines personnes pourront à 0.6, d’autres à 2.0 13:29 <@jrandom> legion: patches bienvenus 13:29 <ant> <Gatak> 2.0 mince, c’est loin dans le futur =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> erm, je commence maintenant ? 13:29 <aum> bonjour à tous 13:30 <@jrandom> le micro est à toi, postman (désolé ;) 13:30 <@jrandom> 'lo aum, tu as réussi à venir à la réunion 13:30 <@jrandom> (mince ! /me shuts up again) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> d’abord, je voulais dire qu’on a déjà atteint 300 comptes enregistrés sur postman.i2p 13:30 <@jrandom> w00t 13:30 <+postman> le nombre de mails depuis/vers Internet augmente régulièrement et prouve encore une fois qu’il faut aller plus loin 13:31 <cervantes> *squeeeel* 13:31 <+postman> après avoir parlé avec jr il y a quelques semaines, nous avons convenu de publier v2mail en même temps qu’I2P 1.0 13:31 <+postman> l’état récent est : le proxy SMTP en Java conçu pour tourner sur chaque nœud est terminé 13:31 <@jrandom> super ! 13:32 <+postman> le proxy POP3 en Java est à 80%, il ne manque que le moteur maildir 13:32 <+postman> il y aura un gestionnaire web qui nécessite encore pas mal d’ajustements (15% fait) 13:32 <+postman> la communication inter-nœuds est à 40% - nous avons testé des échanges de datarecord via HTTP/XML 13:33 <+postman> ça semble marcher plutôt bien et même vite 13:33 <+postman> même si un nœud relais tombe en panne/est éteint quelques jours, il sera synchronisé en quelques minutes après être revenu en ligne 13:33 <@jrandom> mortel 13:33 <+postman> je pense qu’on est plutôt dans les temps 13:34 <+postman> une chose est notable 13:34 <bla> postman: Beau boulot mec ! Une question : Beaucoup de nœuds ne peuvent pas recevoir ni envoyer de données sur le port 25 (pas directement en tout cas). Les propriétaires de nœuds pourront-ils le spécifier (ou bien ce sera détecté automatiquement) ? 13:34 <cervantes> cool 13:34 <+postman> bla: plus tard 13:34 <+postman> dans v2mail il y aura une webapp locale 13:34 <+postman> avec ça vous pourrez gérer vos proxys locaux ET demander un « relayaccount » (compte de relais) 13:35 <+postman> ce relayaccount (compte de relais) sera ensuite utilisé pour associer votre adresse/domaine aux relais 13:35 <+postman> les relais synchroniseront l’information automatiquement 13:35 <@jrandom> cool 13:35 <+postman> même des fonctionnalités comme le carnet d’adresses / les clés publiques et cie fonctionneront avec l’interface LOCALE 13:36 <+postman> l’idée est d’avoir un gestionnaire centralisé où vous pouvez faire tout ce qui concerne le courrier 13:36 <+postman> les données pertinentes sont transférées vers UN des relais puis synchronisées entre les relais 13:36 <+postman> et ce gestionnaire web tournera sur votre propre nœud 13:37 <+postman> quand votre nœud est en ligne, les relais livreront les mails en file d’attente pour votre destination/domaine/adresse 13:37 <+postman> ils seront livrés à votre proxy SMTP local 13:37 <+postman> vous pouvez même déclencher tout ça avec ETRN :) 13:37 <aum> re 13:37 <aum> j’aimerais soulever un point de discussion pendant cette réunion, si c’est ok 13:37 <+postman> voilà pour le futur, les amis :) 13:37 <+postman> . 13:38 <@jrandom> ça déchire, postman 13:38 * postman rend le micro 13:38 <@jrandom> aum: super, on aura du temps au point 4) 13:38 <+postman> ouais, je suis aux anges :) 13:38 <@jrandom> postman: donc pour l’utilisateur lambda, le proxy SMTP aura le maildir local, et le proxy POP3 lira/etc., c’est bien ça ? 13:39 <+postman> oui, le proxy SMTP a un MDA 13:39 <+postman> et livrera le courrier dans des maildirs locaux 13:39 <+postman> on peut même créer plusieurs comptes/utilisateurs en local 13:39 <cervantes> postman: les relais garderont-ils la trace de vos quotas, etc., et propageront-ils ces infos entre eux ? 13:39 <+postman> et les associera aux comptes de votre domaine 13:39 <+postman> cervantes: oui, ils le feront 13:39 <septu_ssh> désolé, puis-je demander à postman les mécanismes de paiement/anti-spam dans le nouveau modèle ? 13:40 <+postman> septu_ssh: as-tu lu des documents sur la page web ? 13:40 <+postman> cervantes: ce n’est pas du temps réel parfait 13:40 <+postman> cervantes: mais je suis ok avec une mise à jour des quotas toutes quelques minutes 13:40 <septu_ssh> postman: dans la file d’attente de lecture :/ 13:40 <septu_ssh> mais si c’est documenté, alors ça va 13:40 <cervantes> postman: oui je m’en doutais 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: ce n’est pas dramatique en fait - le quota est une limite raisonnable 13:41 <cervantes> postman: même si quelqu’un peut envoyer à nrelays * quota de destinataires, ce n’est pas une mauvaise chose 13:41 * septu_ssh is bungle 13:41 <+postman> cervantes: yep 13:42 <+postman> le but est juste d’empêcher quiconque d’abuser vraiment du service 13:42 <+postman> dans les tests, j’avais 3 relais, ça a été vraiment rapide 13:42 <@jrandom> postman: j’ai oublié, est-ce que cela supportera que le relais SMTP local parle directement au relais SMTP de quelqu’un d’autre, plutôt que de rebondir via vos nœuds ? 13:42 <+postman> cervantes: en 10 secondes ils étaient synchronisés :) 13:43 <@jrandom> (ou peut-être que c’est juste pour plus tard) 13:43 <+postman> jrandom: les relais mail i2p seront opérés par plusieurs personnes et sont les destinations préférées pour router le courrier 13:43 <cervantes> postman: tu pourrais introduire un délai exponentiel dans la file d’envoi 13:43 <cervantes> si ça devient un problème 13:43 <+postman> jrandom: donc envoyer vers d’autres destinations pourrait être utile dans certaines circonstances 13:44 <@jrandom> oui, mais dangereux dans d’autres 13:44 <cervantes> donc plus tu envoies de mails, plus le temps de mise en file augmente... ça devrait laisser le temps aux relais de rattraper 13:44 <+postman> jrandom: mais si le propriétaire d’un nœud divulgue sa destination IMIO il pourrait être spammé sans contrôle :) 13:44 <@jrandom> exactement 13:44 <@jrandom> d’un autre côté, c’est pareil si les relais mail i2p sont hostiles 13:45 <+postman> jrandom: en effet, c’est une construction de type WOT 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: je ne peux pas empêcher un opérateur de relais d’attribuer un quota de 0 pour ton adresse 13:45 <@jrandom> 'k super. oui, pas besoin de s’en soucier pour l’instant 13:45 <+postman> :) 13:46 <+postman> ok 13:46 <+postman> . 13:46 <@jrandom> ok cool, merci pour la mise à jour. des trucs vraiment excitants 13:46 <@jrandom> ok, on enchaîne sur 3) i2p-bt mises à jour 13:46 <@jrandom> duck: ping 13:46 <@duck> salut 13:47 <@duck> Hier, BitTorrent 4.0.0 est sorti 13:47 <ant> <dm> ça sonne allemand 13:47 <@duck> qu’on attendait plus ou moins avant de démarrer 0.2 13:47 <@duck> j’ai écrit une liste de tâches / todo : http://pastebin.ca/raw/7037 13:47 <@duck> (désolé, mon www est actuellement en panne) 13:48 <@jrandom> cool 13:48 <legion> quel genre de calendrier pour 0.2 ? 13:48 <@duck> l’objectif était 4 semaines 13:49 <legion> cool 13:49 <@duck> comme vous pouvez le voir, RawServer (la partie qui communique avec i2p) est la plus grosse tâche 13:50 <@duck> . 13:50 <@duck> petit sondage rapide : 13:50 <legion> oui, je le sais bien :) 13:50 <@duck> qui prévoit de créer un fork i2p-bt ? 13:50 <@jrandom> cool, y a-t-il quelque chose que les gens puissent faire pour aider ? 13:50 <@jrandom> héhé 13:51 <ant> <dm> moi 13:51 * jrandom attrape une cuillère 13:51 <ant> <dm> suis prêt à aider 13:51 <legion> moi 13:51 <ant> <dm> je suis gay 13:51 <legion> je travaille sur un fork 13:52 <@duck> bien, alors je sais qui ne pas prendre au sérieux. 13:52 <@duck> franchement, je trouve ça idiot ; mettre les ressources en commun vous mènerait bien plus loin 13:53 <@jrandom> ou peut-être que s’il y a de meilleures façons de faire, vous pouvez convaincre duck de travailler de cette façon ? 13:53 <named> Je vais écrire un fork en qbasic, s’il vous plaît prenez-moi au sérieux. 13:53 <@duck> j’essaierai de rendre le processus plus ouvert, pour que les autres puissent voir ce qui est prévu, etc. 13:53 <ant> <dm> ton ouverture ne nous fait pas changer d’avis. FORK ! FORK ! FORK ! FORK ! 13:53 <@duck> si vous avez d’autres suggestions 13:54 <ant> * dm soulève legion sur ses épaules. 13:54 <legion> hmm, c’est peut-être vrai, mais avec ce que je fais je doute que tu veuilles que je pollue le processus de développement principal d’i2p-bt ;) 13:54 <ant> <dm> FORK ! FORK ! FORK ! FORK ! 13:54 <@jrandom> legion: que fais-tu que duck ne voudrait pas supporter ? 13:55 <@duck> legion: félicitations, si tu googles « i2p bittorrent », une annonce « Windows I2P Bittorrent Version 1.0 » est en #1 13:55 <@jrandom> bon sang 13:56 <bla> jrandom: Oui ? 13:56 <+postman> jrandom: oui, ils vont bientôt exploser ce réseau :) 13:56 <bla> ;) 13:56 <named> 1.0? Zut, j’utilise 0.1.8 ! 13:56 <Ragnarok> oh 13:57 <legion> omfg, vraiment ?! Je n’arrive pas à y croire... c’est dingue. 13:57 <@duck> bref, je ne pense pas qu’il y ait grand-chose de nouveau à dire là-dessus 13:57 <legion> ma version 1.0 est basée sur 0.1.8 ; si vous utilisez 0.1.8, vous êtes bien. 13:58 <@jrandom> (et la 1.0 est un .exe que personne n’a audité, YMMV) 13:58 <legion> je l’ai mal nommée et numérotée, désolé, encore désolé pour ça. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> n’importe quel jour de la semaine 13:59 <@duck> en lien indirect : 13:59 <@jrandom> ok, autre chose sur 3) i2p-bt, ou on passe à 4) ??? 13:59 <+postman> legion: quand y aura-t-il du code source téléchargeable ? 13:59 <frosk> "I2P-BT 0.1.8 fonctionne plutôt bien et est stable jusqu’ici. Personnellement je ne vois aucune raison de passer à I2P-BT 1.0" (vu sur le forum) 13:59 * jrandom soupire 13:59 <@duck> le mois dernier, Bram Cohen a donné une conférence sur BitTorrent dans une université 14:00 <@duck> assez intéressant : http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (retours d’expérience sur les gros programmes P2P, plus quelques détails de BitTorrent expliqués) 14:00 <@duck> . 14:01 <@jrandom> word 14:01 <@duck> postman: legion a publié du code source 14:01 <ant> <dm> c’est l’inventeur de BT ? 14:01 <@duck> mais d’après smeghead ce n’est pas le même que le .exe 14:01 <@jrandom> dm: oui 14:01 <legion> Il y a un code source développeur que vous pouvez télécharger depuis http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> ok, je vais regarder 14:02 <ant> <dm> l’exe est-il une compilation directe de ce source ? 14:03 <legion> mais en fait le code 1.0 est juste le 0.1.8 avec un patch de smeghead, compilé et bien empaqueté. 14:04 * cervantes passe à 4)??? et attend que tout le monde rattrape 14:04 <ant> <dm> la question reste sans réponse 14:04 <ant> <dm> Legion, avez-vous, oui ou non, donné l’ordre Code rouge ??? 14:04 <@jrandom> *tousse* 14:04 <legion> On devrait peut-être revenir au sujet, ma discussion sur le client BT a été déplacée vers #itorrent 14:05 <@jrandom> ok, 4) ??? 14:05 <@jrandom> autre chose que les gens veulent aborder ? 14:05 <@jrandom> aum: tu avais quelque chose ? 14:06 <ant> <dm> stasher est de retour ? 14:06 <legion> je vois juste un comportement bizarre avec 0.5.0.2 pendant des périodes de fort trafic... 14:06 <aum> oui 14:06 <aum> j’aimerais soulever la question de la création/gestion automatisée de tunnel 14:07 <ant> <dm> vas-y 14:07 <+detonate> il y a une exception de pointeur nul dans le truc de la zone de notification sous Windows, je viens de le remarquer 14:07 <aum> c’est 1337 que la console web permette maintenant aux humains de créer/supprimer/gérer manuellement des tunnels 14:07 <@jrandom> detonate: tu pourrais la mettre sur le bugzilla ? 14:07 <aum> mais je crois aussi fermement qu’il devrait toujours y avoir un moyen fiable et pratique pour les programmes de gérer aussi les tunnels 14:08 <@jrandom> aum: personne n’est en désaccord. on en a besoin, et on l’aura. juste pas encore. 14:08 <ant> <dm> tu ne peux pas faire ça via SAM ? 14:08 <aum> j’ai remarqué à mon retour récent sur i2p que la bibliothèque pysam ne fonctionne plus 14:08 <septu_ssh> j’ai aussi une question rapide après aum 14:08 <aum> ce qui a été décevant 14:08 <@jrandom> le protocole SAM fonctionne, pysam non 14:08 <Ragnarok> ça a déjà marché ? 14:09 <aum> correct 14:09 <aum> pysam marchait du tonnerre 14:09 <legion> Pendant ces périodes il y a plus de 1000 tunnels auxquels mon nœud participe et plusieurs secondes de lag et de délai. 14:09 <@jrandom> legion: oui, le nombre de tunnels est dû aux anciennes builds 14:09 <cervantes> ah mymodesty 14:09 <cervantes> eerm pymodesty 14:09 <aum> je suis en train d’écrire un module 'i2ptunnel.py', qui définit des classes permettant une gestion facile des tunnels 14:10 <legion> donc si on ne se connectait pas aux anciennes builds, le réseau serait beaucoup plus fluide ? 14:10 <@jrandom> 'k, je ne sais pas si c’est la bonne solution à long terme, mais si ça comble l’écart pour toi maintenant, cool 14:10 <@jrandom> legion: ces tunnels ne sont pas le problème 14:11 <aum> eh bien, les interfaces de classes peuvent rester même si le mécanisme sous-jacent change 14:11 <@jrandom> 'k 14:11 <legion> ah bon ? 14:12 <legion> Quand il y a peu de tunnels, il y a très peu de lag et de délai... 14:12 <cervantes> legion: désolé, aum soulève juste quelques questions, si tu peux patienter une minute 14:12 <legion> ça me semble juste étrange. 14:13 <legion> ok 14:13 <@jrandom> il faut tenir compte de ce qui a marché par le passé - la config web fonctionne et est maintenue parce que tout le monde l’utilise. peut-être que le mieux serait de faire fonctionner l’appli sur laquelle tu travailles avec une création de tunnel manuelle d’abord, ce serait plus efficace ? 14:13 <@jrandom> histoire qu’il y ait toujours quelque chose qui utilise i2ptunnel.py, pour le mettre à l’épreuve 14:13 <aum> on dirait qu’on est en impasse 14:13 <+detonate> jrandom: bien sûr 14:14 <ant> <dm> passons à la suite alors 14:14 <aum> je ne veux pas investir du temps à développer mon appli tant que je n’ai pas une API de gestion de tunnel fiable 14:14 <septu_ssh> \o. - point à soulever 14:14 <cervantes> réalistement, je n’imagine pas que l’interface de tunnel sera refondue dans les prochains mois cependant... 14:14 <@jrandom> mais tu vois bien qu’on peut en ajouter une facilement 14:14 <cervantes> donc une solution temporaire est viable 14:15 <named_> L’interface web ne pourrait-elle pas avoir une sorte d’API que le programme d’aum manipule ? 14:15 <@jrandom> named_: oui 14:16 <@jrandom> il est trivial d’ajouter quelque chose pour permettre un contrôle sûr via des URLs, mais ça n’a de sens que s’il y a quelque chose qui en a besoin 14:16 <@jrandom> sinon ça va juste pourrir 14:16 <aum> named_: ce serait bien, et ça pourrait marcher s’il y avait un mot de passe en dur dans la config que les programmes clients doivent POSTer avec les champs de contrôle du tunnel 14:16 <cervantes> personnellement j’aimerais voir tout le système de tunnel complètement refondu ; si tu inclus une interface de gestion de tunnel dès le départ alors tu n’auras pas à te soucier de l’effort supplémentaire pour maintenir une interface séparée 14:17 <@jrandom> oui, les proxys ont besoin de pas mal de travail, que j’ai évité autant que possible :) 14:17 <aum> SAM est bon pour certaines situations, mauvais pour d’autres 14:17 <cervantes> mais ça, c’est un peu plus tard... 14:17 <fedo> ( 14:18 <@jrandom> aum: mais en attendant, tu ne pourrais pas simplement utiliser une des trois méthodes disponibles ? 14:18 <cervantes> c.-à-d. si l’interface web elle-même utilise l’API, il n’y a pas de surcoût de maintenance 14:18 <@jrandom> oui. l’interface web utilise le TunnelControllerGroup 14:19 <aum> l’utilisation de SAM devient difficile quand on veut utiliser des libs existantes qui dépendent fortement des sockets TCP standard 14:19 <aum> jrandom: la CLI I2PTunnel ne fonctionne pas pour ouvrir des tunnels serveur, donc je suis en train d’écrire du code pour utiliser TunnelControllerGroup 14:19 <@jrandom> aum: les libs existantes doivent être auditées avec soin. par exemple, l’outil gzip lui-même expose des données sensibles 14:19 <aum> je code pendant qu’on parle 14:21 <@jrandom> je suis certain que la CLI fonctionne pour les tunnels serveur, mais utiliser le TunnelControllerGroup est préférable si tu en as besoin comme ça 14:21 <@jrandom> ok, quelqu’un d’autre a quelque chose à évoquer ? 14:22 <septu_ssh> Ma question concerne une version distribuée de hosts.txt, une table DHT est actuellement utilisée pour routerInfo, ne pourrait-on pas l’étendre à une version distribuée du DNS ? La DHT du DNS pourrait contenir des correspondances de www.bla.i2p vers le SHA de l’eepsite, et les entrées seraient signées par un « I2P registrar »... des commentaires ? des réfutations ? 14:22 <mancom> une question concernant la roadmap: 0.6 est-elle toujours prévue pour avril ? 14:22 <@jrandom> septu_ssh: des données non routantes dans le netDb, par-dessus mon cadavre ;) 14:23 <septu_ssh> jrandom: pas la même base 14:23 <septu_ssh> une base distribuée différente 14:23 <aum> jrandom: as-tu vu mon rapport de bug ? la commande CLI 'server' /ne fonctionne pas/ 14:23 <maestro^> septu_ssh: il n’y a pas de registrar i2p 14:23 <@jrandom> septu_ssh: il y a beaucoup d’aspects dangereux dans la nomination, avec quelques compromis clés. as-tu vu la discussion sur la dénomination sur ugha.i2p ? 14:24 <@jrandom> septu_ssh: ah, une DHT au-dessus d’I2P pourrait certainement être utilisée pour distribuer des entrées, mais ces noms ne seraient pas sécurisés s’ils étaient traités comme des entrées globales 14:26 <@jrandom> aum: je l’utilisais quotidiennement jusqu’à il y a quelques semaines, as-tu vu ma réponse ? 14:26 <@jrandom> maestro^: c’est le plan 14:26 <@jrandom> euh, mancom: 14:26 <cervantes> aum: j’ai une réponse à ce mail i2plist de jr, ne t’est-elle pas parvenue, ou le problème persiste-t-il ? 14:26 <septu_ssh> la seule raison pour laquelle je suggère un « registrar » est que sinon des collisions peuvent avoir lieu 14:26 <@jrandom> septu_ssh: accepte les collisions :) 14:26 <@jrandom> un système de noms globalement unique, lisible par l’humain, distribué et sécurisé n’existe pas 14:27 <septu_ssh> ça peut aussi arriver dans host.txt s’il est modifié manuellement, mais le problème reste le même 14:27 <@jrandom> abandonne le premier paramètre, et c’est parfait 14:27 <aum> jrandom: j’ai bien vu ta réponse - et j’ai /bien/ streaming.jar dans mon classpath 14:27 <septu_ssh> postman gère un nœud central pour le mail, donc il y a un certain élément de confiance dans le réseau, sûrement que quelqu’un ferait confiance à un registrar pour gérer l’espace de noms ? 14:27 <@jrandom> ok cool, et ça revient toujours avec ce stacktrace, aum ? 14:28 <aum> oui 14:28 <@jrandom> septu_ssh: postman n’agit comme élément central que pour les outproxies et inproxies de postman 14:28 * Ragnarok doit vraiment se mettre à écrire cette doc de carnet d’adresses... 14:28 <aum> c’est quand j’exécute manuellement la CLI, que je fais un genkeys, puis un 'server' en utilisant le privkeyfile généré par genkeys 14:28 <@jrandom> septu_ssh: personne ne fera confiance à quelqu’un pour gérer un espace de noms. censure == exercer une pression sur ce registrar. 14:28 <maestro^> chacun est en fait son propre registrar 14:29 <maestro^> tu fais confiance à tes amis et ils te font confiance 14:29 <aum> oh merde, j’ai pris un ancien classpath 14:29 * aum reteste 14:30 <ant> <dm> ok, je serai le registrar. 14:31 <ant> <dm> je serai aussi impartial que possible... d’accord ? 14:31 <septu_ssh> hmmm, ok, retour à la planche à dessin proverbiale alors... 14:31 <@jrandom> septu_ssh: un bon endroit à consulter est http://zooko.com/distnames.html :) 14:32 <@jrandom> tout le monde le veut, mais ce qu’ils veulent n’est tout simplement pas sécurisé. nous avons une solution qui l’est, mais nous abandonnons l’unicité globale 14:33 <septu_ssh> hmmm, ok 14:33 <@jrandom> ok, quelqu’un d’autre a autre chose à apporter pour la réunion ? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - ok, la CLI 'server' fonctionne maintenant, mais je n’ai jamais obtenu de 'numéro de job' pour le tunnel 14:34 <@jrandom> hmm oui, ça tourne indéfiniment 14:34 <aum> ah, je dois faire 'list' pour obtenir le numéro de job 14:36 <@jrandom> ok cool, s’il n’y a rien d’autre... 14:36 * jrandom conclut 14:36 * jrandom *baf* clôt la réunion