Réunion des développeurs I2P - 18 janvier 2005

13:04 <jrandom> 0) salut 13:04 <jrandom> 1) État du réseau 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (le son de la discussion crypto qui me passe à côté des oreilles) 13:04 <jrandom> :) 13:04 * jrandom fait signe 13:04 <cervantes> salut 13:04 <jrandom> vous aussi, vous pouvez écouter le son de la discussion crypto qui vous passe à côté des oreilles ! note d’état hebdomadaire publiée @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> salut 13:05 <jrandom> on se lance, puisque de toute façon on empiète sur une discussion intéressante... 1) état du réseau 13:05 <jrandom> je n’ai pas grand-chose à ajouter au-delà de ce qui est dans le mail – quelqu’un a-t-il quelque chose à soulever concernant l’état du réseau ? 13:06 <bla> À part le fait que, pour la première fois, on a vu des nœuds sur *tous* les continents sauf l’Antarctique, non. 13:06 <jrandom> w00t! 13:07 <jrandom> ok, passons à 2) trucs 0.5 13:07 <mule> hé, mon père est justement en route pour l’Antarctique, j’aurais dû lui donner un nœud 13:07 <ant> <duck> satanés Antarcticiens 13:07 <Xan> pas d’Antarcticiens ? :( 13:07 <jrandom> hah sympa 13:07 <jrandom> quoique je ne pense pas qu’il y ait un grand ensemble d’anonymat là-haut 13:07 <Frooze> blâmez l’Antarctique 13:08 * cervantes installe une plate-forme pétrolière en Antarctique pour pouvoir financer un nœud là-bas 13:09 <jrandom> ok ok, il y a beaucoup de choses pour la 0.5, on peut donc y aller par morceaux 13:09 <jrandom> d’abord, merci aux personnes qui ont collecté une journée de stats – plein de données intéressantes @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> avec plaisir :) 13:10 <cervantes> concernant l’état du réseau... j’ai vu pas mal de gens avoir du mal à faire démarrer I2P ces derniers temps (sur les forums, etc.) – je ne sais pas si c’est juste dû à une hausse du nombre d’utilisateurs ou peut-être à plus d’apps basées sur i2p qui peuvent foirer 13:10 <+protokol> jrandom: MENTEUR ! tu as dit que les données étaient intéressantes ! 13:10 * jrandom lance de la boue sur protokol 13:11 <ant> <duck> cervantes : j’ai aussi vu des retours de gens capables de le faire démarrer en quelques minutes 13:11 <ant> <duck> je pense que le NAT cause la plupart des problèmes 13:11 <cervantes> duck : vrai... 13:11 <ant> <dmdm> qui est NAT ? 13:11 <jrandom> cervantes : il reste certainement quelques problèmes moches. La question du NAT et d’OSX a été un peu pénible ces derniers temps, mais l’aide de Jhor sur le second devrait améliorer les choses 13:12 <cervantes> oui 13:12 <cervantes> *tousse* alors... 0.5 13:13 <Xan> dmdm : traduction d’adresses réseau 13:13 <jrandom> heh, ok. En gros, l’objectif de ces stats de taille de messages est d’explorer les questions de bourrage 13:14 <jrandom> malheureusement, la stratégie que j’ai bricolée en piochant des nombres au hasard était pourrie, elle ajoute 25 % de surcharge rien qu’avec le bourrage 13:14 <jrandom> si on choisit l’une des propositions pour le chiffrement 0.5 (tunnels-alt.html), on n’aura pas ce problème 13:15 <jrandom> (puisque ça imposera de petites tailles fixes avec fragmentation) 13:15 <mule> quel type de messages voulez-vous bourrer, ceux qu’un router voit ou ceux qu’un observateur externe voit ? 13:15 <jrandom> mule : question importante 13:15 <jrandom> si on ne s’inquiète que de l’observateur externe, on peut laisser les messages sans bourrage, en faisant toute génération de faux trafic à la couche de transport 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> d’un autre côté, si on craint que des participants au tunnel fassent de l’analyse de flux, il faut se soucier du bourrage dans le tunnel 13:16 <@duck> avec 5-6 sauts, quel est le risque qu’un router fasse de l’analyse de trafic ? 13:16 <cervantes> Teal`c : réunion en cours... peux-tu utiliser #i2p-chat pour annoncer des mp3 ;-) 13:17 <Teal`c> désolé 13:17 <cervantes> :) pour David Hasselhoff ? 13:18 <jrandom> ça dépend du niveau d’analyse, duck. S’ils ont d’une manière ou d’une autre repéré dans quel tunnel ils se trouvent (par ex. ils sont la passerelle d’entrée d’un tunnel entrant et ont moissonné la netDb, en corrélant ça avec une destination), ce sont des données non triviales. D’un autre côté ce n’est pas une exposition directe, mais ça donne des infos 13:18 <jrandom> encore plus important que le bourrage dans le tunnel, il y a le bourrage de bout en bout, qui cache les données de flux des messages aux passerelles et aux extrémités. 13:19 <jrandom> si on est fous/idiots, on pourrait aller jusqu’à un pipenet, en utilisant un débit constant partout 13:19 <+polecat> j’ai trouvé ! 13:19 <jrandom> (et finir avec zéro utilisateur qui fait tourner i2p) 13:19 <+polecat> Ce qu’il faut faire, c’est tunneler i2p par e-mail ! 13:19 <cervantes> quelle est la probabilité que des routers collusifs se retrouvent dans le même tunnel sur un réseau suffisamment grand ? 13:19 <+polecat> Aucun FAI ne serait assez bête pour bloquer l’e-mail ! 13:20 * jrandom attend l’implémentation net.i2p.router.transport.gmail 13:20 <postman> polecat : ouh là, c’est idiot 13:20 <postman> :) 13:20 <bla> cervantes : N^(-h) (N est le nombre de nœuds rapides, h = nombre de sauts). On dirait 13:20 <+polecat> =3 je sais. 13:21 <cervantes> c’est beaucoup ? :) 13:21 <jrandom> pas le nombre de nœuds rapides, puisque les personnes externes ne connaîtront pas vos profils 13:21 <+polecat> Sérieusement, en abusant sans vergogne des services IP existants, on pourrait tunneler i2p de multiples manières ingénieuses. 13:21 <jrandom> c^2/N^h pour faire entrer deux pairs dans le même tunnel 13:21 <jrandom> d’accord, polecat. C’est une des raisons pour lesquelles nous n’avons pas de tunnels bidirectionnels 13:22 <jrandom> certains transports (par ex. l’e-mail) sont nuls pour la communication bidirectionnelle 13:22 <bla> jrandom : c = ? 13:22 <jrandom> c == nombre de pairs collusifs 13:23 <+polecat> Hmm, point intéressant. 13:23 <ant> <duck> en termes de feuille de route, quel serait l’impact si i2p partait dans la mauvaise direction et choisissait une mauvaise solution crypto ? 13:23 <+polecat> Ou le protocole du pigeon voyageur, pas du tout bidirectionnel. 13:23 <+polecat> la crypto est déjà modulaire, non ? 13:23 <jrandom> duck : ce n’est qu’un point dans la 0.5, et une sous-section du doc tunnels*.html. Il y a bien plus dans le routage de tunnel que la simple façon d’envelopper les données 13:24 <bla> jrandom : Cela dit, c’est le problème pour les faire entrer dans le tunnel *maintenant*. Cependant, sur T renouvellements de tunnel (toutes les X minutes), on a P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> d’un autre côté, la différence entre « blocs fixes de 1 Ko » et « blocs de 0 à 40 Ko » a un impact substantiel 13:24 <+polecat> Je n’aimerais pas voir ce réseau suivre la voie d’Entropy, coincé dans McEliece. 13:24 <jrandom> polecat : lis http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom : Et donc ça tend vers zéro pour un temps suffisamment long. C.-à-d. que pour un temps suffisamment long, les attaquants seront dans le même tunnel au moins une fois 13:25 <jrandom> le plan, c’est AES256/CBC standard 13:25 <+protokol> j’ai entendu dire que DNS est bien pour tunneler des trucs, la plupart des gens ne le bloquent pas 13:25 <jrandom> certainement, bla, même si ce n’est pas tout à fait aussi direct (pour les tunnels exploratoires oui, mais pas pour les tunnels client) 13:26 <+polecat> Et si jamais même AES est cassé, on prendra un chiffrement symétrique équivalent. 13:27 <jrandom> bla : je ne pense pas que ce soit une inquiétude pratique énorme dans la plupart des cas à ce niveau, mais quand on le monte dans le cadre d’une attaque du prédécesseur, la question devient en grande partie sans objet 13:28 <jrandom> (à cause de la façon dont on fait le reste du routage de tunnel) 13:28 <bla> jrandom : ok 13:28 <jrandom> exact, polecat 13:29 <jrandom> duck : si on prend la deuxième option, changer pour une autre plus tard sera sans doute facile. 13:29 <jrandom> d’un autre côté, la deuxième option demandera des optimisations de performance costaudes pour que ça ne soit pas nul 13:29 <jrandom> mais je suis sûr qu’on peut y arriver 13:31 <jrandom> bref, je pense que ce qui précède couvre où nous en sommes actuellement concernant le travail 0.5 13:31 <jrandom> quelqu’un a d’autres questions/commentaires/inquiétudes ? 13:31 <bla> jrandom : Une 13:32 <bla> jrandom : je pense qu’on devrait valoriser un peu plus l’anonymat que la performance pour le moment : donc oui, les options PRNG (générateur de nombres pseudo-aléatoires) semblent bien 13:33 <jrandom> d’accord. La performance peut être améliorée plus tard, « ajouter » un meilleur anonymat en revanche est beaucoup plus difficile 13:33 <jrandom> (mais bien sûr, la performance /est/ un paramètre de sécurité. si c’est pourri, personne ne l’utilise) 13:33 <bla> Oui. 13:33 <bla> jrandom : 13:33 <bla> désolé 13:33 <@duck> d’accord, /me bascule le bit magique de performance de Freenet 13:33 <cervantes> peut-être que ça dissuadera tous ces leechers agitant leurs torrents de rester à l’écart un peu plus longtemps ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- connexion réinitialisée 13:34 <bla> cervantes : Non, ce n’est pas moi ! :) 13:34 <cervantes> :) 13:35 <jrandom> je pense qu’on peut réussir des optimisations vraiment cool, et il semble que beaucoup de nos étranglements ne sont pas liés à la sélection des pairs, mais simplement (heh) à des bogues dans la jobqueue 13:36 <jrandom> mais bref, autre chose pour 2) 0.5 ? 13:36 <ant> <BS314159> pourrais-tu poster une explication de cette attaque par boucle ? 13:37 <ant> <BS314159> ça semble plus dangereux que ce que ton traitement laisse entendre 13:37 <jrandom> boucle : construire un tunnel contenant A-->B-->C-->D-->C, envoyer 10 messages. 13:37 <jrandom> sans les PRNG, tu peux ajouter autant de messages que tu veux à cette boucle C<-->D 13:38 <ant> <BS314159> ok 13:38 <jrandom> en lançant effectivement un DoS contre n’importe quels routers avec juste quelques messages 13:38 <ant> <BS314159> mais seul A peut faire ça 13:38 <jrandom> avec les PRNG, ça limite le nombre de messages qui peuvent entrer dans la boucle 13:38 <ant> <BS314159> donc il n’y a pas de danger qu’un attaquant raccourcisse mes tunnels en introduisant des boucles 13:38 <jrandom> non, personne ne peut raccourcir tes tunnels 13:39 <jrandom> la seule chose à laquelle ça sert, c’est un DoS 13:39 <jrandom> (un DoS très bon marché) 13:39 <jrandom> (mais quand tu peux faire un DoS de manière sélective sur des pairs à peu de frais, tu peux faire des choses très très vilaines) 13:40 <ant> <BS314159> je comprends 13:40 <+protokol> et les certificats hashcash aideront pour ça ? 13:40 <jrandom> protokol : hashcash traite le problème d’un pair qui construit trop de tunnels, et peut-être qui construit trop de sauts 13:41 <jrandom> protokol : ça n’aide pas contre les boucles. Les deux moyens que j’ai trouvés qui /marchent/ sont les PRNG (tunnel-alt.html) ou la vérification à chaque étape (tunnel.html) 13:42 <jrandom> vérifier à chaque étape comporte des dangers, donc l’orientation actuelle est plutôt vers les PRNG 13:42 <+Ragnarok> quelle sera l’efficacité de la méthode PRNG ? 13:42 <Xan> A-->B-->C-->D-->C – chaque saut ne devrait-il pas avoir un identifiant différent ou quelque chose, pour que les messages quittent le tunnel la deuxième fois qu’ils atteignent C plutôt que de boucler ? 13:43 <jrandom> Xan : si, mais sans vérifier chaque étape, tu ne peux pas dire si c’est mauvais ou pas 13:44 <jrandom> Ragnarok : je pense que ce sera très efficace pour minimiser les dégâts 13:45 <jrandom> du moins, d’après ce que je vois jusqu’ici 13:45 <jrandom> si quelqu’un voit des problèmes avec ça, ou a des suggestions d’amélioration, contactez-moi :) 13:46 <Xan> ou peut-être que je passe à côté 13:46 <Xan> à plus 13:46 <jrandom> 'k à+, je mettrai à jour le doc pour être plus clair 13:47 <jrandom> ok, à moins qu’il y ait autre chose, on passe à 3) i2pmail.v2 ? 13:47 <jrandom> postman : t’es là ? 13:48 <postman> oui 13:49 <postman> :) 13:49 <jrandom> quelque chose à ajouter par rapport à ton post sur le forum ? ça a l’air plutôt cool 13:49 <postman> eh bien, quelques-uns d’entre vous ont peut-être déjà lu le brouillon pour i2pmail.v2 13:50 <bla> wtf se passe-t-il ? Déconnexions massives. J’ai aussi du mal à atteindre des sites (par ex. orion, library) ici 13:50 <postman> il vise à une infrastructure mail entièrement décentralisée à terme 13:50 <postman> mais il a besoin de logiciels proxy sur les nœuds ainsi que d’un paquet de relais dédiés 13:51 <postman> tout le monde est invité à contribuer idées / concepts / coups de gueule 13:51 <postman> le développement a déjà commencé – n’attendez rien avant la fin du printemps :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, les flics viennent juste d’arriver à ma porte 13:52 <bla> kaji : ? 13:52 <jrandom> vite, fais sauter ton disque dur 13:52 <postman> jrandom : voilà, c’est tout ce que j’ai à dire pour l’instant :) 13:52 <cervantes> cachez la table de blackjack ! 13:52 <jrandom> trop cool, merci postman 13:52 <kaji> ils ont dit que j’avais composé le 911, mais je suis presque sûr que ni moi ni mon frère ne l’avons fait 13:53 <+protokol> kaji : ils vérifient juste i2p 13:53 <jrandom> ok, à moins qu’il y ait autre chose sur 3) i2pmail, passons à 4) azneti2p_0.2 13:53 <+protokol> <musique flippante> 13:53 <jrandom> comme mentionné dans l’e-mail, il y a eu des avancées importantes récemment 13:53 <kaji> puis ils ont dit que les téléphones sans fil pouvaient déconner quand ils sont décrochés, mais tous mes téléphones sans fil sont sur leur chargeur -> #i2p-chat 13:55 <jrandom> les gens d’Azureus ont été très réactifs pour préparer une mise à jour (yay !), mais il faut aussi que les gens restent à l’affût des problèmes 13:55 <jrandom> (si vous ne lisez pas la mailing list i2p et utilisez azneti2p, lisez la mailing list i2p) 13:55 <jrandom> ((ou même si vous n’utilisez pas azneti2p, lisez la liste, car c’est là qu’on annonce des choses importantes ;) 13:56 <jrandom> duck et orion ont aussi fait plein de mises à jour pour accommoder le nouveau client bt et le formatage 13:56 <jrandom> (yay !) 13:56 * orion sourit 13:57 <orion> il reste encore du chemin, mais pour l’instant, ça marche. 13:57 <jrandom> (dans la mesure où i2p le permet ;) 13:58 <orion> héhé, oui. ;) 13:58 <jrandom> quelqu’un d’autre a quelque chose à soulever concernant azneti2p ou i2p-bt ? 13:58 <jrandom> (ou bytemonsoon2p ;) 14:00 <jrandom> ok sinon, on enchaîne avec 5) ??? 14:00 <jrandom> la parole est libre – quelqu’un d’autre a quelque chose à soulever ? 14:00 <postman> jrandom : pourquoi l’addressbook publie-t-il des entrées userhosts ? 14:01 <jrandom> postman : bug. 14:01 <postman> donc ce n’était pas un comportement prévu et ça va être changé ? 14:01 <cervantes> juste une chose... 14:01 <jrandom> postman : correct, et ce sera changé 14:02 <jrandom> (hein Ragnarok ? :) 14:02 <+Ragnarok> ça dépend précisément de ce que veut dire postman... 14:03 <jrandom> Ragnarok : les nouvelles entrées ajoutées par l’utilisateur local à ses hosts privés ne devraient pas être propagées aux hosts publiés 14:03 <jrandom> (par ex. userhosts.txt est privé, hosts.txt est synchronisé avec d’autres personnes et est public) 14:03 <cervantes> Dans le cadre d’une rubrique semi-régulière sur le forum, il y aura des reconnaissances et des récompenses pour ceux qui ont apporté de bonnes choses à I2P récemment ou sur toute la durée du projet 14:03 <postman> Ragnarok : après la mise à jour vers 0.4.2.6 j’ai trouvé des entrées de mon userhosts.txt dans l’addressbook publié, dans mon dossier eepsite 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok : c’étaient des clés ajoutées manuellement, qui n’étaient pas censées être publiées 14:04 <cervantes> cette semaine nous mettons à l’honneur duck pour son excellence générale en tant que fournisseur de services pour la communauté et comme grand idleur polyvalent : http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (allez duck, allez, allez duck, allez) 14:05 <Teal`c> et le détournement de nom de domaine ? 14:05 * brachtus applaudit 14:05 * orion fait un dandinement de canard en signe de respect. 14:05 <cervantes> un point important pour l’avenir... vous n’avez pas besoin d’être un génie de la cryptographie pour recevoir des louanges ! 14:06 <+Ragnarok> non, c’est le comportement attendu. Je peux le changer, mais d’abord je dois finir d’implémenter le verrouillage de fichiers pour que vous puissiez modifier hosts.txt directement 14:06 <orion> (mais ça aide) 14:06 <cervantes> vous avez peut-être simplement contribué un eepsite génial ou autre... 14:06 <cervantes> ou été une personne utile sur le forum, etc. 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (sinon, soyons honnêtes, jrandom gagnerait chaque semaine) 14:07 <jrandom> hé, vous financez tous ma cagnotte à bière, ce truc n’est pas gratuit ;) 14:07 <ant> <BS314159> tu pourrais juste créer un nouveau fichier, « publichosts.txt » ? 14:07 <ant> <BS314159> puis faire en sorte que l’addressbook ignore userhosts.txt, mais permette aux utilisateurs de s’abonner à leur propre publichosts.txt ? 14:08 <jrandom> Teal`c : il n’y a aucun moyen de détourner un nom de domaine, aucune entrée n’est écrasée, et userhosts a toujours la priorité sur hosts 14:09 <jrandom> Ragnarok : peut-être que l’interface web peut régler le problème de verrouillage, puisque les utilisateurs n’ajouteront pas dans les fichiers manuellement 14:09 <+Ragnarok> une fois le verrouillage fait, il n’y aura plus vraiment de raison d’intégrer des adresses depuis userhosts.txt (c’est actuellement la seule manière d’éviter une condition de course), donc ça n’a pas vraiment de sens d’ajouter un troisième fichier 14:10 <+Ragnarok> jrandom : eh bien, je prévoyais d’utiliser l’API Java de verrouillage de fichiers 14:10 <jrandom> si tu penses que c’est nécessaire, c’est toi le boss :) 14:10 <ant> <BS314159> ça te permettrait de supprimer tous les noms obtenus d’autres personnes tout en gardant ceux que tu as créés toi-même 14:10 <ant> <BS314159> tout simplement en vidant hosts.txt et en changeant ton abonnement 14:11 <ant> <BS314159> mais j’imagine que ça peut attendre la signature des noms 14:11 <orion> les métadonnées résoudront ce problème. Y a-t-il déjà un brouillon de spec ? 14:11 <jrandom> n’utiliser que deux fichiers devrait suffire – un géré par l’addressbook, un non 14:12 <jrandom> (tu pourrais même faire en sorte que l’addressbook ignore complètement userhosts.txt – userhosts.txt a de toute façon priorité sur hosts.txt) 14:12 <+Ragnarok> jrandom : ce serait le plan, une fois le verrouillage fait (ce qui ne devrait vraiment pas être trop de boulot, je n’ai juste pas encore eu le temps :) 14:13 <+Ragnarok> et je travaille actuellement à apprendre suffisamment les schémas XML pour en écrire un pour les enregistrements de noms 14:13 <ant> <dr_kavra> c’est le canal pour kenosis ? un autre canal m’a dit de venir ici :D 14:13 <jrandom> lol 14:13 <jrandom> non, désolé, ici c’est i2p 14:14 <jrandom> (à moins que tu ne cherches une couche de comm anonyme) 14:14 <jrandom> trop cool, Ragnarok 14:14 <ant> <BS314159> je trouve toujours que XML est trop verbeux et peu lisible pour ça, comparé à YAML, mais ce n’est pas moi qui écris le code 14:14 <jrandom> Ragnarok : la partie difficile sera de faire la crypto avec XML sans retomber sur du vilain CDATA 14:14 <orion> quelqu’un a déjà écrit un brouillon fonctionnel pour la spec des métadonnées ? 14:15 <jrandom> (personnellement je pense que XML craint, mais je suis juste un râleur) 14:15 <jrandom> orion : http://dev.i2p.net/pipermail/i2p/2004-February/000135.html propose une configuration de base 14:15 <orion> (métadonnées nom/clé) 14:15 <dox> l’addressbook et ses fonctionnalités ont-ils été annoncés quelque part ? Je ne savais pas que mon hosts.txt était publié 14:15 <jrandom> (voir les éléments NameReference et LocalEntry) 14:16 <jrandom> dox : c’est écrit à l’emplacement spécifié dans addressbook/config.txt 14:16 <jrandom> (par défaut, ./eepsite/docroot/hosts.txt) 14:17 <orion> il manque un indicateur public/privé (c.-à-d. distribuer, ne pas distribuer). 14:17 <ant> <cervantes> la seule bonne chose avec XML (et c’est un gros +) c’est que c’est une norme largement acceptée 14:17 <jrandom> exact, orion, beaucoup de bonnes idées sont apparues depuis ce message 14:17 <+Ragnarok> XML craint peut-être, mais franchement c’est mieux que toutes les alternatives pour ce que je fais 14:17 <jrandom> cervantes : EDI aussi 14:17 <orion> y a-t-il un endroit pour les condenser ? p. ex. une section du forum ? 14:18 <orion> ou peut-être une page wiki ? 14:18 <jrandom> orion : le wiki de susi ou d’ugha 14:18 <orion> je vais mettre en place des wikis pour bytemonsoon et orion.i2p afin d’aider à obtenir un consensus communautaire sur les objectifs de développement futurs de chacun. 14:18 <BrockSamson> xml + crypto sans CDATA = MIME, non ? 14:19 <jrandom> trop cool, orion 14:19 <jrandom> BrockSamson : smime, avec des parseurs différents ;) 14:19 <orion> (également un pour les métadonnées de nom) 14:21 <jrandom> il y a beaucoup de façons de faire les métadonnées, l’important c’est la flexibilité et la « correction » pour que ça puisse évoluer ou changer au fil du temps 14:21 * jrandom est sûr que Ragnarok et consorts vont proposer de bonnes choses :) 14:21 <orion> c’est pourquoi je pense qu’un brouillon public s’impose. 14:22 <ant> <cervantes> i2p consortium :P 14:22 <jrandom> eh bien, ça fait quelques réunions que les gens disent « quelqu’un devrait mettre ses idées sur le wiki », mais les pages du wiki ne grossissent pas beaucoup ;) ce n’est pas grave, on avance à notre rythme 14:23 * orion promet d’avoir trois wikis en ligne d’ici un jour et d’envoyer par e-mail à tout le monde leurs emplacements 14:23 <BrockSamson> traitez-moi de fainéant, mais comparez un bon de commande EDI ANSI 850 à quasiment n’importe quel bon de commande basé sur XML, et je préfère décoder, coder et déboguer la version XML. Même si elle fait 5x la taille de l’EDI 14:23 <jrandom> w00t 14:23 <jrandom> heh BrockSamson 14:24 <BrockSamson> La position 10 est ST ? oh alors la position 310 devrait être le nom 14:24 <BrockSamson> pfff moi 14:24 <jrandom> BrockSamson : je ne pense pas que les schémas XML pour les bons de commande soient bien meilleurs ;) 14:24 <jrandom> (mais ouais, ce truc est juste un sacré désastre) 14:25 <BrockSamson> ils le sont à 4h30 du matin 14:25 <BrockSamson> à moins que... 14:25 <jrandom> heh 14:25 <BrockSamson> ce soit écrit par un ex-programmeur EDI 14:25 <BrockSamson> et que le XML ressemble à ceci : <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> je parie que si vous additionnez les heures que les projets OpenSource passent à débattre « XML ou pas XML », vous pourriez coder Linux 10 fois. 14:26 <BrockSamson> chaque projet auquel j’ai participé a eu des débats massifs là-dessus 14:27 <orion> les débats sont bons pour un projet, selon qui débat. ;) 14:27 <jrandom> bah, ça fait ce que ça fait, mais ce n’est pas une panacée. ça peut bien marcher pour les trucs de nommage 14:28 <BrockSamson> beaucoup de gens sont dans les projets juste pour débattre, toutefois. 14:28 <jrandom> pas ici. moi je suis là pour la bière gratuite 14:28 <ant> <cervantes> c’est discutable 14:28 <orion> les détails d’implémentation seront plus clairs quand le brouillon de spec sera plus tangible. 14:28 <orion> d’où le besoin d’un wiki/revue par les pairs. 14:29 <BrockSamson> j’ai entendu dire que ce projet offrait de l’ail gratuit 14:29 <jrandom> beaucoup 14:30 <jrandom> ok, quelqu’un d’autre a quelque chose à soulever pour la réunion ? 14:30 <ant> * cervantes sort la vache cérémonielle avec cloche 14:30 <ant> <cervantes> call =cow 14:30 * jrandom se prépare 14:31 * jrandom *baf*s la cloche à vache, clôturant la réunion