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

15:26 <jrandom> 0) salut 15:26 <jrandom> 1) 0.6.1.7 et état du réseau 15:26 <jrandom> 2) Échecs de tunnel expérimentaux 15:26 <jrandom> 3) SSU et NATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) salut 15:26 * jrandom agite la main 15:26 <jrandom> les notes d’état hebdomadaires sont publiées sur http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros a lu les notes 15:27 * jrandom est en retard, donc je vous laisse un moment pour lire :) 15:29 <jrandom> ok, autant passer à 1) 0.6.1.7 et état du réseau 15:29 <@cervantes> *tousse* 15:29 <jrandom> Je n’ai pas grand-chose à ajouter au-delà de ce qui est dans le mail sur ce point. quelqu’un a d’autres commentaires/questions/idées ? 15:30 <Pseudonym> il semble que faire des optimisations de performance avant de changer l’algo de création de tunnel soit peut-être à l’envers 15:30 <gott> I am getting a lot of "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> la latence des tunnels est bien plus basse, je ne sais pas si vous avez fait des changements ou si mon FAI est soudainement meilleur. 15:30 <gott> depuis l’I2PTunnel Webmanager 15:31 <jrandom> gott: ça suggère de mauvaises requêtes HTTP, ou des choses que l’eepproxy ne pouvait pas comprendre 15:31 <jrandom> modulus: cool, on a fait pas mal de choses pour essayer d’améliorer tout ça 15:31 <jrandom> Pseudonym: eh bien, jusqu’ici la création de tunnel n’a pas été notre goulet d’étranglement - c’était des choses à un niveau bien plus élevé 15:32 <jrandom> d’un autre côté, les améliorations des dernières révisions ont mis en évidence des problèmes plus bas 15:32 <Pseudonym> oh, donc l’optimisation concernait d’autres parties du code ? 15:32 <Pseudonym> cool 15:33 <jrandom> oui, au niveau SSU, ainsi qu’au niveau du fonctionnement des tunnel. la création de tunnel n’est pas une opération sensible en termes de performances [sauf quand elle l’est ;] 15:34 <jrandom> Je fais des tests de charge en direct sur le réseau, en collectant des stats de charge non anonymes de différents pairs pour essayer d’affiner 15:34 <ailouros> Je me demande pourquoi parfois je vois plus de tunnels que ceux configurés pour une destination (par ex. eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> donc, ces prochains jours, quand vous verrez le router 7xgV transférer beaucoup de données, eh bien, n’y prêtez pas attention ;) 15:35 <jrandom> ailouros: quand la création de tunnel prend du temps, il en construit en plus, au cas où. 15:35 <jrandom> zzz décrit aussi quelques bizarreries à ce sujet, et un patch est en cours pour améliorer un peu les choses 15:35 <ailouros> Je vois.. mais alors pourquoi expirent-ils tous en même temps ? 15:35 <@cervantes> jrandom: par curiosité, quand as-tu commencé ces tests ? 15:35 <jrandom> cervantes: il y a quelques jours 15:36 <@cervantes> ah cool, ce n’est donc _pas_ ça ;-) 15:36 <jrandom> je ne sais pas ailouros, ça dépend de quelques conditions. Mais il y a des... *tousse* bizarreries dans le code de création de tunnel, que j’évite de toucher puisqu’il est en cours de réécriture pour 0.6.2 15:38 <ailouros> Je vois. Je pensais que c’était une question de stratégie... Je préférerais que les tunnel meurent à des moments différents sauf s’il y a une bonne raison de ne pas le faire 15:38 <ailouros> c’est-à-dire, des créations de tunnel décalées 15:39 <jrandom> oui, il y aura une meilleure randomisation pour 0.6.2, et le patch de zzz ajoute aussi un peu de randomisation pour la révision actuelle 15:40 <+Complication> Je me demande pourquoi une instance autrement saine d’i2phex... déciderait de re-hasher les fichiers une fois sur deux quand je la démarre ? 15:40 <jrandom> aucune idée 15:40 <+Complication> Une configuration endommagée semble la cause la plus probable pour l’instant, mais je n’ai pas encore supprimé ma config. 15:40 <jrandom> peut-être des horodatages décalés ? 15:42 <+Complication> Non, ils semblent corrects aussi 15:42 * jrandom ne sait pas. n’a jamais regardé cette partie du cod de phex 15:42 <jrandom> euh, code 15:42 <+Complication> Je vais voir si supprimer les anciens fichiers de config lui fait du bien 15:42 <jrandom> cool 15:43 <jrandom> ok, autre chose sur 1) État du réseau / 0.6.1.7 ? 15:43 <jrandom> sinon, on passe à 2) Échecs de tunnel expérimentaux 15:44 <jrandom> on en a déjà un peu parlé, et il y a plus d’infos dans les notes et sur zzz.i2p 15:44 <jrandom> zzz : as-tu quelque chose à ajouter/soulever ? 15:46 <jrandom> sinon, passons à 3) SSU et NATs 15:46 <jrandom> bar: quelque chose à ajouter ? 15:46 <+bar> non, je n’ai rien d’autre à ajouter que ce qui est dans le mail 15:47 <jrandom> cool, oui je dois encore répondre à certains détails - je pense que notre retransmission prendra déjà en charge certains des points que tu soulèves 15:48 <jrandom> l’astuce sera de détecter quelle situation est en jeu, pour qu’on puisse automatiser la bonne procédure (ou informer l’utilisateur qu’il est fichu) 15:48 <+bar> tout en temps voulu, pas de précipitation 15:49 <+bar> oui, j’ai suggéré un réglage manuel utilisateur pour contourner ce problème pour l’instant, c’est peut-être impossible, mais on pourra en discuter plus tard 15:50 <jrandom> oui, les dérogations manuelles aideront, mais mon expérience avec les anciennes révisions d’i2p était que tout le monde (*tout le monde*) bousillait ça ;) donc l’automatisation est préférable 15:50 <jrandom> (tout le monde, moi compris ;) 15:52 <+bar> d’accord 15:52 <ailouros> lol si je l’ai fait aussi, alors il y avait quelque chose qui clochait dans la doc, car je l’ai suivie point par point :D 15:53 <+bar> en attendant, je vais passer un peu de temps à étudier le peer testing 15:53 <jrandom> cool, merci bar ! 15:54 <+bar> (peut-être que je pourrais aussi générer du spam inutile à ce sujet :) 15:54 <jrandom> :) 15:55 <jrandom> ok, s’il n’y a rien d’autre sur 3), passons à 4) Syndie 15:56 <jrandom> il y a eu beaucoup de progrès sur ce front dernièrement, avec des refontes d’UI assez substantielles depuis la sortie de 0.6.1.7 15:57 <jrandom> il y a aussi une nouvelle installation/build autonome, bien que comme nous avons tous i2p installé, nous n’avons pas besoin d’une version séparée 15:57 <ailouros> Je trouve que la mise en page de 6.1.7 est plus difficile à utiliser que celle de 6.1.6 15:58 <jrandom> hmm, fais-tu tourner syndie en mode mono-utilisateur ? et/ou utilises-tu la dernière build CVS ou la build officielle 0.6.1.7 ? 15:58 <ailouros> officielle 0.6.1.7, mono-utilisateur 15:58 <jrandom> fais-tu partie des partisans de l’interface de type blog, par opposition à la navigation en fils de discussion ? 15:58 <ailouros> Non, même si je ne sais pas vraiment laquelle est celle façon blog 15:58 <ailouros> personnellement je préférerais une navigation en fils 15:59 <ailouros> (et aussi un code couleur des nouveaux messages dans la vue en fil) 15:59 <+Complication> CVS relativement récent, mono-utilisateur 15:59 <+Complication> J’ai trouvé une petite bizarrerie (qui, je pense, pourrait ne pas être voulue) 15:59 <jrandom> ah, il y a eu beaucoup de progrès sur ce point dans le CVS, ailouros 15:59 <ailouros> super :) 16:00 <jrandom> nous avons aussi un nouvel affichage en fil, utilisant la traversée complète d’une seule branche suggérée par cervantes, plutôt que de toutes les branches 16:00 <@cervantes> ces changements sont-ils poussés sur syndiemedia.i2p.net ? 16:00 <+bla> Serait-ce une bonne idée d’afficher quelques exemples par défaut pour l’emplacement dans http://localhost:7657/syndie/syndicate.jsp ? 16:00 <jrandom> syndiemedia.i2p.net est sur le head de CVS, oui 16:00 <+Complication> Quand tu as ouvert un fil, et que tu es en train de lire ses messages... puis tu choisis d’appliquer un filtre auquel aucun message ne correspond (par ex. ouvrir le fil "Syndie threading", appliquer le filtre "i2p.i2phex")... 16:00 <jrandom> oui, peut-être bla. les nouvelles installations auront les trois valeurs par défaut, mais des exemples seraient bien 16:01 <@cervantes> (l’arborescence réelle du fil doit aussi s’ouvrir complètement toutefois) 16:01 <+Complication> ...il semble laisser les messages actuels affichés, comme s’ils correspondaient ou quelque chose du genre... 16:01 <+Complication> Même si j’ai bel et bien cliqué sur le bouton "Go". 16:01 <@cervantes> Complication: oui, j’ai trouvé ça déroutant moi aussi 16:02 <jrandom> hmm Complication, l’idée générale était de te laisser naviguer tout en regardant un message, mais ce serait peut-être mieux de ne plus afficher les messages 16:02 <jrandom> cervantes: ah, oui l’étendre jusqu’à la feuille serait bien, et devrait être trivial à faire 16:02 <+Complication> Je viens de le remarquer, et comme ça saute aux yeux, j’ai pensé le signaler 16:02 <@cervantes> (ou le rendre plus évident qu’il n’y a aucune correspondance) 16:03 <jrandom> eh bien, la navigation de fil dit *aucune correspondance* :) 16:03 <ailouros> peut-être qu’il cherche un briquet 16:03 <jrandom> !thwap 16:03 <@cervantes> (ou le rendre encore plus évident qu’il n’y a aucune correspondance) 16:03 <jrandom> <blink>Aucune correspondance</blink> 16:03 <+Complication> Oups :) 16:04 <tethra> on dirait que ton !thwap a touché spaetz__ à la place, jr ! 16:04 <+Complication> C’est vrai, parfois le navigateur de fils paraît très éloigné :) 16:04 <jrandom> oui, on expérimente avec du CSS pour le faire flotter sur le côté, en option 16:05 <@cervantes> avec la prise en charge des thèmes tu pourrais avoir le fil en haut en bas gauche droite etc 16:05 <@cervantes> ah comme jr a dit 16:05 <+Complication> Le lien "Threads" y amène assez vite, toutefois 16:05 <+Complication> ...si c’est actuellement dans la zone visible. 16:06 <+Complication> Et ceux qui ont l’habitude de naviguer au clavier peuvent naturellement appuyer sur "Fin" 16:06 <jrandom> bien sûr, ce truc est vraiment simple à modifier (comme vous pouvez le voir avec les changements rapides dans le CVS :), donc si quelqu’un a des suggestions (ou des maquettes - html / png / etc), n’hésitez pas à les poster quand vous voulez 16:07 <jrandom> Je pense que nous aurons une page d’aperçu principale type blog dans les prochains jours dans cvs 16:08 <jrandom> ok, il y a plein d’autres choses en cours avec syndie, donc passez sur http://localhost:7657/syndie/ pour plus d’infos :) 16:08 <jrandom> quelqu’un a autre chose à soulever là-dessus, ou on passe à 5) ??? 16:09 <zzz> salut, je viens d’arriver. sur 2), je cherche des testeurs pour mon patch. 16:10 <zzz> Mes résultats sont des améliorations du job lag et de la fiabilité, et une réduction des blocages du router. Donc j’espère que d’autres essaieront. 16:10 <ailouros> ça semble assez bon. Qu’est-ce que je dois faire ? 16:11 <jrandom> salut zzz, ok cool, je vais le malmener un peu ici aussi. Il a beaucoup de composants différents, donc ça vaudrait peut-être le coup de le découper en morceaux, mais ça a l’air bon et c’est en bonne voie pour 0.6.1.8 16:11 <ailouros> (le uptime moyen est d’environ 10 h ici :( 16:11 <zzz> Si tu as le code source et ant, applique simplement le patch - ou je peux mettre en ligne un i2pupdate.zip si tu veux 16:12 <zzz> jrandom je vais travailler à le découper 16:12 <ailouros> Je prends l’update, merci 16:13 <zzz> ailouros je le mettrai sur zzz.i2p d’ici une heure - merci 16:13 <jrandom> zzz : ne t’en fais pas à moins d’avoir du temps libre... je peux lire le diff :) 16:13 <ailouros> merci 16:14 <zzz> jrandom OK. Il y a quelques bricoles qui peuvent facilement être retirées par toi ou moi. 16:16 <ailouros> Je suppose qu’on en est à 5) ??? maintenant ? 16:16 <zzz> jrandom autre sujet : des OOM du router avec i2phex et des problèmes possibles avec SAM 16:16 <jrandom> oui, ailouros 16:16 <jrandom> ah oui zzz, ce serait super de trouver ce qui se passe avec SAM 16:17 <ailouros> j346, as-tu eu l’occasion de jeter un œil à mon appli ? 16:17 <jrandom> Ce qui serait top, c’est que quelqu’un prenne en charge la maintenance du SAM bridge, car je n’y ai pas fait de travail substantiel, et human n’est pas passé depuis un moment. 16:19 <jrandom> pas encore ailouros, malheureusement. J’étais un peu incertain de son fonctionnement, donc je dois d’abord lire le code source 16:20 <ailouros> n’hésite pas à demander 16:20 <ailouros> (et bonne chance pour le voyage à travers le source, c’est une bonne définition du mot "bazar") 16:20 <jrandom> héhé 16:21 <zzz> correction : mon expérience a été des OOM en utilisant i2p-bt, pas i2phex. Ça arrive après environ 24 heures avec un i2p-bt et en quelques heures en en faisant tourner deux i2p-bt 16:22 <+Complication> Les miens sont arrivés après des stress-tests nocturnes. 16:22 <+Complication> (pendant lesquels, soit dit en passant, j’ai vu des moyennes sur 5 minutes de 50 Ko/s) 16:22 <bar_> pourrais-tu me rappeler ce qu’est/fait ton appli, ailouros ? Ma mémoire est bonne mais courte... 16:22 <+Complication> En entrée, je précise. 16:22 <+Complication> La sortie était limitée à 35 Ko/s 16:22 <@cervantes> Complication: Je n’ai jamais entendu appeler ça des stress-tests nocturnes avant... 16:22 <jrandom> sympa, Complication 16:23 <+Complication> cervantes: eh bien, on pourrait appeler ça du mégaleeching semi-quotidien alors :P 16:23 <ailouros> bar_: c’est une preuve de concept fonctionnelle pour une appli de partage de fichiers distribuée qui partage des blocs communs entre différents fichiers (comme suggéré par polecat) 16:23 <bar_> ah, d’accord, merci ailouros 16:24 <tethra> cervantes: heheheh ;) 16:24 <ailouros> de rien (si quelqu’un veut récupérer le source, c’est en C/C++) 16:25 <+polecat> ailouros: Fais attention, la probabilité que deux blocs binaires soient identiques est suffisamment faible, je parle surtout de théorie pure qui serait peu utile en pratique. 16:25 <ailouros> polecat, je suis d’accord. Mon meilleur pari, c’est que ça devient utile quand tu obtiens différentes versions des mêmes fichiers 16:25 <ailouros> par exemple, un film qui a un bloc corrompu 16:25 <+polecat> Tu pourrais transférer des blocs de zéros à la vitesse de l’éclair ! ("Le prochain bloc est des zéros" "oh, je l’ai déjà" "le prochain bloc est des zéros" "oh, je l’ai déjà") 16:26 <ailouros> ou une archive d’autres fichiers zip 16:26 <jrandom> ou, par ex., des tags ID3 modifiés, etc. 16:26 <ailouros> exactement 16:26 <+polecat> C’est vrai. Mais une façon simple de "réparer" un film avec un bloc corrompu est de dire à bittorrent de le retélécharger par-dessus. La plupart des clients préserveront les blocs dont les hashes sont identiques et écraseront ceux qui sont différents. 16:26 <jrandom> les archives de fichiers ne fonctionneront probablement pas toutefois, puisqu’il faudrait qu’elles se coupent aux limites de fichiers 16:27 <ailouros> j636, c’est pourquoi je veux implémenter l’idée de LBFS de découper sur des marques de données et non sur des tailles de bloc fixes 16:27 <@cervantes> la communauté DC utilisait cette méthode, en partageant des distributions de fichiers en rarsets 16:27 <+polecat> Ce qui pourrait être utile, ce serait de faire un algorithme général de correction d’erreurs binaire, puis de l’implémenter à grande échelle. Tous les blocs pourraient être "corrigés" les uns vers les autres, et tu n’aurais qu’à transmettre les données de correction, qui pourraient être plus petites que le bloc lui-même. 16:29 <@cervantes> et ensuite les recherches sont basées sur les hashes Tiger de ces parties RAR 16:29 <+Complication> Bonne idée... ça a l’air difficile toutefois :) 16:29 <+polecat> Mais juste un équivalent hash-pour-hash... tu ne trouverais jamais deux blocs identiques ! 16:29 <ailouros> cervantes, c’est quoi un "rarset" ? :D (à part un "RAR file", hein) 16:29 <+polecat> À moins que les deux côtés aient déjà le fichier, dont un corrompu. 16:29 <ailouros> polecat, hein ? 16:29 <@cervantes> ailouros: une archive RAR découpée, avec des fichiers de parité si nécessaire 16:30 <ailouros> cervantes: Je ne comprends pas l’avantage de faire ça 16:31 <@cervantes> son principal bénéfice était d’ajouter du pseudo-téléchargement multi-source à DC 16:32 <ailouros> eh bien, ça fait partie du mécanisme de partage de blocs entre fichiers, non ? 16:34 <ailouros> polecat: concernant le réécriture par bittorrent des fichiers endommagés, ce que ça ne t’apporte pas, c’est quand tu essaies d’obtenir plusieurs versions à la fois 16:35 <@cervantes> ton client ne fait correspondre/télécharge que des parties valides, si tu as des fichiers de parité tu peux aussi récupérer des parties endommagées 16:35 <ailouros> avec mon système il n’y a pas de parties endommagées (les fichiers ne sont assemblés que lorsque les blocs composant sont téléchargés et revérifiés) 16:36 <@cervantes> des choses que bittorrent fait par défaut, sauf que tu ne peux pas chercher spécifiquement des parties individuelles 16:36 <+polecat> Des versions multiples n’auront probablement pas un seul bit en commun toutefois... ce qui est bien stupide. Un type décide de réencoder le film en format timbre-poste et lui donne le même nom. 16:37 <+polecat> Ou un autre prend des données aléatoires et les nomme d’après le fichier que tu veux télécharger. 16:37 <ailouros> lol c’est vrai 16:37 <@cervantes> exactement et les releases en rarset sont immunisées contre ça... 16:37 <ailouros> mais garde à l’esprit que les fichiers d’autres réseaux (emule, kazaa, etc.) arrivent souvent corrompus 16:38 <+polecat> les releases en rarset ne sont pas immunisées... 16:38 <+polecat> Tu dois toujours déterminer quel rarset est le bon. 16:38 <ailouros> cervantes, comment les rarsets sont-ils immunisés contre un idiot qui publie n’importe quoi ? 16:38 <@cervantes> (à condition d’avoir une source fiable) 16:39 <@cervantes> parce qu’un groupe de release publie des hashes/informations de distribution 16:39 <ailouros> hahaha c’est facile :D 16:39 <@cervantes> et les trucs sont marqués comme nuked si c’est de mauvaise qualité, les gens les retirent de leurs partages 16:40 <ailouros> cervantes, ça, mon jouet le fait déjà 16:40 <@cervantes> cool 16:40 <ailouros> tu obtiens le descripteur de fichier d’une source de confiance, tu récupères le fichier en multi-get illico 16:41 <@cervantes> ça a l’air bien ;-) 16:41 <ailouros> tu ne peux pas rechercher des fichiers, mais tu peux parcourir le répertoire partagé de chaque utilisateur, donc tu peux utiliser un robot web et mettre les résultats en cache 16:42 <ailouros> même si je pourrais ajouter une fonction de recherche à l’avenir si jugé nécessaire 16:44 <ailouros> Je crois que mon jouet, correctement développé en appli, peut offrir le cache et la résilience que les gens de freenet essaient d’offrir 16:44 <ailouros> c’est-à-dire distribution de contenu statique et mise en cache 16:45 <ailouros> tu lis mon blog, tu le mets en cache et tu l’offres à d’autres personnes quand elles le veulent. tu ne fais rien de plus que laisser le contenu là 16:45 <ailouros> tu n’aimes pas le contenu ? supprime-le et c’est réglé 16:45 <jrandom> hmm, donc tu le vois comme un backing store qui pourrait être utilisé pour syndie? 16:46 <ailouros> il PEUT être utilisé comme backing store 16:46 <ailouros> tel qu’il est maintenant, tu pourrais même l’utiliser à la place de jetty, dans les installations par défaut d’i2p 16:46 <jrandom> par ex. pièces jointes / liens vers [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (bon, avec deux ou trois changements mineurs :D ) 16:46 <jrandom> heh 16:47 <jrandom> ok, oui, je ne comprends définitivement pas comment clunk fonctionne... tu veux en poster à ce sujet dans syndie, ou monter une eepsite ? :) 16:47 <ailouros> les hashes de fichier sont téléchargés sur demande du fichier, et ces hashes sont automatiquement téléchargés en fichier complet 16:48 <jrandom> d’accord, mais "down"loadé, c’est la question du d’où vers où, etc. une description globale de l’architecture réseau serait utile 16:48 <ailouros> Je vais d’abord écrire une doc correcte, puis la publier quelque part 16:48 <jrandom> r0x0r, merci 16:48 <ailouros> téléchargé depuis l’endroit d’où tu as obtenu le hash 16:48 <ailouros> plus tous ceux qui partagent ces blocs 16:49 <ailouros> pense à go!zilla et Download Accelerator :) 16:49 <jrandom> Je pense que tu ne mesures pas à quel point je suis confus 16:49 <ailouros> mais de façon transparente et au sein d’i2p 16:49 <ailouros> lol sans doute :D 16:50 <jrandom> une explication très, très basique du style "tu fais tourner un client clunk, tu télécharges depuis un serveur clunk, tu obtiens des infos sur des pairs clunk", etc 16:50 <jrandom> Est-ce que j’utilise un navigateur web pour interroger un client clunk ? ou un serveur ? ou un pair ? 16:51 <jrandom> (voilà à quel point je suis perdu) 16:51 <ailouros> recommençons à 0 :) 16:51 <ailouros> tu utilises ton navigateur web 16:51 <ailouros> tu te connectes à ton client 16:51 <ailouros> tu parcours le répertoire des autres avec ton navigateur 16:51 <ailouros> tu sélectionnes les fichiers à télécharger avec ton navigateur 16:51 <ailouros> ton client fait le sale boulot 16:52 <ailouros> tu récupères le fichier téléchargé 16:52 <ailouros> c’est mieux ? :) 16:52 <jrandom> ok super, merci - donc le "parcourir le répertoire des autres" est fait par ton client qui interroge leur client et répond avec une représentation HTML 16:52 <ailouros> exactement 16:52 <jrandom> (ou tirée de quelque serveur/superpeer/etc) 16:53 <jrandom> cool 16:53 <ailouros> tout le sale boulot (trouver les doublons, les téléchargements multiples, etc.) est fait par ton client (local) de manière transparente 16:54 <ailouros> ce que tu vois, c’est, en gros, un arbre de répertoires et quelques fichiers que tu peux télécharger 16:54 <jrandom> cool 16:55 <ailouros> pour publier tes données, tu donnes ton adresse publique (p2p) 16:55 <ailouros> et pour partager des fichiers tu les copies (ou tu les lies symboliquement (symlink)) dans le répertoire pub/ (ou un sous-répertoire). C’est aussi simple 16:57 * jrandom va creuser davantage le source, et attend plus d’infos :) 16:57 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:57 <bar_> euh... quelle est la différence entre publier et partager, puis-je demander ? est-ce que publier pousse les données vers un datastore ? 16:58 <ailouros> bar_: partager, c’est donner les blocs à télécharger. publier, c’est faire savoir au monde ce que tu partages 16:58 <ailouros> publier est un sous-ensemble de partager 16:58 <bar_> aha, je vois, merci 16:58 <ailouros> par exemple, si tu as la moitié d’un fichier, tu le partages mais tu ne le publies pas 16:59 <jrandom> comment les gens sauraient-ils qu’ils pourraient obtenir ces blocs de toi alors ? 16:59 <ailouros> et tu as un contrôle total sur les fichiers que tu publies (contrairement à emule où chaque fichier téléchargé est publié) 16:59 <ailouros> parce que chaque client envoie périodiquement au réseau des informations sur les blocs qu’il a à offrir 17:00 <jrandom> cool 17:00 <ailouros> envoie au réseau via un serveur (comme maintenant) ou une DHT (future) 17:00 <jrandom> donc c’est mnet-esque, avec un traqueur de blocs 17:00 <ailouros> euh mnet-esque ? 17:01 <jrandom> semblable à la façon dont mnet (mnetproject.org) fonctionne 17:01 * ailouros est en train de lire mnetproject.org 17:02 <ailouros> eh bien, tu n’as que tes espaces personnels, pas d’espaces partagés 17:02 <ailouros> et tu ne PUSH pas des blocs partout 17:02 <jrandom> oui, ce n’est pas exactement comme mnet, mais c’est similaire structurellement 17:03 <jrandom> c’est comme mnet où tout le monde est trop fauché pour faire héberger ses données ;) 17:03 <ailouros> oui 17:03 <ailouros> :D 17:03 <jrandom> ok, quelqu’un a autre chose à soulever ? 17:04 <jrandom> sinon... 17:04 * jrandom conclut 17:04 * jrandom *baf* clôt la réunion