Réunion des développeurs I2P - 18 novembre 2003

[22:02] <jrand0m> agenda : [22:02] <jrand0m> 0) bienvenue [22:02] <jrand0m> 1) statut du dev i2p [22:02] <jrand0m> - 0.2.1.1 est sortie (mise à jour et test des pairs et des tunnels, améliorations de réglage, limitation des tunnels, une défense DoS) [22:02] <jrand0m> - n'utilisez pas la limitation de bw (il reste encore un peu de débogage) [22:02] <jrand0m> - gardez vos horloges globalement correctes (marge d'environ 30 minutes) [utilisée pour les expirations de lease et les garlics (garlic encryption)] [22:02] <jrand0m> 2) kademlia, 0.3, et idn [22:02] <jrand0m> 3) révision de la feuille de route (0.2.3 --> 0.4, 0.2.2 --> 0.3.1) ? [22:02] <jrand0m> 4) état des applis [ppp2p, i2ptunnel, im, ns, squid] [22:02] <duck> 5) pourquoi jrand0m boit-il de la bière locale bon marché ? [22:02] <jrand0m> 5) commentaires / questions / etc. [22:02] <jrand0m> héhé [22:02] <jrand0m> donc oui, en gros ça rentre dans le point 5 :) [22:02] <mihi_> double 5 ;) [22:03] <mihi_> oups... [22:03] <jrand0m> 0) bienvenue [22:03] * mihi_ n'a pas regardé la colonne de gauche [22:03] <jrand0m> salut. 65e réunion je suppose. [22:03] <jrand0m> hehe [22:03] <jrand0m> 1) ces trucs de code [22:04] <jrand0m> 0.2.1.1 est sortie hier soir [22:04] <jrand0m> plein de bonnes choses dedans. [22:04] * mihi le teste atm. [22:04] <jrand0m> les tunnels sont testés et échouent rapidement, en pénalisant tous les participants afin qu'ils aient peu de chances d'entrer dans la reconstruction [22:05] <jrand0m> les messages dans i2ptunnel sont aussi limités à une taille max de 64k (les messages plus gros provoquaient des problèmes) [22:05] <jrand0m> il y a quelques bogues en cours de correction dans le code de limitation de bw, donc assurez-vous que vos limites de bw dans router.config sont des valeurs négatives [22:06] <jrand0m> (i2p n'a de toute façon pas assez de trafic pour causer une vraie charge pour le moment) [22:06] <jrand0m> (mais la limitation de bw sera testée unitairement et corrigée pour 0.2.1.2) [22:07] <jrand0m> aussi, essayez de garder vos horloges proches de l'heure correcte. c'est chiant qu'on en ait besoin, mais pour l'instant oui. [22:07] <jrand0m> on pourra peut-être trouver un moyen de ne pas exiger des horloges semi-synchronisées, mais c'est délicat. [22:07] <jrand0m> 2) trucs fun [22:08] <jrand0m> beaucoup des bogues corrigés dans les dernières versions sont liés au bricolage pourri d'un BroadcastNetworkDB. [22:08] <jrand0m> puisqu'il est prévu d'être remplacé en 0.3, autant mentionner par quoi il va l'être [22:09] <jrand0m> kademlia est une DHT (structured distributed hash table) qui nous permet d'insérer et de récupérer en temps O(log(N)) ou moins, garanti [22:09] <jrand0m> [avec une petite réserve encore en cours d'élaboration] [22:10] <jrand0m> ce code kademlia doit être écrit pour 0.3 afin qu'on puisse insérer et récupérer des structures RouterInfo et LeaseSet. [22:10] <jrand0m> cependant, les choses seraient plus simples si c'était implémenté séparément - et donc testable séparément. [22:10] <jrand0m> (tests unitaires == bien) [22:11] <jrand0m> alors, quelle est une façon simple de tester unitairement une dht ? écrire dessus un simple service de stockage/recherche de fichiers. [22:11] <dm> insert fetch ? on parle de contenu ? [22:11] <jrand0m> voici idn : (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN [22:11] <Ophite1> dm : Non, seulement des structures routerinfo et leaseset. [22:12] <jrand0m> dm> la networkDatabase d'i2p contient actuellement seulement deux structures spécialisées, comme l'a dit ophite [22:12] <dm> ok, merci. [22:12] <Ophite1> peut ou pas être utile pour amorcer d'autres protocoles aussi, mais ce n'est pas anonyme en soi. (?) [22:12] *** grimps (~grimp@anon.iip) a rejoint le canal #iip-dev [22:12] <tusko> une question : quel protocole est utilisé maintenant pour networkDatabase ? [22:13] <jrand0m> désolé, téléphone. [22:13] *** Déconnexion: godmode0 (Ping timeout) [22:13] <jrand0m> exact, kademlia n'est pas anonyme, mais pas explicitement non anonyme non plus [22:13] <Ophite1> une kademlia modifiée passera à l'échelle. le hasard non. [22:13] <jrand0m> tusko> actuellement on fait un broadcast inondé [22:13] <duck> et si kademlia se fragmentait ? [22:13] <dm> pas de portables autorisés à la réunion. [22:13] <duck> <insérer commentaires de zooko> [22:13] <Ophite1> flooded broadcast alias méthode gnutella ne passera certainement pas ;) [22:13] <jrand0m> Ophite1> oui, kademlia n'utilise pas le hasard :) [22:13] <duck> Ophite1 : marche mieux comme routage freenet :) [22:14] <jrand0m> duck> exactement (<jrand0m> [avec une petite réserve encore en cours d'élaboration] ) [22:14] <Ophite1> duck : je m'en tiens là... ;) [22:14] *** Déconnexion: mihi (Ping timeout) [22:14] <tusko> kademlia est une sorte d'hypercube ? [22:14] <Ophite1> non, un cercle. [22:14] *** Déconnexion: mihi_ (Ping timeout) [22:14] <jrand0m> et/ou un arbre XOR :) [22:15] <Ophite1> scissions/fusions... on rebat l'arbre ? peut-on jeter un œil à l'overnet-like d'emule pour ça ? :) [22:15] <jrand0m> c'est un protocole assez simple, mais on peut clairement regarder autour. [22:16] <jrand0m> icepick a implémenté kademlia en Python aussi, pour ent (sous le nom kashmir) [22:16] *** mihi (~mihi@anon.iip) a rejoint le canal #iip-dev [22:16] <Ophite1> considérer aussi des nœuds malveillants fragmentant délibérément l'arbre. [22:16] <jrand0m> absolument. mais c'est assez résistant aux attaques [22:16] <Ophite1> un espace de clés 256 bits y résiste mieux. [22:17] <Ophite1> et il faudrait créer beaucoup de structures RouterIdentity = difficile. [22:17] <tusko> j'ai trouvé intéressants les papiers de gravepine : (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/ [22:17] <jrand0m> c'est aussi pourquoi je veux d'abord l'implémenter comme une application, plutôt que d'arracher le cœur d'i2p - pour qu'on règle tous les détails sales avant [22:17] <Ophite1> donc je suis content de la section 3 du draft 0.9. [22:17] *** Déconnexion: nickthief54450 (Excess Flood) [22:18] *** nickthief54450 (~chatzilla@anon.iip) a rejoint le canal #iip-dev [22:18] <tusko> regarde (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php [22:18] <Ophite1> cependant je pourrais signaler que si le message 0, DatabasePing, est implémenté, vous voudrez peut-être y inclure un hashcash. [22:18] <jrand0m> intéressant tusko, je pense que leur modèle économique nécessitera une révision, comme leurs défenses sybyl [22:19] <Ophite1> (vous le faites peut-être déjà ; pas lu cette partie) [22:19] <jrand0m> absolument Ophite1. Je pensais justement mettre des certifs hashcash dans tous les messages (DatabaseLookup inclus) [22:20] <Ophite1> bonne idée. mais attention aux performances et au réglage vs défense DoS là, et vous voudrez peut-être faire tourner le calcul du hashcash dans un thread séparé, de priorité inférieure ? [22:21] <jrand0m> eh bien, la vérification du hashcash devrait être quasi instantanée [22:21] <jrand0m> et la génération du hashcash ne devrait pas pouvoir être précompilée [22:21] <jrand0m> euh, précalculée [22:21] <dm> Ophite1 doit être un avatar créé par jrand0m pour qu'il puisse enfin parler d'I2P avec quelqu'un qui comprend WTF il raconte. [22:22] <jrand0m> lol [22:22] * dm n'est pas dupe. [22:22] *** godmode0 (~enter@anon.iip) a rejoint le canal #iip-dev [22:22] <Ophite1> une façon d'empêcher ça est d'utiliser des dérivés de clés de session comme partie du hashcash.. [22:22] <jrand0m> oui. et/ou mettre un nonce et la date [22:22] <Ophite1> la date entraîne ces embêtants problèmes de synchronisation. ça peut être un vrai souci. [22:22] <Ophite1> sauf si vous avez envie de réécrire NTP ;-) [22:22] *** Déconnexion: mihi (Ping timeout) [22:23] <jrand0m> héhé [22:23] <jrand0m> on a déjà un peu croisé ça [22:23] <jrand0m> (d'où la marge de 30 minutes) [22:23] <jrand0m> un hachage de session peut être viable. bonne idée. [22:24] <Ophite1> et non, je ne suis pas le clone de jrand0m ;) [22:24] <jrand0m> ok, donc pour idn, je vais probablement seulement implémenter ce qui est sur cette page wiki I2PIDN [22:25] *** Déconnexion: dm (Ping timeout) [22:25] <jrand0m> ce qui serait bien, ce serait que quelqu'un prenne ça et fonce - faire une vraie interface utilisateur, de meilleures applis de get/store, FEC/ECC/etc. [22:25] <jrand0m> j'avais aussi quelques idées sur un réseau de recherche construit en parallèle [22:26] <jrand0m> mais, bon, c'est probablement plus utile à i2p que je concentre mon temps sur le router [22:26] <Ophite1> ça tourne au-dessus d'i2p ? [22:26] <jrand0m> (le rendre fonctionnel, scalable, et sécurisé) [22:26] <jrand0m> oui [22:26] <jrand0m> i2p rend idn anonyme [22:27] <Ophite1> quelles étaient tes idées de réseau de recherche ? [22:27] <jrand0m> note : ce n'est pas encore écrit, mais ça a l'air d'être #2 sur ma todo list [22:27] <Ophite1> peut-on construire une autre dht via des tunnels ? [22:27] *** mihi (~mihi@anon.iip) a rejoint le canal #iip-dev [22:27] <jrand0m> en gros une base de données distribuée répliquée, avec des insertions et synchros hashcash, où les gens stockent des clés idn à côté de métadonnées / etc. [22:27] *** dm (~as@anon.iip) a rejoint le canal #iip-dev [22:28] <jrand0m> hmm, oui, certainement. mais i2p n'est pas intrinsèquement basé sur des tunnels - c'est basé sur des messages (i2p est IP, i2ptunnel est TCP) [22:28] <Ophite1> si ~tous les nœuds participent = très utile pour "découvrir" d'autres protocoles. [22:28] <jrand0m> clairement [22:28] <Ophite1> donc, ça devrait être standard. [22:28] <Ophite1> dhcp/zeroconf pour i2p ? :) [22:28] <jrand0m> idn serait une très bonne appli à livrer avec i2p pour offrir une "expérience prête à l'emploi" [22:29] <Ophite1> Si c'est censé être une application de communication/transfert/stockage de fichiers complète, je propose le nom "Darknet". [22:29] <jrand0m> :) [22:29] <Ophite1> Tu sais évidemment probablement d'où ça vient. :) [22:30] <dm> Ça vient d'où ? [22:30] <Ophite1> l'article de MS Research : The Darknet and the Future of Content Distribution. [22:30] *** Déconnexion: godmode0 (Ping timeout) [22:30] <TC> lien ? [22:30] *** tonious (~Flag@anon.iip) a rejoint le canal #iip-dev [22:30] <jrand0m> eh bien, tim may dit qu'il a inventé le terme il y a ~11 ans ;) [22:30] <tusko> où est la page wiki I2PIDN ? [22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc [22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN [22:30] <Ophite1> implique aussi que le réseau fonctionne "dans le noir" - personne ne sait qui est qui ;) [22:30] <jrand0m> exactement. [22:31] *** mihi_ (~mihi@anon.iip) a rejoint le canal #iip-dev [22:31] <jrand0m> eh bien, i2p lui-même est un darknet en ce sens, mais c'est de la messagerie générique - c'est la couche IP pour un tel darknet. [22:31] <jrand0m> i2ptunnel est la couche TCP, et idn est NFS :) [22:31] <Ophite1> i2p est le protocole qui permet de créer un tel réseau à partir de quelque chose de globalement comme overnet. [22:31] <Ophite1> à propos... y a-t-il un moyen de spécifier la priorité dans les messages ? [22:32] *** mihi est maintenant connu sous le nom de nickthief76430 [22:32] *** mihi_ est maintenant connu sous le nom de mihi [22:32] <jrand0m> marrant que tu mentionnes ça :) [22:32] *** nickthief76430 est maintenant connu sous le nom de mihi_backup [22:32] <mihi> oups... [22:32] <jrand0m> je lisais justement quelques uns des papiers HotNets2 à venir ((Link: http://nms.lcs.mit.edu/HotNets-II/program.html)http://nms.lcs.mit.edu/HotNets-II/program.html) et ça m'a inspiré des mécanismes de QoS sur i2p [22:33] <Ophite1> un bit volumineux/faible latence compromettrait-il légèrement l'anonymat (attaque par intersection ?) en permettant de relier des trafics ? même si ça bascule parfois ? [22:33] <Ophite1> ah, eh bien ça pourrait mieux marcher bien sûr =) [22:33] <Ophite1> Ne vous souciez pas de la négation plausible locale. [22:33] <jrand0m> oui, i2p suppose que la machine locale est de confiance [22:33] *** Déconnexion: dm (Ping timeout) [22:33] <Ophite1> C'est un problème à résoudre par Rubberhose/Marutukku et Thermite, pas par I2P. [22:34] <jrand0m> exactement. (sinon, le logiciel est compromis et peu importe ce qu'on fait) [22:34] * TC espère que sa machine locale est de confiance [22:34] <jrand0m> héhé [22:34] <Ophite1> TC : moyen facile de le savoir ; fais des menaces de mort contre Bush et vois si des agents du Secret Service débarquent chez toi ;-) [22:34] <jrand0m> lol [22:34] <TC> fait et refait [22:34] *** Déconnexion: tonious (Ping timeout) [22:34] <jrand0m> hah ! [22:35] * jrand0m regarde mon proxy squid se faire mettre hors service par le fbi [22:35] <TC> c'est un piège ! [22:35] <jrand0m> prenez une hache ! [22:35] <jrand0m> :) [22:35] <TC> quelqu'un a joué à uplink ? [22:35] <Ophite1> terminé. cracké. diffusé. [22:35] <Ophite1> entraîné aussi ;) [22:36] * jrand0m prend ça pour un "oui" [22:36] *** dm (~as@anon.iip) a rejoint le canal #iip-dev [22:37] <Ophite1> il peut y avoir des possibilités de DoS via le cache, les choses en mémoire... [22:37] <jrand0m> ok, donc voilà ce que je pense pour idn/kademlia. implémenter idn et le faire tourner sur le code 0.2., le malmener un peu, puis implémenter 0.3 avec cette implémentation kademlia [22:37] <jrand0m> oh certainement. la todo list a "mettre en file d'attente les messages en attente et les gros messages sur disque" :) [22:37] <dm> IDN ne devrait-il pas être implémenté après qu'I2P soit testé et mature ? [22:38] <jrand0m> c'est un des problèmes qu'on a rencontrés en testant un gros fichier de l'eepsite de TC [22:38] <Ophite1> dm : pas étant donné que c'est un banc d'essai pour la base fancy. [22:38] <jrand0m> dm> j'y pensais aussi, mais je dois implémenter le code kademlia pour préparer 0.3. en gros le code kademlia EST 0.3 [22:38] <Ophite1> J'aime bien la nature DHT hybride qu'un tel réseau offrirait cependant. [22:39] <dm> aha... [22:39] <jrand0m> mais si personne ne veut lui coller une UI normale avant i2p 1.0, ça pourrait aussi être une bonne idée [22:39] <Ophite1> découverte de nœuds DHT + routage de type ngr = scalabilité capable de gérer la masse critique [22:39] <dm> qu'est-il arrivé à cette liste initiale de jalons. secure-->anonymous-->not harvestable, etc... [22:39] <Ophite1> jrand0m : je m'abstiendrai de l'annoncer aux pirates jusqu'à ce qu'il soit prêt. ça suffit ? [22:39] <jrand0m> eh bien, moins le routage de type ngr :) on fait des tunnels :) [22:39] <TC> tant qu'on garde la CLI [22:39] <dm> ah scalable était un des éléments de cette chaîne. [22:39] <jrand0m> dm> 0.3 est nécessaire pour scalable. ce qui vient avant not harvestable [22:39] <jrand0m> merci Ophite1 :) [22:40] <jrand0m> définitivement TC. j'aurai besoin de la CLI pour tester [22:40] <Ophite1> la scalabilité du vrai truc anonyme est directement liée aux choix faits dans le routage des tunnels, et ça c'est une affaire d'implémentation du router ? [22:40] <jrand0m> (et, soyons honnêtes, on fera probablement la distribution logicielle / les versions avec idn) [22:40] *** godmode0 (~enter@anon.iip) a rejoint le canal #iip-dev [22:40] <dm> ok... ça sonne bien alors. [22:40] <jrand0m> absolument ophite. [22:40] <Ophite1> suggestion : taille maximale des messages ? [22:40] <jrand0m> c'est le Problème difficile [22:41] <jrand0m> la taille max des messages est actuellement follement grande (4g) mais je pense la réduire à 64k ou 128k [22:41] <jrand0m> mais je ne veux pas en arriver là tout de suite [22:41] * Ophite1 va fouiller dans ses notes [22:41] <Ophite1> les notes de scalabilité BitTorrent/Scone indiquent 512K. [22:42] <jrand0m> hé ok cool. (des refs à creuser ?) [22:42] <Ophite1> mais, pense-le comme la taille de fenêtre tcp. [22:42] <jrand0m> oui [22:42] <Ophite1> pas pour scone, désolé - projet de recherche d'une amie. [22:42] <jrand0m> cool, pas d'souci [22:42] *** Déconnexion: mihi_backup (Ping timeout) [22:42] <Ophite1> pour info, ta kademlia est à peu près aussi bonne que la sienne :) [22:42] <jrand0m> hehe [22:42] <jrand0m> (eh bien, je ne l'ai pas encore implémentée ;) [22:42] <Ophite1> euh, la sienne je veux dire :/ [22:42] <jrand0m> oh nickel [22:43] <dm> érection.. [22:43] *** mihi_backup (~mihi@anon.iip) a rejoint le canal #iip-dev [22:43] <jrand0m> héhé [22:43] <jrand0m> donc, c'est 2) kademlia, 0.3, et idn [22:43] <Ophite1> elle a nommé ses jouets d'après des puddings. custard, crumble (type Waste), strudel.. son bittorrent-like était le pudding le plus rapide du monde - 'scone ;) [22:43] <jrand0m> haha [22:45] <Ophite1> elle est matheuse. [22:45] <jrand0m> encore mieux [22:45] <jrand0m> il y a beaucoup de collecte / analyse de stats qui vont arriver pour une sélection avancée des pairs [22:45] <Ophite1> mais je verrai si je peux lui soumettre des trucs. la scalabilité d'i2np 0.9 venait d'elle - ça lui plaît. [22:45] <jrand0m> (malheureusement on ne peut pas tricher comme mnet, mixminion et tor) [22:46] <jrand0m> ravi de l'entendre [22:46] <Ophite1> un commentaire - dsa ? [22:46] *** nickthief54450 (~chatzilla@anon.iip) a rejoint le canal #iip-dev [22:46] <Ophite1> dsa 1024 bits, comme en SHA-1 ? [22:46] <jrand0m> ouais [22:47] <Ophite1> je suppose que c'est éprouvé. [22:47] <Ophite1> et aussi petit. [22:47] <jrand0m> oui. mais je ne suis pas 100% attaché à nos implémentations crypto particulières [22:47] <Ophite1> bref. passons à la roadmap. [22:47] <TC> haha, appelons une version windows 'Microsoft Darknet (r)' [22:47] <jrand0m> héhé tc [22:48] <jrand0m> ok, 3) révision de la feuille de route (0.2.3 --> 0.4, 0.2.2 --> 0.3.1) ? [22:48] <jrand0m> à cause de tous les bogues sur lesquels je tombe concernant la db de broadcast, je veux accélérer la sortie 0.3 (db kademlia) [22:48] <TC> c'est sympa de ne pas être limité par les marques déposées comme un projet open source normal [22:49] *** tonious (~Flag@anon.iip) a rejoint le canal #iip-dev [22:49] <jrand0m> 0.2.3 c'est routes restreintes / pairs de confiance, et probablement pas une exigence forte pour qui que ce soit ici. ça peut être repoussé en 0.4 sans problème, je pense [22:50] <jrand0m> 0.2.2 c'est des modifs de tunnels, mais je pense qu'une bonne partie de la pression pour implémenter ça va être allégée avec la sortie 0.2.1.1 (qui teste et reconstruit les tunnels si nécessaire, plutôt que d'attendre 10 minutes) [22:50] <Ophite1> les pairs de confiance sont un domaine qui a besoin de révision imho. [22:50] <jrand0m> d'accord. [22:50] *** dm_backup (~as@anon.iip) a rejoint le canal #iip-dev [22:50] <Ophite1> le seul domaine qui ne me donne pas des sensations chaleureuses. [22:50] <Ophite1> quoique c'est peut-être juste le mot "de confiance". :) [22:50] <jrand0m> en gros mes pensées actuelles sont de publier des tunnels vers des routers [22:50] <jrand0m> héhé [22:51] <jrand0m> (si on publie des tunnels vers des routers, on peut se passer de passerelles non fiables, ce qui enlève le "de confiance" de pairs de confiance) [22:51] *** Déconnexion: dm (Ping timeout) [22:51] *** dm_backup est maintenant connu sous le nom de dm [22:51] <Ophite1> il faut analyser les implications sur l'anonymat de ça. [22:51] <jrand0m> mais les pairs de confiance sont intrinsèquement nécessaires dans un système anonyme de grade militaire, où /tous/ les nœuds que tu peux contacter sont considérés comme des attaquants. [22:52] <Ophite1> je ne pense pas que ce soit vraiment possible... [22:52] <jrand0m> certainement. encore une raison pour laquelle ça devrait passer en 0.4 [22:52] <jrand0m> Ophite1> nœuds de confiance avec autodestruction temporisée / déclenchée. [22:52] <jrand0m> monter un pigeon, router à travers lui, le tuer [22:52] <jrand0m> exactement, si les pigeons effacent leurs logs après N heures / N octets / N messages [22:52] <Ophite1> je veux dire si tu veux que je sorte un ver qui en installe quelques millions... [22:53] <Ophite1> logs ? quels logs ? [22:53] <jrand0m> :) [22:53] <jrand0m> ok, formate les disques ;) [22:53] * Ophite1 a écrit un cheval de Troie furtif au niveau noyau [22:53] <jrand0m> sympa [22:53] * dm a écrit un plugin calendrier Outlook au niveau noyau. [22:53] <Ophite1> ...quand j'avais 19 ans :) [22:53] <Ophite1> marche toujours. :) [22:54] <Ophite1> je ne vais pas l'inclure ici cependant, ne t'inquiète pas, ou, euh, vérifie mon code, ce qui serait probablement une Bonne Chose À Faire de toute façon ;) [22:54] <dm> quand j'avais 12 ans. [22:54] <jrand0m> je ne pense pas qu'i2p veuille /une/ si grande distribution avant que la 1.0 soit stable et lourdement revue par les pairs [22:54] <jrand0m> héhé Ophite1 [22:54] <jrand0m> héhé dm [22:54] <Ophite1> franchement, je pense que c'est une fonctionnalité gadget. [22:54] <jrand0m> peut-être. [22:55] <jrand0m> par contre les routes restreintes sont nécessaires [22:55] <jrand0m> c'est une fonctionnalité de base pour les gens derrière des firewalls [22:55] <jrand0m> (des firewalls très restrictifs) [22:55] <Ophite1> bonjour, transports. [22:55] <Ophite1> on y viendra. [22:55] <Ophite1> ou est-ce le bon moment pour en parler ? [22:55] <jrand0m> sure, creusons :) [22:56] <jrand0m> on a déjà rencontré un problème avec un pair injoignable qui pourrait être résolu avec des routes restreintes [22:56] *** tusko a quitté #iip-dev [22:56] <jrand0m> même si c'était dû à une mauvaise configuration, ça pourrait être plus fréquent [22:57] <Ophite1> Aussi : étant donné deux pairs coopérants derrière des firewalls filtrant en entrée qui larguent les mauvais paquets, et un pair coopérant qui n'est pas derrière un firewall et peut envoyer des paquets avec adresses IP source forgées vers les deux autres... [22:57] <Ophite1> Tu peux établir une connexion TCP entre les deux pairs derrière firewalls que les deux firewalls considèrent comme sortante. [22:57] <jrand0m> clairement [22:57] <dm> adresses IP forgées ?!? [22:58] <Ophite1> croyez-moi, les firewalls sont un problème TRÈS courant. [22:58] <Ophite1> parfois ils sont contrôlés par l'utilisateur mais l'utilisateur est un boulet. ça peut être géré avec l'installeur qui gère le firewall :) [22:58] <dm> I2P va utiliser l'usurpation IP ? :) [22:58] <jrand0m> oui. si i2p ne peut pas fonctionner derrière firewalls / NATs / proxies, ça ne vaut pas la peine de continuer. [22:59] <Ophite1> parfois ils sont activement hostiles, des passerelles d'entreprise ou d'éducation qui cherchent délibérément à tout faire foirer. Il faut les traverser, et les traverser proprement. [22:59] <jrand0m> dm> options de transport [22:59] <jrand0m> absolument Ophite1 [22:59] <Ophite1> dm : j'ai une implémentation fonctionnelle - dans le protocole Direct Connect. [22:59] <jrand0m> i2p veut être le champ de bataille pour ce code. [22:59] <Ophite1> dm : si *ça* peut le gérer, i2p le peut. [22:59] *** Déconnexion: tonious (Ping timeout) [23:00] <Ophite1> je suggère de laisser ça désactivé par défaut. Seuls très peu en ont besoin, et ce serait bien s'ils peuvent annoncer qu'ils le sont pour que les requêtes leur soient routées. [23:00] <dm> on ne peut pas usurper des IP sans code natif, si ? [23:00] <Ophite1> l'avantage, c'est qu'ils n'ont pas besoin de router *à travers*, juste d'aider à la mise en place. [23:00] <Ophite1> = gros gain de vitesse. [23:01] <jrand0m> tout à fait Ophite1, c'est à ça que sert la structure RouterInfo.routerAddress[] [23:01] <Ophite1> dm : ouais, comme si ça n'allait pas être réécrit ? [23:01] *** tonious (~Flag@anon.iip) a rejoint le canal #iip-dev [23:01] <dm> ok, je vérifiais juste... [23:01] <jrand0m> oui dm, je n'ai aucun scrupule à inclure du code natif dans i2p [23:01] <Ophite1> je voudrais dire que je ne pense pas que java soit une solution permanente. [23:01] <Ophite1> Et que je considère le router java comme banc d'essai/prototype. [23:01] <jrand0m> ça me va. si ça nous amène à 1.0, règle le protocole, etc., c'est bon. [23:02] <Ophite1> ...et j'espère que ça ne reste pas coincé là comme freenet ;) [23:02] <dm> IPAddress.Spoof(192.168.32.1); [23:02] *** alient (alient@anon.iip) a rejoint le canal #iip-dev [23:02] <jrand0m> lol dm [23:02] <dm> import IPSpoofing; [23:02] <Ophite1> mmm... sockets bruts en java ;) [23:02] <jrand0m> fcntl / ioctl en java... mmMMmm [23:02] <mihi> hmm, les sockets bruts nécessitent root sur unix, non ? [23:02] <dm> des femmes à forte poitrine léchant mon pénis.. mmMMmmm [23:02] <jrand0m> donc on inclut un rootkit [23:03] <jrand0m> ;) [23:03] <Ophite1> jrand0m : déjà couvert =) [23:03] <jrand0m> héhé [23:03] <Ophite1> de plus comme j'ai dit ; seuls quelques-uns en ont besoin. [23:03] <jrand0m> oui [23:04] <jrand0m> et seulement pour des raisons légitimes, bien sûr. [23:04] <Ophite1> sur mon hub dc, un seul (bot) avait la capacité, et le hub lui disait quand des passifs voulaient se connecter à des passifs. [23:04] <Ophite1> ça a causé un peu d'étonnement. [23:04] <jrand0m> hehe [23:04] <Ophite1> a aussi fait fermer l'hôte du bot, d'où ma suggestion de peut-être le laisser désactivé par défaut :) [23:04] <jrand0m> c'est clairement une bonne fonctionnalité à avoir dispo [23:04] <jrand0m> lol [23:05] *** Déconnexion: nickthief54450 (Excess Flood) [23:05] <jrand0m> ok, donc avec les routes restreintes repoussées à 0.4, on a un mois ou deux pour continuer le débat sur la nécessité de la fonctionnalité [23:06] <jrand0m> d'autres idées / choses qui devraient être dans la roadmap et n'y sont pas, des choses mal placées, etc. ? [23:06] <Ophite1> je dis de le pousser en 0.4 définitivement. Ça va causer des soucis de firewall pour l'instant mais on est encore en test... [23:06] <Ophite1> ...quelqu'un qui ne peut pas ouvrir un port sur un firewall ne devrait probablement pas encore essayer. [23:06] *** nickthief54450 (~chatzilla@anon.iip) a rejoint le canal #iip-dev [23:06] <jrand0m> oui. et même avec des firewalls, PHTTP les laisse passer. [23:07] <Ophite1> il faut toutefois tester phttp contre des proxies hostiles. [23:07] * jrand0m est derrière un firewall que je ne contrôle pas et je participe pleinement à i2p [23:07] <dm> hax0r [23:07] <jrand0m> eh bien, oui, des proxies hostiles peuvent simuler une confirmation, mais tout est signé, donc le message ne peut pas aller au mauvais endroit / etc. [23:08] <jrand0m> mais le relais phttp et le transport ont beaucoup de fonctionnalités nécessaires [23:08] <Ophite1> en particulier, examiner les futures possibilités qu'auraient des routeurs de niveau application pour détecter/foutre en l'air le protocole. [23:08] <jrand0m> hm ? [23:08] <Ophite1> j'ai de l'expérience avec le tunneling firewall cependant. [23:08] <Ophite1> on voudra peut-être inclure un repli GET. [23:09] <jrand0m> hmm. GET va dans les logs. mais peut-être en repli [23:09] <jrand0m> (POST peut être vers /index.html) [23:09] <Ophite1> jrand0m : mais tout est signé/chiffré si les noderefs sont cool... ? [23:10] <Ophite1> à moins que le proxy devienne aussi un attaquant actif, ça va être assez dur pour lui. [23:10] <jrand0m> tous les messages sont chiffrés vers le router de destination, et la désignation de quel relais phttp emprunter est signée dans le routerInfo [23:10] <jrand0m> oui. le proxy phttp tel quel n'est certainement pas assez fort contre un attaquant actif [23:11] *** Déconnexion: grimps (Leaving) [23:12] <jrand0m> je pense que ce serait super si les gens postaient des idées de transports alternatifs sur le wiki :) [23:12] <jrand0m> ok, 4) état des applis [ppp2p, i2ptunnel, im, ns, squid] [23:12] <jrand0m> mince, tusko est parti [23:12] <jrand0m> tusko a écrit un script python (ppp2p) pour permettre de faire passer ppp sur i2p via i2ptunnel [23:13] <Ophite1> je t'avais dit que quelqu'un le ferait :) [23:13] <dm> ppp sur i2p ? [23:13] <jrand0m> je ne l'ai pas regardé, mais la dernière fois il faisait tourner un vpn sur i2p avec 5s de ping [23:13] <jrand0m> héhé oui [23:13] <Ophite1> dm : bien sûr. [23:13] <dm> quand pourrais-tu l'utiliser ? [23:13] <dm> pourrais/voudrais [23:13] <jrand0m> dm> outproxy anonyme [23:13] <Ophite1> dm : ANYTHING anonyme. [23:13] <jrand0m> pour, disons, faire tourner un nœud kazaa anonymement, ou autre [23:13] * Ophite1 souligne que quiconque fait tourner un lien sortant i2p->ppp est fou et sera probablement mis sur liste noire/traqué [23:13] <dm> ah, je comprends. [23:13] <jrand0m> tout à fait Ophite1 [23:14] <jrand0m> donc pour l'instant, c'est seulement pour des pairs de confiance. [23:14] <Ophite1> voir aussi : la cascade JAP de dresde... :) [23:14] <jrand0m> ce qui, bon, n'a pas vraiment de sens pour l'anonymat... [23:14] <jrand0m> héhé [23:14] <Ophite1> et la plupart des trucs qui sortent de leur nœud seront non chiffrés... [23:14] * jrand0m pense à ike sur ppp sur i2p [23:15] * jrand0m regarde ma tête exploser [23:15] *** fiaga (~po@anon.iip) a rejoint le canal #iip-dev [23:15] <Ophite1> jrand0m : pourquoi pas i2p sur ppp sur i2p ? [23:15] <jrand0m> tout à fait faisable. la récursion, c'est fun, non ? [23:15] <soros> i2p sur i2p :-o [23:15] <jrand0m> ou i2p sur ppp sur i2p sur i2p sur freenet sur kazaa [23:15] <Ophite1> là c'est juste idiot. Freenet ne fonctionnerait pas ;) [23:16] <godmode0> sur connexion lente :) [23:16] <jrand0m> héhé ça aurait des soucis de latence, c'est sûr :) [23:16] <mihi> ... sur un tunnel icmp sur ... [23:16] <Ophite1> ooh oui, loki :) [23:16] <Ophite1> 0ldsk00l :) [23:17] <Ophite1> Les adresses I2P, étant les clés publiques, sont ... plutôt longues. [23:17] <jrand0m> oui. [23:17] <jrand0m> d'ailleurs, comme on en est au point 4 : ns [23:17] <Ophite1> Comme une URL I2P www étant en fait trop longue pour être collée n'importe où de sensé (>512 caractères ?!!) [23:17] <mihi> co a promis d'écrire un service de noms... [23:17] <jrand0m> ouais. [23:17] <jrand0m> je pense qu'avec idn implémenté, il serait très facile pour quelqu'un d'adapter le code kademlia en un dns distribué [23:17] <mihi> Ophite1 : poste-les sur le forum eepsite. [23:18] <Ophite1> le problème de l'espace de noms tel que je le vois, c'est qu'il faut soit un certain degré de contrôle centralisé, SOIT permettre les collisions. [23:18] *** Déconnexion: fiaga (Ping timeout) [23:18] <jrand0m> (il suffit d'ajouter une CA ou des CAs WoT, et voilà. (Link: www.mihi.i2p)www.mihi.i2p) [23:18] <jrand0m> pas nécessairement. [23:18] <Ophite1> éclaire-moi avec tes meilleures idées alors. [23:18] <jrand0m> Ophite1> regarde les specs de co/wiht sur la liste iip-dev. [23:19] <Ophite1> le mieux que j'ai trouvé c'est que la clé racine crée des espaces de noms signés. style dnssec. [22:19] <jrand0m> il ne va pas jusqu'au bout avec une dht, mais il gère des groupes [22:19] <jrand0m> comme on le fait maintenant - on peut /tous/ choisir qui sont nos serveurs DNS racine. [22:19] <jrand0m> dans le même esprit, on devrait /tous/ pouvoir choisir qui est notre CA (ou CA WoT) [22:20] <jrand0m> donc techniquement il /pourrait/ y avoir des collisions, mais seulement une fois qu'il y a plusieurs groupes de CA qui n'interagissent pas [22:20] * Ophite1 note que c'est peu probable [22:20] <jrand0m> d'accord [22:20] <Ophite1> soit tu fais confiance à la CA racine soit pas. [22:20] <jrand0m> et si tu ne fais pas confiance à la racine, tu crées la tienne [22:21] <jrand0m> (ou tu en trouves une autre) [22:21] <Ophite1> et si tu ne fais pas confiance à la CA racine c'est pour une raison, une raison qui circulera vite. [22:21] <jrand0m> exactement [22:21] <jrand0m> surtout quand il y a de la publication anonyme :) [22:21] <Ophite1> étant donné que le seul vrai but des CA est d'assurer l'anti-collision - comme Trent... [22:21] <jrand0m> oui [22:22] <Ophite1> à peu près la seule chose qui ferait perdre confiance dans une CA c'est (1) fuite de clé ou (2) refus d'enregistrer quelque chose qui n'est pas déjà enregistré. [22:22] * jrand0m note la "fiabilité" de verisign [22:23] * Ophite1 note que Verisign prétend vérifier l'identité du détenteur du certificat - une des propriétés qu'un espace de noms I2P est en fait garanti de NE PAS faire [22:23] <jrand0m> certifs auto-signés+++ [22:24] <Ophite1> je soulignerais aussi que les systèmes distribués - comme Darknet, comme je vais l'appeler dorénavant jusqu'à ce que ça colle :) - construits au-dessus d'i2p n'utiliseraient probablement pas l'espace de noms. [22:24] <Ophite1> c'est pour les serveurs, vraiment. [22:24] <jrand0m> héhé [22:24] <jrand0m> oui [22:24] <Ophite1> Les serveurs ne passent pas à l'échelle. Ce problème sera dans i2p autant que dans IP. [22:24] <Ophite1> donc, je pense que l'usage en pratique sera en fait étonnamment limité. [22:24] <jrand0m> l'idn ("darknet") garderait des références aux destinations - les 387 bits complets de leurs clés, pas un joli nom [22:24] <jrand0m> d'accord. [22:25] <jrand0m> sauf / jusqu'à ce que quelqu'un écrive un système d'outproxy distribué [22:25] <jrand0m> alias o-r / freedom sur i2p [22:25] <TC> combien de clés différentes peut-on avoir ? [22:25] * jrand0m attend ce jour avec impatience [22:25] <jrand0m> tc> 2^2048 [22:25] <Ophite1> jrand0m : à ce moment-là la clé racine leur signe un espace de noms : .proxy.i2p [22:26] <dm> Ça doit être la réunion de développement open source la plus hypothétique/mégalomane de tous les temps :) [22:26] <jrand0m> les sous-espaces, c'est génial :) [22:26] <jrand0m> lol dm [22:26] <jrand0m> hé, on a le droit de viser haut, non ? [22:26] <dm> je suis sûr que la plupart des réunions de dev c'est : "Alors, on met 3 bits pour l'en-tête mpeg-5 ou 4 ?" [22:26] <Ophite1> jrand0m : aussi bizarre que ça paraisse, tous les nombres ne fonctionnent pas pour elgamal ;-) [22:26] <TC> dm, t'as vu les réunions debian non ? [22:26] <jrand0m> aaah c'mon, 000000000000000000000000000 est une clé sûre [22:26] * Ophite1 distribue des biscuits Digestive au chocolat [22:26] <dm> TC : non, elles sont comment ? [22:26] <Ophite1> jrand0m : ooh, identité. [22:26] <TC> dm, j'en sais rien, je demandais [22:27] <jrand0m> ok. thecrypto n'est pas là non plus... quelqu'un a des idées sur im ? [22:27] <Ophite1> mince, j'allais demander ça. [22:27] <Ophite1> une appli assez importante. [22:27] <dm> de toute façon, ce type de réunion est plus sympa pour les lurkers, donc je suis pour. [22:27] * dm est diverti. [22:27] <jrand0m> héhé [22:27] <TC> où est co ? [22:27] <Ophite1> comme beaucoup de gens s'attendront à ce qu'i2p soit le successeur de iip. [22:28] <jrand0m> iip sur i2p est assez facile, si on ne veut pas de dcc [22:28] <Ophite1> (je suppose que ça pourrait l'être, si on fait juste tourner un serveur irc iip sur i2p...) [22:28] <jrand0m> iip sur i2p avec dcc nécessite une nouvelle appli [22:28] <jrand0m> exactement Ophite1 [22:28] <jrand0m> 0 ligne de code [22:28] <TC> on ne peut pas juste faire tourner irc sur i2p ? [22:28] <Ophite1> j'aime pas cette idée parce que ... ben, elle ne nous donne rien qu'on n'a pas déjà :) [22:28] <jrand0m> mais la dernière fois que j'ai entendu, thecrypto travaillait sur une appli IM [22:28] <jrand0m> bien sûr tc [22:29] <jrand0m> oui Ophite1, et ça ne passe pas à l'échelle [22:29] <jrand0m> (tout le trafic est canalisé vers l'ircd) [22:29] <Ophite1> Et l'IRCd peut espionner le trafic. [22:29] <TC> ah, bon point [22:29] <jrand0m> (c'est là que UserX devrait apparaître et discuter de ses idées pour iip2.0) [22:29] <jrand0m> oui Ophite1 [22:29] <jrand0m> tous les problèmes du iip actuel [22:29] <Ophite1> jrand0m : Et absolument rien de différent. [22:29] <jrand0m> plus de latence. [23:30] <Ophite1> sauf que c'est en java. génial. :) [23:30] <jrand0m> héhé [23:30] <Ophite1> maintenant, une tonne de gens ont fait leurs armes d'undergrad en essayant et foirant la construction d'applis de chat distribuées. [23:30] <jrand0m> ok, donc quelqu'un devrait soit aider thecrypto soit le pousser un peu :) [23:30] * Ophite1 souligne IRC3 [23:30] <jrand0m> oui, c'est un projet parfait d'école [23:30] <Ophite1> ..et SILC... [23:30] <Ophite1> ...et... [23:31] <Ophite1> ben environ un milliard d'autres. [23:31] <jrand0m> exact [23:31] <Ophite1> littéralement tous ceux-là, je pourrais ajouter, sont pré-DHT pour autant que je sache. [23:31] <jrand0m> ouais [23:31] <Ophite1> c'est décevant parce que c'est une structure incroyablement utile. [23:31] <jrand0m> une DHT pour la recherche / P3P, et ensuite une connexion directe pour l'IM [23:31] <jrand0m> le chat de groupe est plus dur, mais pas trop [23:31] <Ophite1> enfin, direct au sens i2p :) [23:31] <jrand0m> héhé oui [23:32] <Ophite1> et darkmail/i2pmail ? [23:32] <soros> sexe de groupe aussi [23:32] <dm> soros : d'accord. [23:32] <jrand0m> le sexe de groupe n'est pas si dur soros ;) [23:32] <jrand0m> lol [23:32] <jrand0m> l'email sur i2p est facile. quelqu'un doit juste faire tourner un serveur pop [23:32] <jrand0m> ou webmail [23:32] <jrand0m> hahaha [23:33] <Ophite1> jrand0m : sûr, tant que littéralement tout le monde est ok avec ce foutu pgp :) [23:33] * Ophite1 refait des cauchemars CKT [23:33] <jrand0m> oh, vrai. ça exposerait le contenu au serveur ;) [23:33] <Ophite1> aussi... le spam. [23:33] <jrand0m> oui [23:33] <Ophite1> on a ce truc appelé hashcash. [23:33] <Ophite1> ils vont plutôt bien ensemble, non ? [23:34] <jrand0m> ok, donc ouais, quelqu'un devrait se mettre à une appli email spécifique i2p :) [23:34] <Ophite1> évidemment, ça marcherait mieux en tant que partie de l'im. [23:34] <Ophite1> Quelle est, après tout, la différence entre irc et email ? [23:34] <jrand0m> vrai, comme une boîte vocale IM [23:34] <Ophite1> Pouvoir ou non remonter (page up) et voir ce que tu as raté après être revenu... [23:34] <jrand0m> placée dans la dht [23:34] <jrand0m> bon point [23:35] * jrand0m aimerait qu'on ait une équipe d'une douzaine de codeurs [23:35] <Ophite1> note, cependant, que le mail nécessite du stockage, car c'est de la communication offline. irc ne nécessite pas de stockage, car c'est de la communication online. [23:35] <dm> l'email a aussi beaucoup plus de pubs d'agrandissement de pénis. [23:35] <Ophite1> jrand0m : demande des financements. [23:35] <Ophite1> dm : cf. ci-dessus sur hashcash. [23:35] <jrand0m> oui, le P3P pourrait contenir des messages en attente [23:36] <Ophite1> dm : une primitive qui n'était pas disponible au gars qui a bidouillé l'email en une nuit. [23:36] <Ophite1> (au moins on n'aura pas à utiliser des chemins ! pour spécifier le tunnel manuellement. héhéhé.) [23:36] * dm va regretter les protocoles en clair super simples. [23:36] <jrand0m> jrandom%ophite!dm!mihi [23:37] <Ophite1> non, c'est i2p. insère ~520 caractères poubelle entre les points d'exclamation et tu t'en approches ;) [23:37] <jrand0m> haha [23:37] <Ophite1> plusieurs de ces choses *sont* un peu liées. [23:37] <jrand0m> vrai, 387 octets encodés base64... [23:38] <Ophite1> ou pour le dire autrement, ELONGURL :) [23:38] <jrand0m> héhé [23:38] <Ophite1> [IE tronque à 512 ?] [23:38] <jrand0m> nan, ça marche bien [23:38] <Ophite1> tu avoues utiliser IE ? [23:38] <Ophite1> Pour naviguer anonymement ?! [23:38] <jrand0m> ;) [23:38] * Ophite1 sort six des meilleurs de Liu De Yiu et attend =) [23:38] * jrand0m utilise ie pour les eppsites, moz pour squid [23:39] <duck> on est à quel point de l'ordre du jour ? [23:39] <duck> 4 ? [23:39] <jrand0m> ouais, ok ok [23:39] <Ophite1> toujours 4 je pense. [23:39] <jrand0m> i2ptunnel. déchire toujours. [23:39] <jrand0m> des idées ? des commentaires mihi ? [23:40] <jrand0m> une chose que je veux noter concernant l'outproxy squid, c'est que j'ai mis à jour le filtrage des en-têtes pour AUTORISER LES COOKIES et remplacer l'user-agent par un truc idiot [23:40] * mihi attend juste le service de noms... [23:40] <jrand0m> mihi (ou quelqu'un d'autre)> ce serait vraiment facile d'amorcer un tel service de noms avec un ns i2p de style /etc/hosts [23:41] <mihi> au fait : y a-t-il d'autres destinations publiques à part ton squid et l'eepsite de tc ? [23:41] <jrand0m> i2pcvs.dest [23:41] <jrand0m> (pointe vers le pserver cvs d'i2p) [23:41] <jrand0m> (mais il n'est pas toujours up) [23:41] *** yodel (yodel@anon.iip) a rejoint le canal #iip-dev [23:41] <jrand0m> hola yodel [23:41] <yodel> hela [23:42] <jrand0m> ok, je pense que c'est tout pour 4) applis [23:42] <jrand0m> 5) commentaires / questions / etc. [23:42] <mihi> installeur graphique ? [23:42] <TC> salut yodel [23:43] <yodel> je dois commencer à expérimenter la mise de xml-rpc sur i2p [23:43] <yodel> devrait marcher avec httptunnel [23:43] <jrand0m> bonne question mihi. la dernière fois, MrEcho avait une partie qui marchait [23:43] <jrand0m> génial yodel [23:43] <jrand0m> tout à fait. [23:43] <jrand0m> quelle est la taille des flux ? [23:43] <jrand0m> (autrement dit, le protocole est-il bavard ?) [23:44] * Ophite1 prévoit d'essayer BitTorrent sur I2P comme test de charge [23:44] <yodel> xml sur http [23:44] <yodel> la couche ssl ne sera pas nécessaire avec i2p [23:44] <Ophite1> donc, euh, très bavard ? :) [23:44] <jrand0m> ah cool, gros POST ou grosses réponses ? [23:44] <jrand0m> (ou juste petit et petit ?) [23:45] <jrand0m> maudit sois-tu, Ophite1 :) [23:45] <yodel> tailles égales [23:45] <yodel> httptunnel supporte le http gzippé ? [23:45] <jrand0m> mais bt n'utilise-t-il pas des adresses IP ? [23:45] <jrand0m> hmm, httptunnel n'a aucune compression inhérente, c'est juste un bitstream [23:45] <TC> hmm, packager i2p+ppp\vpn+gui comme solution de sécurité pour les partages windows sans fil [23:45] <yodel> donc ça devrait fonctionner... [23:45] <godmode0> jrand0m> tu testes i2p sur serveur de news nntp ? [23:45] <jrand0m> oui yodel [23:45] <yodel> envoi de 500-1000 octets, idem en réponse [23:46] <jrand0m> hmm je n'ai pas encore testé ça godmode0 [23:46] <yodel> beaucoup moins quand c'est zippé [23:46] <jrand0m> oh cool yodel, ça marchera sans aucun problème [23:46] <yodel> quelle est la latence pour un msg/paquet/truc unique ? [23:46] <jrand0m> 2-5s, parfois jusqu'à 10s [23:46] <jrand0m> (actuellement) [23:46] <Ophite1> pas mal pour du pré-dht :) [23:46] <yodel> donc 20s aller-retour ? [23:47] <jrand0m> je charge généralement une page web en 5-10s [23:47] <yodel> ah [23:47] <yodel> bon [23:47] <yodel> +d [23:48] <jrand0m> mince, on approche des 2 heures. quelqu'un a d'autres questions / pensées ? [23:48] <Ophite1> La tarte c'est bon. [23:48] <duck> jrand0m : pourquoi tu bois de la bière locale bon marché ? [23:48] <Ophite1> L'orgie et la tarte c'est mieux. [23:48] <jrand0m> rofl duck [23:49] <Ophite1> duck : c'est mieux que Tesco Value Lager ? [23:49] * Ophite1 crache par réflexe [23:49] <jrand0m> héhé [23:49] * duck s'inquiète de la santé de jrand0m [23:49] <jrand0m> tu t'inquiètes de mes habitudes de bière bon marché mais pas de mes bonnes habitudes de whisky ? [23:50] * Ophite1 rappelle le single malt sur la tête de Cary Sherman [23:50] <duck> tu manges bien ? [23:50] <godmode0> corona [23:50] <duck> tu fais tes exercices quotidiens ? [23:50] <jrand0m> eh bien, je suis un de ces végétariens [23:50] <Ophite1> Ce n'est pas une question personnelle, ça, duck ? [23:50] <jrand0m> taper au clavier, ça compte ? [23:50] <duck> t'as déjà bu à ce point ? [23:50] <duck> que t'es devenu végétarien [23:50] <jrand0m> héhé [23:50] <Ophite1> la bière bon marché peut faire ça. [23:51] <duck> Ophite1 : la santé de jrand0m devrait tous nous préoccuper, puisqu'elle est essentielle pour I2P [23:51] *** Déconnexion: mihi_backup (mihi tend à jrand0m le *BAF*er) [23:51] <jrand0m> héhé ok ok mihi [23:51] * jrand0m s'élance [23:51] * jrand0m *baf* clôt la réunion