Réunion des développeurs I2P - 12 septembre 2006

16:06 <jrandom> 0) salut 16:06 <jrandom> 1) 0.6.1.25 et état du réseau 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (quoi/pourquoi/quand) 16:06 <jrandom> 4) Questions crypto pour Syndie 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) salut 16:06 * jrandom fait un signe de la main 16:06 <jrandom> notes d’état hebdo publiées sur http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 16:07 <jrandom> puisque ces notes sont sorties il y a des heures et des heures, vous devriez déjà les avoir lues et avoir des remarques prêtes, non ? ;) 16:07 <jrandom> passons directement à 1) 0.6.1.25 et état du réseau 16:08 <vulpine> <Complication> Concernant 0.6.1.25, ça semble avoir bien fonctionné ici, un seul bug jamais vu auparavant 16:08 <jrandom> cool, c’est quoi le souci ? 16:08 <vulpine> * Complication cherche dans les logs 16:09 <jrandom> la taille du réseau semble plus grande qu’avant, même ordre de grandeur 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> ah ok cool, celui-là existe depuis longtemps, on peut l’ignorer sans risque 16:11 <vulpine> <Complication> Une seule occurrence 16:11 <vulpine> <frosk> j'en ai eu plusieurs du dernier 16:11 <vulpine> * jrandom taquine fox 16:12 <vulpine> <Complication> Oh, et encore un : "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (semble non significatif aussi, peut-être une simple congestion) 16:12 <jrandom> ouaip, probable 16:13 <jrandom> irc est, évidemment, encore un peu chaotique en ce moment 16:13 <jrandom> (mais, pour une fois, ce n’est pas la faute d’i2p :) 16:14 <jrandom> ok, quelqu’un a autre chose pour 1) État du réseau et 0.6.1.25 ? 16:15 <kostya213> je veux juste ajouter que la .25 a corrigé tous les problèmes que j’avais ces derniers mois 16:15 <jrandom> Wikked ! 16:16 <vulpine> <green> s'il te plaît, change le calcul du statut quand on utilise uniquement NTCP 16:16 <jrandom> ok, mais il n’est pas recommandé de désactiver udp (je crois avoir explicitement dit que je ne dirai pas aux gens comment désactiver l’udp non plus) 16:17 <jrandom> mais le statut devrait être mis à jour pour tenir compte du fait que udp n’est pas le seul transport 16:17 <jrandom> je corrigerai ça dans la prochaine révision, merci 16:17 <vulpine> <green> jrandom : bien sûr tu ne le diras pas, mais je sais lire le code ;) 16:18 <jrandom> d’accord, mais quand je ne recommande pas quelque chose et que je dis aux gens de ne même pas essayer, ne soyez pas surpris si un message d’affichage apparaît et prête à confusion ;) 16:19 <vulpine> <green> bien sûr, je pourrais aussi juste afficher "OK" dans la console :) 16:19 <jrandom> pas faux 16:21 <jrandom> ok, passons à 2) I2PSnark 16:21 <jrandom> zzz ne semble pas être là pour l’instant 16:22 <jrandom> zzz travaille sur quelques changements pour améliorer l’ordonnancement dans i2psnark 16:23 <jrandom> (c’est un peu… simpliste en ce moment si je me souviens bien, même si je ne suis pas totalement sûr des modifs sur lesquelles zzz bidouille) 16:23 <jrandom> ((mais j’ai hâte de voir les progrès !)) 16:25 <jrandom> ok, s’il n’y a rien d’autre sur 2) I2PSnark, passons à 3.*) trucs sur Syndie 16:26 <jrandom> commençons par 3.1) qu’est-ce que Syndie, puisqu’il y a beaucoup à couvrir 16:27 <jrandom> j’ai reçu quelques questions avant la réunion concernant le chiffrement des messages 16:27 <jrandom> en gros, les messages sont chiffrés de façon symétrique — toute personne ayant la clé symétrique peut lire le message, car elle est autorisée 16:28 <jrandom> les réponses de canal sont chiffrées de façon asymétrique avec la clé publique associée au canal/forum 16:28 <jrandom> certains messages peuvent utiliser un chiffrement basé sur une phrase de passe pour générer la clé symétrique de lecture 16:29 <jrandom> et certains messages peuvent inclure la clé symétrique dans les en-têtes lisibles du message (afin que tout le monde puisse le lire) 16:29 <modulus> quel est l’intérêt de ce dernier cas ? 16:29 <jrandom> et certains forums peuvent eux-mêmes inclure la clé symétrique dans les métadonnées du forum, de sorte que tout le monde puisse lire le message mais seulement s’ils possèdent les métadonnées du canal 16:29 <jrandom> modulus : pour que tout soit toujours chiffré, même le contenu lisible publiquement 16:29 <jrandom> (afin que l’écoute triviale soit inutile) 16:30 <modulus> d’accord, je vois. 16:31 <jrandom> ok, je pense que cela couvre les questions de chiffrement posées avant la réunion 16:31 <jrandom> quelqu’un a des questions sur 3.1) qu’est-ce que Syndie ? 16:31 <jrandom> (je veux dire, davantage sera clarifié au fur et à mesure que ce sera publié, bien sûr) 16:32 <vulpine> <void> hmm 16:33 <jrandom> que tal void? 16:33 <vulpine> <void> <void> je suppose que l’archive de message (.zip) peut aussi inclure d’autres messages, éventuellement d’autres personnes, comme les messages cités ? 16:34 <jrandom> eh bien, oui, tu peux inclure des fichiers .snd en pièces jointes, mais il y a un espace de noms explicite, donc tu peux faire des liens de type References: standard vers des messages précédents 16:34 <jrandom> (c.-à-d. que tu n’as pas besoin de faire un « threading » à la Frost) 16:35 <vulpine> <void> ok, d’accord 16:37 <vulpine> <Complication> À propos de Syndie, je me demandais comment on résoudrait le problème de donner à des personnes l’accès à un forum à auteurs multiples (comme des comptes sur un forum classique) sans que ce soit irrévocable, et d’éviter le bazar indésirable lorsqu’il faut révoquer l’accès (pour quelque raison que ce soit) 16:38 <vulpine> <Complication> Une solution, bien sûr, serait que l’auteur précise une recommandation indiquant quelles réponses les clients devraient afficher 16:38 <jrandom> Complication : créer une nouvelle paire de clés publique/privée, donner la clé privée aux personnes (temporairement) autorisées, et inclure la clé publique dans la liste des « keys allowed to post » 16:38 <vulpine> <Complication> …et que les clients, sauf s’ils veulent éplucher l’historique, suivent cette recommandation (ou plus précisément sa dernière version) 16:38 <jrandom> (et quand ils ne sont plus autorisés, retirer cette clé de la liste « keys allowed to post ») 16:39 <kostya213> jrandom : tu devrais peut-être utiliser une extension différente de .snd car c’est une extension largement utilisée pour les applications audio, le MIME va s’y tromper 16:39 <jrandom> ah, oui — tous les forums ont un « owner » (une clé privée de signature) qui peut gérer la liste de ceux qui sont autorisés à poster, etc 16:39 <vulpine> <Complication> « keys allowed to post » serait des métadonnées attachées au dernier message de l’auteur, ou à un autre message, c’est bien ça ? 16:39 <jrandom> bon point kostya213, mais du coup on risque de se retrouver coincés avec .dat ;) 16:40 <jrandom> Complication : ah désolé, non, c’est comme le Syndie actuel/ancien — des messages de métadonnées séparés et signés pour le forum/canal lui-même 16:40 <vulpine> * Complication pense que quelqu’un a même déjà revendiqué .dat pour quelque chose :) 16:40 <jrandom> oui, l’application appelée « octet-stream » ;) 16:40 <vulpine> <void> on dirait que .syn n’est utilisé pour rien de notable 16:41 <vulpine> <Complication> Aha, des messages spéciaux de métadonnées… oui, ça pourrait faire l’affaire 16:41 <jrandom> oh chouette, on arrive à syn ! 16:41 <jrandom> (bien vu void, merci kostya213) 16:41 <vulpine> <void> hmm, 16:41 <vulpine> <void> hmm, "Word Synonym File", Company: Microsoft 16:42 <jrandom> bon, je suis sûr qu’on trouvera une solution 16:42 <kostya213> oui c’est utilisé par Word 16:42 <vulpine> <void> mais on peut très bien ignorer ça :) 16:42 <kostya213> ne perdez pas espoir, je pense qu’il est possible de trouver quelque chose qui ne posera pas de problèmes avec les types MIME largement utilisés 16:43 <jrandom> ok, autre chose sur 3.1) Qu’est-ce que Syndie ? 16:43 <vulpine> <void> euh, d’ailleurs, pourquoi se cantonner à des extensions à trois lettres ? c’est une relique de l’ère DOS 16:43 <kostya213> une chose à demander, pourquoi limiter à une extension à trois lettres ? personne n’utilise plus DOS 16:44 <jrandom> hehe 16:44 <kostya213> jinx sur void 16:44 <kostya213> .syndie me paraît bien 16:44 <vulpine> <void> .synd n’entrerait en conflit avec rien 16:44 <kostya213> bien aussi 16:45 <vulpine> <void> maudit lag :( 16:48 <jrandom> ok, passons à 3.2) Pourquoi Syndie est important ? 16:48 <vulpine> <void> jrandom : attends 16:48 <cervantes> (parce que tu dis que ça l’est) 16:48 * jrandom attend 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> la note d’état indique qu’un avatar peut être attaché à un message, sinon un avatar par défaut sera utilisé 16:49 <vulpine> <void> mais si une personne veut avoir plusieurs avatars prédéfinis au lieu d’un seul « par défaut » ? 16:49 <jrandom> ouaip, l’auteur peut inclure un avatar par défaut dans les métadonnées de son propre canal 16:49 <vulpine> <void> joindre l’autre à chaque fois ne sera pas efficace 16:49 <jrandom> bonne question void — passons à ce code de script dans les notes 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys affichera toutes les identités avec lesquelles tu peux signer le message en disant que tu es cette personne, tandis que "authenticate 0" choisit une identité avec laquelle signer 16:51 <jrandom> donc, cette identité a son propre canal, et ce canal a ses propres métadonnées, qui peuvent inclure un avatar 16:51 <vulpine> <void> hmm, une identité distincte signifie une paire de clés distincte ? 16:51 <jrandom> oui 16:51 <vulpine> <void> et si une personne veut avoir plusieurs avatars sur une seule identité ? 16:52 <jrandom> elle a un avatar par défaut dans les métadonnées de son canal, et elle peut le remplacer au cas par cas par message 16:52 <kostya213> valeur discutable 16:52 <vulpine> <void> plusieurs avatars « par défaut » parmi lesquels il peut choisir 16:52 <vulpine> <void> ou je chipote là ? :) 16:53 <jrandom> ah, je vois ce que tu veux dire. non, pas pris en charge au début 16:53 <jrandom> peut-être plus tard 16:53 <vulpine> <void> c’est vrai kostya213, laisse tomber alors 16:53 <vulpine> <void> :) 16:53 <jrandom> (mais les avatars seront très limités en taille, donc ce ne devrait pas être un gros souci de les inclure) 16:53 <vulpine> * Complication pense que l’ajout d’avatars par message pourrait être codé assez facilement 16:53 <vulpine> <void> alors, 3.1) Qu’est-ce que Syndie ? 16:53 <vulpine> <Complication> (à terme) 16:54 <vulpine> * cervantes recolle les serveurs irc ensemble 16:54 <vulpine> <void> Complication : jrandom vient juste de dire qu’il va déjà le faire :) 16:54 <jrandom> (les avatars par message seront dans la base, complication ; l’idée d’avoir de nombreux « par défaut » à choisir, en le sélectionnant en disant "use avatar 1" dans un message plutôt qu’en incluant l’avatar lui-même) 16:54 <vulpine> <Complication> latence, latence… 16:54 <jrandom> ok, autre chose pour 3.1 ? 16:54 <jrandom> sinon, passons à 3.2 16:55 <vulpine> <void> je pense que c’est tout 16:55 <jrandom> wr0d. 16:56 <jrandom> mis à part la pique de cervantes, quelqu’un a des questions/commentaires/inquiétudes à propos du « pourquoi » ? 16:56 <jrandom> (euh, "concerns") 16:58 <vulpine> <Complication> cervantes : as-tu nettoyé la surface avec de l’alcool avant d’appliquer la colle sur l’ircd ? ;) 16:58 <kostya213> à mon avis Syndie n’a pas besoin de justification, sa valeur devrait être évidente pour quiconque s’intéresse déjà aux réseaux d’anonymisation 16:58 <kostya213> et conscient des dangers de la centralisation de l’information 16:59 <vulpine> <Complication> (republier, merci d’ignorer si c’est arrivé au serveur) 16:59 <vulpine> * Complication pense que Syndie est important parce que Monsieur Tout-le-monde qui fait tourner phpBB se ferait compromettre trop vite, et Monsieur Tout-le-monde qui utilise $random_blogging_tool s’en retrouverait compromis aussi 16:59 <vulpine> <Complication> (même si la probabilité peut varier) 16:59 <vulpine> <void> en effet 16:59 <jrandom> ouaip, sans parler de quiconque est confronté à de vrais adversaires hostiles (pas forcément au niveau étatique) 17:00 <jrandom> ok, cool, je voulais juste vérifier ça avec vous 17:00 <jrandom> autre chose sur 3.2, ou on passe à 3.3) quand pourrons-nous utiliser Syndie ? 17:01 <vulpine> <void> eh bien, essentiellement c’est un outil de forum/blogging/e-mail/communication basé sur des primitives cryptographiques et indépendant de la couche de transport 17:01 <vulpine> <Complication> …et dans le scénario où l’adversaire de Monsieur Tout-le-monde lancerait des attaques par intersection, toute personne faisant tourner un eepsite de n’importe quel type finirait par se faire compromettre (sauf dans un réseau énorme) 17:01 <kostya213> ce sera peut-être plus difficile à vendre à ceux qui ne voient pas de valeur immédiate dans la confidentialité/l’anonymat 17:01 <jrandom> kostya213 : ouaip, mais on pourra peut-être sortir quelques astuces, comme la possibilité de naviguer hors-ligne en toute sécurité 17:02 <vulpine> <Complication> Ils pourraient apprécier la sécurité malgré tout 17:02 <jrandom> (par ex. un lecteur rss hors-ligne qui récupère aussi l’ensemble des pages référencées, pas seulement le résumé rss) 17:02 <vulpine> <void> donc oui, je ne vois pas pourquoi ça a besoin d’être justifié :) 17:02 <vulpine> <void> kostya213 : ils n’ont pas besoin d’être anonymes pour utiliser Syndie 17:02 <cervantes> quand pourrons-nous utiliser Syndie ou quand Syndie sera-t-il utilisable ? 17:02 <jrandom> bien dit, void :) 17:03 <cervantes> pour l’interface texte, j’imagine qu’il faudra une bonne dose de documentation d’utilisation 17:03 <jrandom> cervantes : à l’heure actuelle, Syndie est fonctionnel (tu peux créer des messages, gérer des canaux, lire des messages, répondre, etc.) 17:03 <kostya213> jrandom : comment Syndie gère-t-il la redondance ? quelle est sa résilience face à la disparition de contenu ? 17:03 <cervantes> (avant que ce soit utilisable) 17:03 <jrandom> cervantes : il y a des menus intégrés avec chaque commande documentée (au moins minimalement) 17:04 <cervantes> cool, des plans pour quelques exemples de cas d’usage ? 17:04 <jrandom> kostya213 : Syndie opère à la couche contenu — la redondance est gérée par autre chose. si tu publies sur usenet, c’est répliqué sur usenet (par exemple) 17:04 <cervantes> je pense que l’astuce sera d’apprendre comment tout ça s’assemble en scripts 17:04 <vulpine> <void> kostya213 : ça dépasse le cadre de Syndie, ça dépend du mécanisme de transport 17:04 <vulpine> <void> malheureusement 17:04 <jrandom> bonne idée cervantes 17:05 <jrandom> la première version de Syndie inclura un système de réplication http comme l’ancien/l’existant Syndie 17:05 <jrandom> cervantes : peut-être que certains bêta-testeurs pourront assembler leurs scripts préférés pour qu’on les diffuse :) 17:05 <modulus> mmm, c’est une appli console ? 17:05 <jrandom> modulus : oui, la première appli en mode texte 17:06 <modulus> excellent ! 17:06 <cervantes> jrandom : à condition que les bêta-testeurs arrivent à comprendre comment l’utiliser ;-) 17:06 <jrandom> hehe 17:06 * jrandom a envisagé curses/etc., ainsi qu’un mode uniquement cli, mais une interface texte interactive et scriptable est probablement la plus simple et la plus utile 17:07 <jrandom> (sans gui, donc) 17:07 <cervantes> modulus : tu vois, jrandom a écouté tes retours incessants :) 17:07 <vulpine> <Complication> si les gens le veulent, ils pourront probablement construire des interfaces textuelles plus interactives par-dessus 17:07 <jrandom> ouaip, certainement 17:08 <jrandom> (le code est conçu pour faciliter l’intégration avec un client irc, comme pircbot) 17:08 <modulus> cervantes : hehe 17:09 <modulus> j’imagine qu’on pourrait aussi mettre une gui par-dessus d’ailleurs, si ça marche à peu près comme je l’imagine 17:09 <modulus> même si ce serait bien plus de boulot. 17:09 * kostya213 attend le plugin emacs 17:09 <modulus> hahaha 17:09 <jrandom> heh 17:09 <modulus> en fait, un mode emacs n’est pas une si mauvaise idée, ça attirerait peut-être plus de cinglés. 17:10 <cervantes> appuie sur ctrl-alt-shift-break-uparrow-num7-b pour choisir ton identité 17:10 * jrandom laissera ça aux adeptes d’ELisp à bidouiller ;) 17:10 <kostya213> sans vouloir offenser, je ne suis pas sûr que ce projet ait besoin d’attirer plus de cinglés 17:10 <vulpine> <Complication> ces cinglés-là coderaient aussi ? 17:11 <jrandom> espérons-le, complication 17:11 <jrandom> ok, avec un peu de chance 3.3) explique un peu ce qui arrive 17:11 <jrandom> quant au moment, eh bien on verra, mais j’espère "bientôt" ;) 17:12 <jrandom> ok, quelqu’un a autre chose pour 3.3) ? 17:12 <vulpine> * Complication accueillerait volontiers quelques hordes de ces cinglés alors :D 17:12 <cervantes> il y a coder, et puis il y a écrire du perl obscurci interprété en tcl 17:12 <kostya213> un plugin pour FUSE pourrait aussi être utile 17:13 <jrandom> ouaip 17:13 <jrandom> ok, passons à 4) la crypto pour Syndie 17:13 <jrandom> quelqu’un a des commentaires sur ces questions ? 17:14 <vulpine> <Complication> J’aimerais, mais je ne suis pas compétent pour estimer la robustesse de ces chiffrements/hachages/tailles de clés 17:15 <vulpine> <void> quelle longueur font les signatures elgamal/rsa ? 4 kbits pour une clé 2 kbits ? 17:15 <vulpine> * Complication laisse entièrement cette discussion aux autres 17:15 <jrandom> je ne sais pas de tête 17:15 <vulpine> <void> par rapport à dsa ? 17:16 <jrandom> (quoique ecc a l’air tout joli et tout petit) 17:16 <modulus> Les signatures ElGamal sont difficiles et longues. comme l’a découvert l’équipe de gnupg. 17:16 <jrandom> ouaip, même si certaines de ces astuces étaient liées à la réutilisation de clés 17:16 <vulpine> <void> ah, d’accord 17:16 <vulpine> <void> ouais, c’est vrai 17:16 <tethra> modulus : si elles sont difficiles et longues, il y a un site fétichiste pour ça 17:17 <jrandom> ok, ce point était surtout un avertissement et un appel à commentaires quand vous aurez des idées 17:17 <cervantes> ne serait-il pas possible d’implémenter des chiffrements « plugables » — quand une meilleure méthode de création de clés sera standardisée, on pourra l’ajouter à Syndie et les nouveaux messages commenceront à l’utiliser, tout en conservant les méthodes obsolètes pour les anciens messages 17:17 <tethra> (désolé) 17:17 <jrandom> cervantes : ça inclut un préfixe DSA:, donc un préfixe Elg: fonctionnerait 17:17 <modulus> utilisez-vous du dsa limité à 1024 ou pas ? 17:18 <modulus> et quel hachage ? sha1 ou des révisions d’ordre supérieur ? 17:18 <cervantes> donc en fait tu veux surtout que Syndie démarre sur de bonnes bases 17:18 <jrandom> dsa n’est qu’en 1024 bits (il y a des propositions dsa2 pour plus long, mais elles ne sont pas encore standardisées) 17:18 <jrandom> et oui, dsa nécessite sha1 17:18 <modulus> hmm, d’après ce que je comprends, elles étaient assez solides avant la normalisation. 17:18 <kostya213> cervantes a raison, avoir le contenu de Syndie avec des chiffrements figés offre une mauvaise confidentialité persistante, on ne sait jamais quand un algo va partir en vrille 17:18 <modulus> mais je ne suis pas le processus d’assez près, tu as probablement raison 17:19 <jrandom> kostya213 : mais le choix est mauvais pour l’anonymat en crypto, donc nous devrions avoir des valeurs fixes quand c’est possible 17:19 <jrandom> (mauvais pour l’anonymat) 17:19 <vulpine> <void> sais-tu pourquoi davantage de gens/protocoles n’utilisent pas ecc, d’ailleurs ? ils ont peur du manque de recherche, ou juste inquiets pour la compatibilité ? 17:19 <modulus> brevets. 17:20 <jrandom> brevets et FUD, et aussi quelques préoccupations d’implémentation 17:20 <vulpine> <void> ah, oui modulus 17:20 <modulus> au fait, y a-t-il une bonne raison de choisir dsa plutôt que rsa-sha512 par exemple ? 17:20 <tethra> brevets et FUD et l’État (oh là là) 17:20 <modulus> je ne cherche pas à être pénible, c’est juste que gpg par exemple est parti dans cette direction, entre autres. 17:20 <jrandom> je n’ai pas examiné cette option depuis des années modulus 17:21 <modulus> dsa est évidemment une norme, ce qui plaide pour lui, mais les clés sont petites et les hachages faibles. ceci dit, je ne pense pas que ce sera probablement le maillon le plus faible ;-) 17:23 <cervantes> je ne proposerais pas un « choix » — mais les nouvelles versions de Syndie embarqueraient des chiffrements (obligatoires) de plus en plus sûrs 17:23 <vulpine> <Complication> Laisser un peu de marge dans les structures pour de futurs changements me paraît raisonnable, quelle que soit la crypto actuelle qui s’avère la meilleure, je pense 17:23 <jrandom> ouaip, mais cela implique une rétrocompatibilité vers des versions plus faibles/anciennes pour interopérer 17:23 <jrandom> mais ok, on s’en débrouillera 17:24 <jrandom> ok, passons à 5) ??? 17:24 <jrandom> quelqu’un a autre chose à soulever pour la réunion ? 17:25 <cervantes> ne pas pouvoir lire les derniers messages de ta source préférée est une bonne incitation pour s’assurer que tout le monde reste à jour 17:25 <jrandom> dans une certaine mesure 17:26 <cervantes> no=not 17:26 <jrandom> (ouaip, c’est une incitation, mais les gens sont paresseux/pas intéressés par « mettre à jour des logiciels », etc) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> j’imagine que c’est leur problème toutefois 17:27 <jrandom> tout à fait 17:27 <kostya213> au moins, l’implémentation i2p peut avoir des mises à jour indolores 17:28 <jrandom> certainement 17:28 <cervantes> pour ??? — désolé pour la connectivité irc — le FAI devrait rétablir l’un de ses principaux opérateurs réseau "dès que possible" 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> Sur le sujet ???, je peux peut-être ajouter que la deuxième partie (plus étendue) des modifications NTP est presque fonctionnelle, et j’espère la committer pour tests bientôt 17:29 * cervantes prend une pincée de sel 17:29 <kostya213> quels sont les plans à court terme pour le développement du router ? la feuille de route est-elle exacte ? 17:29 <jrandom> wikked complication 17:29 <vulpine> <Complication> Son objectif est de remettre en question les serveurs NTP en se basant sur les décalages d’horloge des pairs 17:29 <jrandom> kostya213 : stabilisation jusqu’à la sortie de Syndie 17:30 <jrandom> (de mon point de vue) 17:30 <vulpine> <Complication> (et éviter de prendre des mesures susceptibles de nuire à la connectivité) 17:31 <cervantes> super 17:32 <jrandom> ok, autre chose pour la réunion ? 17:34 * jrandom se prépare 17:34 * jrandom *baf* clôt la réunion