I2P-Entwicklertreffen - 25. Oktober 2005

16:24 <jrandom> 0) hi 16:24 <jrandom> 1) Netzstatus 16:24 <jrandom> 2) Fortuna-Integration 16:24 <jrandom> 3) GCJ-Status 16:24 <jrandom> 4) i2psnark ist zurück 16:24 <jrandom> 5) Mehr zum Bootstrapping 16:24 <jrandom> 6) Virus-Untersuchungen 16:24 <jrandom> 7) ??? 16:24 <jrandom> 0) hi 16:24 * jrandom winkt 16:24 <jrandom> Wöchentliche Statusnotizen veröffentlicht unter @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html 16:25 * susi23 winkt zurück 16:26 <jrandom> lasst uns zu 1) Netzstatus springen 16:26 <jrandom> wie erwähnt, sieht bisher alles ziemlich vernünftig aus. 16:26 <+fox> <Romster> ah, Meeting, sweet 16:27 <jrandom> es kommt auch noch einiges Gutes, daher werden wir später in dieser Woche ein neues Release haben 16:27 <jrandom> hat jemand etwas, das er/sie zu 1) Netzstatus ansprechen möchte? 16:27 <@cervantes> omg 7 Punkte 16:27 <+legion> ja, sieht gut aus :-) 16:27 <jrandom> volle Woche, cervantes :) 16:28 <@cervantes> kann nur gut sein 16:28 <+Complication> Funktioniert relativ gut, sogar dev.i2p – ich kann sogar CVS-Checkouts ziehen ohne EOF-Meldungen. 16:28 <jrandom> schön :) 16:28 <+Complication> Die letzten könnten release-bedingte Überlastungen gewesen sein. 16:28 <+Complication> Kann ich aber nicht sagen. 16:28 <jrandom> dev.i2p läuft auch auf dem neuesten Build-Code (-7), daher wird es hoffentlich deutlich besser laufen als zuvor 16:29 <jrandom> s/dev.i2p/cvs.i2p (etc)/ 16:29 <+legion> forums.i2p scheint auch viel besser zu laufen als vorher :) 16:29 <@cervantes> *räusper* 16:29 <+fox> <Romster> ist i2p sicher, andere beitreten zu lassen usw? 16:29 <+Ragnarok> ok, jetzt muss ich dieses wundersame "cvs checkout that works the first time" ausprobieren 16:30 <+fox> <Romster> da es jetzt keine bekannten Limits gibt 16:30 <@cervantes> das liegt daran, dass alle die i2p-list hämmern, statt im Forum zu posten 16:30 <+legion> hmm, sicher, cervantes? 16:30 <jrandom> Romster: nun, wir wachsen in letzter Zeit ziemlich gut, aber wir sollten mit der öffentlichen Beta bis 0.6.2 warten 16:30 <jrandom> heh cervantes ;) 16:30 <jrandom> psst, Ragnarok, du verschreist es noch! 16:31 <+Ragnarok> wow... es stimmt. Ich bin sprachlos 16:31 <+fox> <Romster> k jrandom 16:31 <jrandom> (boah, mir tränen die Augen von dem Curry, das meine Mitbewohner unten kochen) 16:31 <jrandom> nice one, Ragnarok 16:32 <+fox> <Romster> lol, das ist mal ein starkes Curry 16:32 <jrandom> ok, wenn es zu 1) nichts weiter gibt, können wir schnell zu 2) Fortuna-Integration springen 16:32 <jrandom> (stimmt, Romster) 16:32 <+fox> <shardy> yay für Fortuna-Integration! 16:32 <+fox> <Romster> gehen wir weiter zu 2) :P 16:32 <+fox> <Romster> was ist Fortuna? 16:32 <jrandom> heh, dachte, das würde dir gefallen, shardy :) 16:32 <+fox> <Romster> ich war im letzten Monat etwas hinten dran 16:32 <+Complication> PRNG-Algorithmus, wenn ich mich recht erinnere. 16:33 <+Complication> Angeblich ein guter, steht so geschrieben. :P 16:34 * Complication kennt aber nichts von den inneren Abläufen 16:34 <jrandom> shardy: ich würde mich freuen, wenn du es dir irgendwann mal ansehen könntest 16:34 <+fox> <shardy> natürlich 16:34 <+fox> <shardy> ihr verwendet die GNU-Implementierung? 16:34 <jrandom> Romster/Complication: in der E-Mail sind ein paar Links 16:34 <jrandom> ja, shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java 16:35 <jrandom> (integriert mit http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java ) 16:36 <jrandom> wir weichen jedoch von der reinen gnu-crypto-Implementierung ab, da wir bereits AES256- und SHA256-Code haben (von Cryptix bzw. Bouncycastle) 16:36 <jrandom> ok, jedenfalls sieht das cool aus, da wir wohl seit einem Jahr daran herumbasteln, das reinzubekommen 16:37 <jrandom> (Fortuna-Integration war eines der Hauptprojekte, die smeghead dazu gebracht haben, 'pants' zu bauen ;) 16:37 <jrandom> wenn jemand Fragen/Kommentare/Bedenken dazu hat, bitte an die Liste werfen 16:37 <jrandom> (oder E-Mail, oder Forum, natürlich) 16:38 <+fox> <Romster> ja, wo ist smeghead, er war eine Weile nicht mehr da 16:38 <jrandom> smeghead ist [redacted] und macht [redacted] 16:39 <jrandom> ok, weiter zu 3) GCJ-Status 16:39 <jrandom> i2p läuft auf GCJ! [w00t!] 16:39 <+susi23> gute Arbeit 16:39 <+legion> sweet 16:39 <jrandom> zumindest funktioniert es mit GCJ 4.0.2 auf Linux 2.6.12. Andere Plattformen habe ich nicht ausprobiert 16:40 <jrandom> ja, die GCJ- und GNU-Classpath-Leute haben Wunder vollbracht 16:40 <jrandom> das Bauen war wirklich einfach, die alten statischen Referenzklassen, an die ich mich erinnere, waren nicht nötig 16:41 <+Complication> Klingt recht positiv, angesichts von Sun Javas nicht ganz vollständiger Offenheit (hinsichtlich Distribution, wenn ich mich richtig erinnere). 16:41 <jrandom> es wird jetzt ein Makefile mit I2P ausgeliefert, aber der Einfachheit halber werden wir wahrscheinlich hauptsächlich weiterhin reines Java vertreiben 16:41 <+susi23> (als Nächstes versuchen wir, es auf J2ME laufen zu lassen ;) 16:42 <+fox> <Romster> GCJ wird Suns JVM übernehmen> 16:42 <cat-a-puss> wie ist die Performance mit GCJ? 16:42 <jrandom> aye, obwohl Sun völlig offen ist, und wir ihre JVM zusammen mit I2P verteilen /könnten/, verbietet ihre Lizenz die Verteilung ihrer JVM als allgemeines Werkzeug 16:42 <jrandom> cat-a-puss: vergleichbar 16:42 <jrandom> das meiste der schweren Arbeit in i2p wird ohnehin von Assembler-Code erledigt ;) 16:43 <+fox> <Romster> wie würde i2p nochmal mit C#/Mono laufen, mit dieser Java-zu-C#-Geschichte (Name vergessen) 16:43 <+fox> <Romster> ich erinnere mich, jrandom und ich haben das vor Ewigkeiten beide ausprobiert 16:43 <jrandom> keine Ahnung. Aber wenn es mit GCJ funktioniert, könnte es mit IKVM funktionieren – diesem Mono-JVM-Ding 16:44 <+Ragnarok> IKVM 16:44 <+Ragnarok> nm 16:44 <+fox> <Romster> ah, das war's, IKVM 16:44 <+fox> <Romster> große Unterschiede zwischen GCJ, IKVM und Suns? 16:45 <jrandom> ich habe IKVM noch nie benutzt 16:45 <+fox> <Romster> ich bin sicher, du hast es mal mit Mono benutzt, oder war das Eclipse? 16:45 <+fox> * Romster zuckt mit den Schultern 16:45 <jrandom> und i2p wie ausgeliefert unterstützt derzeit nicht die router console, allerdings unterstützt es den router-Betrieb, i2ptunnel und sam 16:46 <+Ragnarok> was blockiert die router console? 16:47 <+susi23> Xerces, wenn ich mich richtig erinnere 16:47 <jrandom> Xerces-Kram. die mit i2p ausgelieferte xercesImpl hat sun.*-Abhängigkeiten, und als ich naiv versucht habe, das neueste Xerces einzusetzen, ist es schiefgegangen, das sowie jdom und rome und den Rest von Jetty durch den GCJ zu bekommen 16:47 <jrandom> das neueste Xerces hat wohl einige zusätzliche Anforderungen 16:48 <jrandom> (für JAR-Dateien, die wir derzeit nicht mitliefern). Aber ich bin sicher, wir können das herausfinden 16:49 <+fox> <Romster> jrandom ist gut darin, Probleme aufzuspüren :) 16:49 <jrandom> noch besser darin, Probleme zu verursachen 16:49 <+fox> * Romster holt sich einen Kaffee 16:49 <jrandom> ok, noch etwas zu 3) GCJ-Status? 16:49 <jrandom> oder sollen wir zu 4) i2psnark weitergehen 16:50 <jrandom> betrachte uns als weitergezogen 16:50 <jrandom> ok, i2psnark ist zurück (yay) 16:51 <jrandom> viel habe ich über das hinaus, was in der Mail steht, nicht hinzuzufügen... hast du etwas, Ragnarok? 16:51 <+Ragnarok> nö 16:51 <+susi23> zum Web-Frontend 16:51 <+Ragnarok> mehr Tests wären jedoch schön, also sollte es jeder ausprobieren :) 16:52 <+susi23> das mit susibt zu unterstützen, sollte kein Problem sein 16:52 <jrandom> ooh, gib uns die Details, susi23 :) 16:52 <jrandom> schön 16:52 <+fox> <jme___> naive Frage: Warum Zeit investieren, einen alten BT-Client zu unterstützen, während andere (Azureus) einen vollwertigen Client unterstützen? 16:52 <jrandom> Azureus ist schon verdammt gut 16:52 <+susi23> ein Major-Release von susibt ist für November geplant :) 16:53 <jrandom> heh, cool, susi23 16:53 <+Complication> Für mich wirkte Azureus furchtbar komplex. 16:53 <+Ragnarok> Azureus ist grottig 16:53 <+susi23> für mich brauche ich immer eine headless (ohne GUI) Lösung 16:53 <+Ragnarok> um es mal deutlich zu sagen 16:53 <+fox> <jme___> ok :) 16:53 <jrandom> jme___: Azureus ist allerdings etwas heavyweight, aber eine großartige allgemeine BT-Lösung 16:53 <+Complication> (Ich könnte mir gut vorstellen, dass ich dort mal etwas falsch konfiguriere und meine Anonymität ankratze.) 16:54 <+fox> <jme___> ergibt Sinn, wollte es nur wissen 16:54 <+fox> <Romster> für mich hat Azureus nie gut funktioniert, ich bin zu BitLord gewechselt, das funktioniert 16:54 <jrandom> ich plane weiterhin, mit den Azureus-Leuten das azneti2p-Plugin weiter zu verbessern, aber bei i2psnark hat es buchstäblich weniger als 2 Stunden gedauert, bis ich Daten geswarmt habe 16:54 <+legion> Ja, Azureus ist für i2p einfach zu groß und kompliziert 16:54 <+Complication> Wenn das Ziel ist, einen BT-Client zusammen mit i2p zu bündeln, klingt ein leichter Client am besten. 16:54 <+fox> <Romster> KISS-Prinzip 16:54 <+Ragnarok> Ich mag den offiziellen Client am liebsten, aber i2psnark hat den großen Vorteil, dass er simpel genug ist, damit ich daran hacken kann 16:55 <+legion> das Ding ist, i2p braucht keinen heavyweight-BitTorrent-Client 16:55 <jrandom> ja, es ist wirklich sauberer Code (mit schrulligem GNU-Format ;) 16:55 <+Ragnarok> verdammt, GNU 16:55 <+Ragnarok> der schlechteste Klammerstil aller Zeiten 16:55 <jrandom> heh 16:55 <+fox> <Romster> heh, Code-Reformatter :) 16:55 <+Ragnarok> jrandom lässt mich nicht :) 16:55 <+Ragnarok> nun ja, aus gutem Grund 16:55 <+fox> <jme___> Unabhängigkeit und Einfachheit sind Kriterien, denen ich definitiv zustimme 16:56 <+fox> <Romster> wird es Optionen geben, das BT-Torrent-Programm auf jedem i2p-Knoten zu aktivieren? 16:56 <jrandom> ja, es wäre schön, wenn wir Multitorrent, Piece Selection und Web-Funktionalität in mjws Mainline-Snark backporten könnten 16:56 <+Ragnarok> je einfacher es ist, desto wahrscheinlicher wird es gepflegt 16:56 <jrandom> gaaaanz genau, Ragnarok 16:57 <+legion> ja, diese Backports wären der Hammer 16:57 <+fox> <Romster> OT: Schaut euch mal eMules KAD-Netzwerk an, ich finde das ziemlich cool. 16:57 <jrandom> Romster: es wird jetzt standardmäßig mit dem Build ausgeliefert, aber sobald wir es in susibt haben, wird es oben in der Navigation bei den anderen Clients sein 16:58 <+Ragnarok> wir müssen allerdings auch einen .torrent-Ersteller mitliefern können. Und ein Tracker wäre nett. 16:58 <jrandom> ja, tatsächlich hat Snark beides, ich habe es nur deaktiviert, weil ich es nicht pflegen wollte :) 16:58 <+legion> hmm, guter Punkt, Ragnarok 16:58 <jrandom> aber sie wieder reinzubringen, wäre nicht viel Aufwand 16:59 <+Ragnarok> nun, der Torrent-Ersteller sollte zumindest nicht so schlimm sein 16:59 <jrandom> es gibt auch eine Tracker.java und Handling im PeerAcceptor, aber ich habe rausgeworfen, was nicht nötig war, daher sollte man dafür wohl auf http://klomp.org/snark/ zurückschauen 17:00 <jrandom> (und review http://dev.i2p/~jrandom/snark_diff.txt for changes) 17:00 <+fox> <Romster> da snarik zurück ist, wird doch dran gearbeitet, oder? :) 17:00 <+legion> eigentlich wäre es bei einem Tracker besser, eine verteilte Lösung zu entwickeln 17:00 <+fox> <Romster> snark* 17:00 <jrandom> Code zu portieren ist einfacher, als einen neuen verteilten Tracker zu bauen, legion ;) 17:00 <+fox> <Romster> legion, du redest 17:00 <+legion> stimmt 17:01 <jrandom> aber ich hätte nichts dagegen, eine schöne, saubere, gepflegte, anonymitätsfreundliche verteilte Tracker-Lösung zu integrieren :) 17:01 <+fox> <Romster> könnte an die eepsites angeflanscht werden? 17:01 * jrandom sieht ein fliegendes Pony am Fenster vorbeiziehen 17:01 <+Ragnarok> der offizielle BT-Client hat einen Kademlia-basierten verteilten Tracker, aber das taugt natürlich nur als Design-Referenz 17:01 <+legion> ein Ansatzpunkt ;) 17:02 <+fox> <Romster> eigentlich Kademlia = eMules KAD-Netzwerk? hmm, wenn das so ist, wäre KAD ideal für einen Tracker, aber Bootstrapping ist ein Problem 17:03 <+Ragnarok> sie basieren auf demselben Algorithmus, sind aber in keiner Weise kompatibel 17:03 <+Ragnarok> kompatibel, sogar 17:04 <+Ragnarok> etwas wie eMules KAD für i2phex zu machen, wäre irgendwie interessant... 17:04 <+Ragnarok> wie auch immer, fliegende Ponys 17:04 <jrandom> :) 17:04 <jrandom> (stimme in beiden Punkten zu) 17:04 <jrandom> ok, noch etwas zu 4) i2psnark? 17:05 <+Ragnarok> solange wir etwas haben, um .torrent-Dateien zu erstellen, sind die bestehenden Tracker ok 17:05 <jrandom> guter Punkt – ich glaube, in Snarks main ist etwas auskommentierter Code 17:05 <+legion> nein, ich finde, die bestehenden Tracker sind nicht ok :( 17:05 <jrandom> was stimmt nicht mit ihnen, legion? 17:05 <cat-a-puss> gib den Nutzern nicht einfach nur eine Torrent-Datei 17:05 <+legion> oft hat man Probleme, auf sie zuzugreifen 17:06 <jrandom> hmm, cat-a-puss? oh, du meinst, wir brauchen ein Web-Interface zum transparenten Swarmen? 17:06 <+legion> Sites werden mit Traffic überflutet 17:06 <jrandom> ah, das ist i2ps Problem, hoffentlich wird 0.6.1.4 das verbessern 17:06 <jrandom> postman erzählte mir, dass er massenhaft Hits auf tracker.postman.i2p bekam 17:06 <jrandom> die Zahlen habe ich gerade nicht im Kopf 17:06 <cat-a-puss> Wenn wir sowohl den Swarming-Code als auch den Code zum Beschaffen des Torrents selbst handhaben, können wir es für den Nutzer auch gleich transparent machen 17:07 <jrandom> orion.i2p/bt/ wird allerdings kaum genutzt 17:07 <jrandom> (und tracker-fr scheint lebendig) 17:07 <+susi23> mit susibt hoffe ich, den RSS-Feed des Trackers einzubinden, so dass du nicht mehr auf die Webseite des Trackers musst, sondern die Torrents automatisch heruntergeladen werden :) 17:07 <cat-a-puss> verhindert auch, dass man einen i2p-Torrent mit einem nicht-anonymen verwechselt 17:07 <+fox> <jme___> HTTP-Tracker für BT skalieren aufgrund eines schlecht designten Protokolls nicht 17:07 <+fox> <Romster> router watchdog: router hängt hart, Neustart, wtf 17:07 <+legion> genau, das ist mein Punkt – einige Tracker werden überflutet, während andere Leerlauf haben 17:07 <jrandom> cat-a-puss: ah, ja, ich würde liebend gern Hooks von syndie in susibt integrieren :) 17:07 <+fox> <jme___> das ließe sich leicht beheben, würde aber die Kompatibilität mit dem offiziellen BT-Protokoll brechen 17:08 <+fox> <jme___> das ist der Weg, den die DHT-Tracker-Geschichten gehen 17:08 <jrandom> (und umgekehrt, damit Leute .torrent-Dateien leicht syndizieren können, etc) 17:08 <+Complication> Romster: die bekomme ich auch, aber die Maschine, auf der ich sie bekomme, ist grenzwertig (300 MHz) 17:08 <+fox> <Romster> der verteilte Tracker ist die Lösung für überlastete Tracker 17:08 <jrandom> legion: das lässt sich leicht beheben, indem Leute unterschiedliche Tracker verwenden :) 17:08 <+fox> <Romster> Azureus DHT 17:08 <jrandom> Code ist teuer, unterschiedliche URLs zu verwenden ist billig 17:08 <+legion> ja, aber das tun sie offenbar nicht, oder? 17:09 <jrandom> aber ja, ein verteilter Tracker wäre großartig. Steht aber nicht auf meiner Roadmap; wenn es jemand ans Laufen bringt, wäre das der Hammer. 17:09 <+Complication> Mit der Zeit... sicher kann auch jemand auf verteilt gehen. 17:09 <+legion> Statt Torrents auf Tracker-Sites zu posten, könnten sie einen bith und alle Details auf ihrer eepsite posten. 17:10 <jrandom> bith == Hash? 17:10 <+legion> ja, steht für BitTorrent-Hash, nicht mein Begriff 17:10 <+Complication> Am Anfang jedoch... ein einfacher und solider Client in Java, gebündelt mit dem router... kann viele Probleme lösen. (Vielleicht sogar signierte Updates ziehen, ohne dev.i2p zu überlasten.) 17:11 <+legion> ja, das wäre großartig 17:11 <jrandom> aye, Complication 17:11 <+fox> <Romster> ja, Torrent-Updates 17:11 <+fox> <Romster> ok, nächster Punkt auf der Liste :) 17:12 <jrandom> ok, 5) mehr zum Bootstrapping 17:12 <+legion> ja, weiter geht's 17:12 <jrandom> in letzter Zeit viel Interessantes auf der Liste, und ich werde das hier ganz sicher nicht alles zusammenfassen :) 17:12 <+fox> <Romster> Bootstrapping der i2p router-Datenbank? 17:12 <jrandom> hat jemand Fragen/Kommentare/Bedenken, die er zum Thread besprechen möchte? 17:12 <jrandom> Romster: siehe die Liste und/oder E-Mail 17:12 <+fox> * Romster muss diese Liste lesen 17:13 <jrandom> aye, da steht gutes Zeug drauf :) 17:13 <+fox> <Romster> ich war in letzter Zeit ziemlich beschäftigt 17:13 <+Complication> 26 Nachrichten zum Durchlesen, kann noch nicht kommentieren 17:13 <jrandom> noch kein Endergebnis, aber wir peilen für 0.6.2 eine neue Methode zum Bauen von tunnels an 17:14 <+fox> <Romster> eine neue Methode – gibt es einen Fehler in der aktuellen Methode? 17:14 <+fox> <Romster> Fehler* 17:14 <jrandom> Michaels Analyse zeigt, dass der Angriff jetzt nicht wirklich ein Problem ist, da es gegen die Alternativen einfachere Angriffe gibt 17:14 <jrandom> lies die Liste ;) 17:14 <+fox> <Romster> arg, später 17:14 <+fox> <Romster> jetzt ist jetzt :) 17:15 <+fox> <Romster> ich schlafe normalerweise um diese Zeit. 17:15 <+fox> <Romster> deshalb bin ich selten bei einem Meeting dabei 17:16 <cat-a-puss> kannst du deine Ideen für eine neue Methode / bestehende / verworfene Methoden in einer E-Mail an die Liste posten, damit wir vergleichen können 17:16 <+fox> <Romster> also hat es mit Angriffsmethoden und tunnel-Erstellung zu tun, nehme ich an, ohne die Liste gelesen zu haben 17:16 <cat-a-puss> (das ist für Jrandom) 17:16 <jrandom> cat-a-puss: ich bin nicht sicher, ob wir schon ein Endergebnis ausdiskutiert haben 17:16 <+fox> <Romster> wäre eine Idee, cat-a-puss 17:17 <+Complication> Romster: ja, es ging mehr oder weniger darum, dem Endpunkt eines exploratory tunnel als möglichem Angreifer weniger Einfluss zu geben 17:17 <jrandom> aber http://dev.i2p.net/pipermail/i2p/2005-October/001073.html ist das Neueste von dem, was ich aus deinem Vorschlag entstehen sehe 17:17 <jrandom> naja, nicht Einfluss – i2p ist ein Free-Route-Mixnet – sondern weniger Information 17:18 <+Complication> Ja, das wäre wohl der treffendere Begriff 17:18 <jrandom> (die oben verlinkte URL ist voller Rumfuchteln, noch keine solide Krypto ausgearbeitet) 17:18 <+fox> <Romster> weniger = besser für mehr Robustheit gegen Angriffe, ich verstehe, worauf du hinauswillst 17:18 <jrandom> ((aber ich denke, das ist alles mit bestehenden Techniken machbar) 17:19 <jrandom> Romster: hier ist ein Plot von Michaels Angriff gegen den bestehenden Algorithmus, wobei die X-Achse angibt, wie viel % des Netzwerks kompromittiert sind - http://dev.i2p.net/~jrandom/fraction-of-attackers.webp 17:20 <jrandom> (plain telescopic building wäre schon vor x=200 aus dem Diagramm raus) 17:20 <jrandom> ((das, was wir jetzt haben, ist also um Größenordnungen besser)) 17:20 <jrandom> aber wir können das weiter verbessern 17:21 <jrandom> obwohl es auch die garlic routing-Alternative gibt 17:21 <jrandom> wie auch immer, ja, mehr zu klären – behaltet die Liste im Auge :) 17:21 <+fox> <Romster> ok, ich lese mir die Liste später in Ruhe durch 17:22 <+fox> <Romster> und schaue, ob mir etwas zum Ergänzen einfällt 17:22 <jrandom> cool 17:22 <cat-a-puss> wäre die „neue“ teleskopische Methode schnell genug, um on-demand zu bauen? 17:22 <jrandom> ich bin nicht sicher, ob wir das wollen 17:22 <jrandom> das ist die O(1)-vs-O(N)-Frage 17:23 <jrandom> die neue Technik würde tunnel-Erstellung ohne die Nutzung der exploratory tunnels erlauben und die exploratory tunnels für netDb-Operationen lassen 17:23 <jrandom> (und für die Erstellung von exploratory tunnels :) 17:24 <+fox> <Romster> hmm, wäre es sinnvoll, die Hacker zu verwirren, indem man ihnen haufenweise False Positives liefert und so die wahre Quelle maskiert 17:24 <+legion> klingt gut :) 17:24 <+legion> ich denke, so ein bisschen Verwirrung wäre gut 17:24 <cat-a-puss> jrandom: genau, ich fragte, ob das die Dinge genug beschleunigen würde, so dass manchmal die letzten Hops nicht wissen, dass sie die letzten sind, wie auf der Liste diskutiert. 17:25 <+fox> <Romster> exploratory tunnels, um netDB router-Referenzen zu sammeln? 17:25 <jrandom> romster: wir sind die Hacker ;) aber ja, wenn die False Positives die True Positives überwiegen, bräuchte es eine erheblich große Zahl von Angriffen, um statistisch signifikante Daten zu bekommen 17:26 <jrandom> hmm, schon, cat-a-puss, aber ich bin nicht sicher, wie das etwas beschleunigen würde – es würde uns von einer O(1)- zu einer O(N)-tunnel-Topologie bringen 17:26 <jrandom> oder was meinst du mit beschleunigen? 17:26 <+fox> <Romster> und wenn es an den Punkt käme, entdeckt zu werden, könnte es dann abtauchen und eine Weile ruhig sein? 17:26 <jrandom> mit der neuen Technik würden fehlgeschlagene tunnel-Erstellungen sicher reduziert 17:26 <+fox> <Romster> oder frühzeitig den Schlüssel ändern und weitermachen oder so, heh 17:26 <jrandom> romster: es wäre wohl sinnvoll, die Mails durchzugehen, um den Angriff zu verstehen ;) 17:27 <+fox> <Romster> ja, nach dem Schlaf 17:27 <+Complication> Romster: soweit ich weiß, ist es größtenteils ein passiver Angriff, daher kann das Ziel ihn nicht bemerken 17:27 <+fox> <Romster> und ich repariere den PC eines Freundes, der hier steht 17:27 <+fox> <Romster> ah, verstehe, Complication. 17:27 <cat-a-puss> jrandom: ich rede nicht von der O(n)-Sache. Ich meine, einfach zu warten, einen Client-tunnel zu konstruieren, bis wir für einige Apps einen brauchen, statt sie ständig bereitstehen zu haben. 17:28 <+Complication> (aber ich könnte falsch liegen, und die letzten 26 Nachrichten könnten aktive Komponenten enthalten) 17:28 <+fox> <Romster> würde ein langfristiger passiver Angriff das Ziel schließlich finden? 17:28 <+fox> <Romster> ich kommentiere, nachdem ich die Liste gelesen habe 17:28 <jrandom> ah, cat-a-puss, wir werden das tunnel-Pooling für 0.6.2 auf jeden Fall verbessern. Wir bauen den tunnel derzeit nur, wenn wir ihn brauchen (und geben uns etwas Zeit, falls die Erstellung fehlschlägt) 17:28 <+Complication> Romster: nun, den Angriff über die Lebensdauer eines tunnels hinaus fortzusetzen, würde Ressourcen und Geduld erfordern 17:28 <+fox> <Romster> und es besser verstehen 17:29 <+Complication> Aber Zeit spielt in jeder Erfolgswahrscheinlichkeit eine Rolle. Versuchst du lange, hast du mehr Chancen. 17:29 <+fox> <Romster> ah, das ist die Idee: die tunnel-Lebensdauer ist zu kurz, als dass sich ein Angriff lohnen würde. 17:29 <jrandom> richtig, Complication – jede Stichprobe tritt nur 'm' Mal alle (c/n) tunnels auf 17:30 <+fox> <Romster> gibt es keine Interaktion zwischen den einzelnen tunnels, um Statistiken zu sammeln? 17:30 <+fox> <Romster> wenn einer kurz vorm Ablauf steht und ein anderer gebaut wird 17:31 <jrandom> romster: die neuen tunnels sprechen nicht miteinander, nein, aber das ist nicht der Angriff, den Michael beschrieben hat 17:31 <jrandom> es gibt unzählige Angriffe da draußen, die meisten haben wir behandelt, aber wann immer jemand einen vorschlägt, der für I2Ps Betrieb relevant sein könnte, wollen wir ihn weiter analysieren 17:31 <+fox> <Romster> muss die Liste lesen, ok, ich belasse es fürs Erste dabei, hat noch jemand etwas zu sagen? 17:32 <jrandom> ok, wenn es nichts weiter gibt, gehen wir zu 6) Virus-Untersuchungen über 17:32 <+fox> <Romster> eine Statistik, die man sammeln könnte: kein 0-Hop würde bedeuten, dass der nächste Hop nicht der Endpunkt ist, also könnte er ausgeschlossen werden – aber bei Millionen von Knoten wäre diese Analysetechnik nutzlos 17:33 <jrandom> ich habe nichts hinzuzufügen über das hinaus, was im Forum diskutiert wurde 17:33 <jrandom> genau, Romster, es gibt Predecessor-Angriffe auf die tunnel-Länge, was eines der Hauptthemen ist, das wir in 0.6.2 angehen 17:33 <+fox> <Romster> Virus, welcher Virus? Wenn es Linux ist, existiert er nicht, aber Windows, hmmm 17:34 <+Complication> Nun, obwohl ich kein passendes Binary bauen konnte (keine Ahnung warum), war der endgültige Unterschied klein genug... um hoffentlich für jeden nützlich zu sein, der Assembler-Code lesen möchte. 17:34 <jrandom> Romster: bitte, die wöchentlichen Statusnotizen sollten diese Tagesordnungspunkte erklären, und das Meeting ist dazu da, Dinge /über/ das in den Notizen hinaus zu diskutieren ;) 17:35 <+Complication> Ich konnte darin sicher nichts Offensichtliches finden, aber ich konnte auch nicht alle Unterschiede weg erklären. 17:35 <@cervantes> rtfml und rtff 17:35 <+fox> <Romster> ja, ich war nicht auf dem Laufenden, sorry dafür, jrandom 17:35 <@cervantes> ;-) 17:35 <jrandom> aye, die Tatsache, dass sowohl eine bekannte sichere BAT-Datei als auch die alte denselben Erkennungscode ausgelöst haben, ist erheblich 17:35 <+Complication> Ja, das nimmt etwas Zweifel. 17:36 <+Complication> Ich vermute, dass der QBFC undokumentierte Unterschiede innerhalb derselben Versionsnummer haben könnte (verschiedene Builds?) 17:37 * jrandom hat keine Ahnung, aber es ist möglicherweise nur irgendeine OS-Interaktion oder was auch immer. Ich weiß es nicht, du hast genug Analyse geliefert, damit Leute ihre eigene informierte Entscheidung treffen können 17:37 <+Complication> Ich denke, so ist es besser. 17:37 <+Complication> Disassembly liegt wirklich deutlich außerhalb meines üblichen Spielplatzes. 17:37 <jrandom> legion: möchtest du dazu etwas erwähnen, oder sollen die Leute einfach das Forum durchgehen, wenn sie mehr Infos wollen? 17:38 <@cervantes> darf ich einfach wiederholen, was andere im Forum gesagt haben, und Complication für die Zeit und die akribischen Versuche danken, die er in die Prüfung dieses Themas gesteckt hat 17:38 <jrandom> aye, es wird sehr geschätzt 17:38 <+legion> Ich habe nichts hinzuzufügen, ich habe das Gefühl, ich habe dazu schon viel zu viel gesagt 17:39 <jrandom> 'k, verstanden. ok, hat noch jemand etwas dazu, oder sollen wir zu 7) ??? übergehen 17:39 <jrandom> [betrachtet uns als weitergezogen] 17:40 <+fox> * Romster unterstützt das :) 17:40 <+legion> ok, für 7)??? wie wäre es, wenn wir kurz i2phex besprechen 17:40 <jrandom> cool, gute Idee 17:40 <+fox> <Romster> da ich es gerade sogar nutze :) 17:40 <@cervantes> nein nein, erst Gruppenumarmung 17:40 <jrandom> redzara meinte, er würde beim Meeting dabei sein, aber der Fortschritt beim Merge ist langsam 17:41 <+legion> susi23 fragte nach einer headless-Version 17:41 <jrandom> ah, cool, ich habe deinen Post dazu gesehen 17:41 <+fox> <Romster> darf ich hinzufügen, dass die Favoritenliste breiter sein muss, um mit den längeren i2p-Keys klarzukommen 17:42 <+susi23> (ist kein Muss, ich war nur neugierig) 17:42 <jrandom> nun, niemand kann sich base64-Keys merken, daher bin ich nicht sicher, ob dir viel entgeht, Romster ;) 17:42 <jrandom> (und die ersten paar Bytes sollten ausreichen, um sie eindeutig zu identifizieren) 17:42 <+fox> <Romster> i2phex mit einem Server zu starten, ist bisher das Hauptproblem, das ich sehe 17:42 <+legion> Eigentlich würde ich im Client nur die ersten 12 Zeichen der Keys angezeigt sehen 17:42 <+fox> <Romster> heh, rate mal 17:42 * Complication ist leider extrem beschäftigt und kann kein XML-RPC machen 17:43 <jrandom> klingt vernünftig, legion 17:43 <+fox> <Romster> wie wäre es, so viele Zeichen anzuzeigen, bis der Key eindeutig ist 17:43 <jnymo_> Ich habe gute Ergebnisse mit i2phex 17:44 <jrandom> cool, jnymo_, ich habe auch Gutes gehört 17:44 <+fox> <Romster> also wenn 2 Keys mit abc anfangen, wäre es abcx 17:44 <jnymo_> 12 identische Zeichen sind unwahrscheinlich, Romster 17:44 <+fox> <Romster> stimmt 17:44 <+Complication> Außerdem: einfacher = schneller 17:44 <+fox> <Romster> aber man bräuchte keine 12, wenn die Keys so stark randomisiert sind 17:45 <+Complication> (nicht dass man beim Anzeigen viel Geschwindigkeit gewinnen könnte) 17:45 <+legion> Vielleicht könnte es ein neues Host-Eigenschaften-Fenster geben, das den vollen Key und bestimmte Informationen anzeigt, z. B. wie viel er teilt und so weiter 17:45 <+susi23> (netDb funktioniert für router-IDs schon mit 4 Zeichen prima) 17:45 <+fox> <Romster> oder die Datenbank nutzen und keyname=base64 verwenden und nur den keyname anzeigen 17:45 <jrandom> hmm, ich dachte, es gäbe schon eine Peer-Info-Anzeige, legion? 17:46 <jrandom> legion: so etwas wäre vermutlich gut, im Mainline-Phex ergänzt zu werden? 17:46 <+legion> hmm, könnte sein... 17:46 <jrandom> (so kann Gregor es pflegen ;) 17:46 <+Complication> Nun, es gibt eine „Browse host“-Funktion, aber das ist vielleicht nicht ganz dasselbe. (Wenn sie funktioniert.) 17:46 <jrandom> Complication: tut sie 17:46 <jrandom> (funktionieren, meine ich) 17:47 <+Complication> Scheint im Grunde den Host-Destkey in das Suchfeld zu werfen 17:47 <+Complication> ...und startet eine Suche. 17:48 <jnymo_> das ist vielleicht ein i2phex-Mainline-Thema, aber ich habe keine ETA für i2phex-Downloads gesehen 17:48 <+Complication> Hmm... oder eigentlich startet sie keine Suche. 17:48 <+Complication> Meine scheint zu warten, bis ich sie manuell starte. 17:48 <+fox> <Romster> wofür ist die Checkbox „Nearby i2phex running“? 17:49 <+legion> Ich sehe, dass es reichlich Raum für Verbesserungen gibt. ;) 17:49 <jrandom> jep :) 17:50 <jrandom> viel zu tun, und das Forum ist ein guter Ort, um Ideen/Vorschläge/Fragen(/Patches :) zu posten 17:50 <+fox> <Romster> trotz seines offensichtlichen Namens 17:50 <jrandom> ok, hat noch jemand etwas für das Meeting? 17:50 <+fox> <Romster> hmm, guter Punkt 17:50 <+fox> <Romster> mir fällt sonst nichts ein 17:51 <+fox> <Romster> aber arbeitet jemand an einem verteilten Datenspeicher? 17:51 * cervantes schaut auf seine Uhr 17:51 <+fox> <Romster> so richtig aktiv 17:51 <jrandom> Romster: abgesehen von syndie, nein 17:51 <jrandom> (zumindest meines Wissens nicht) 17:52 <+legion> ich habe mich gefragt, ob man einen HTTP-Download-Manager in i2p integrieren könnte – das würde das Herunterladen größerer Inhalte von eepsites erleichtern. 17:52 <+fox> <Romster> q und iphex und ein oder zwei andere, aber ich habe seit einer Weile nichts Wartbares mehr gesehen 17:52 <@cervantes> wie ist der Status von feedspace... ich habe davon länger nichts gehört 17:52 <jrandom> legion: das wäre cool – dazu gibt es auch einen Post im Forum, glaube ich 17:53 <+fox> <Romster> ah, feedspace, noch eins 17:53 <jnymo_> falls das schon im Meeting erwähnt wurde, nm.. aber gibt es Neuigkeiten zur i2p-Freenet-Zusammenarbeit? 17:53 <jrandom> cervantes: zuletzt hörte ich, dass frosk ziemlich beschäftigt war, aber wenn frosk da ist, kann er uns vielleicht mehr sagen :) 17:53 <+legion> Ich persönlich würde gern eine i2p-Entropy-Zusammenarbeit sehen. 17:54 <+fox> <Romster> ich habe Ideen für einen Datenspeicher, aber das wäre eine Erweiterung der derzeit verwendeten Methoden 17:54 <+legion> Da q, feedspace und Co. derzeit nicht gerade schnell vorankommen 17:54 <jrandom> jnymo_: ich habe den Freenet-Leuten etwas Code geschickt, um auf unserem SSU-Transport zu laufen, toad hat sich an einigen Diskussionen beteiligt, aber Freenet wird noch eine Weile nicht in der Lage sein, dass wir es als Datenspeicher oben auf i2p laufen lassen (wahrscheinlich erst nach deren 0.7-Release) 17:54 <+fox> <Romster> ich möchte ein Projekt starten, aber nicht das wiederholen, was andere bereits getan haben 17:54 <+legion> frage mich, ob es möglich wäre, Entropy zu portieren, um über i2p zu laufen... 17:54 <jrandom> legion: Entropy wäre gut, aber die Integration ist irgendwie schwierig. Natürlich könnten Leute Dinge wie fproxy.i2p für Entropy betreiben 17:55 * jrandom kennt Entropys Transportcode überhaupt nicht 17:55 <+fox> <Romster> ich habe meinen IRC-Client auf Eis gelegt, davon sind schon viele in Arbeit – alles, was i2p jetzt braucht, ist ein Datenspeicher, und dann schlägt es Freenet mit Leichtigkeit :) 17:55 <jrandom> (aber vielleicht wäre das ein guter Weg, jemanden dazu zu bringen, am GCJ-SDK zu hacken :) 17:56 <jrandom> Romster: bei anderen Projekten zu helfen, ist viel lohnender, als brandneue zu starten, da man mit weniger Aufwand viel mehr schafft :) 17:56 <jnymo_> ah.. Glückwunsch zum GCJ-Port 17:56 <+fox> <Romster> Entropy ist in C oder C++, iirc 17:57 <jrandom> genau, Romster, weshalb sie I2Ps SDK und die Streaming-Bibliothek verwenden könnten, mit GCJ zu nativen Bibliotheken gebaut 17:57 <+fox> <Romster> jrandom, stimmt, aber wer :) 17:57 <jrandom> ich nicht 17:57 <+legion> oh, und noch etwas: heute habe ich eine neue Version meines readme.html-Updates für die i2p router console veröffentlicht. 17:57 <jrandom> (der einzige Weg, etwas, das dir wichtig ist, erledigt zu bekommen, ist, dass *du* es tust :) 17:57 <jrandom> cool 17:57 * dust würde gern eine Art 'squid'-Syndikation sehen, um eepsites zu entlasten 17:58 <jrandom> dust: ja, total, wenn wir sucker in diese Position bringen können, wäre das ideal 17:58 <jrandom> z. B. würde ich gern die neuesten Infos von orion in syndie, lokal bekommen 17:58 <+fox> <Romster> baue einen Proxy, den Squid nutzen kann :) 17:59 <+legion> Ich habe es aufgeschoben, in der Hoffnung, dass bestimmte Verbesserungen am Python-eepsitechecker bis jetzt gemacht worden wären. 17:59 <dust> ah, syndie 17:59 <jrandom> (das ist eigentlich der Zweck von syndie – Syndizierung, um die Last zu reduzieren) 17:59 <dust> _die_ Antwort 17:59 <jrandom> es gibt einen Python-eepsite-Checker? 17:59 <+fox> <Romster> das höre ich zum ersten Mal 17:59 <+legion> ja, den benutze ich ;) 18:00 <jrandom> cool, legion 18:00 <+legion> wirklich? Den gibt es schon eine Weile 18:00 <+fox> <Romster> nice, das würde ich mir gern ansehen :) 18:00 <@cervantes> ich glaube, jemand hat baffleds Skript portiert... weiß nicht mehr wer/wann 18:00 <+fox> <Romster> ich lerne Python 18:00 <jrandom> ah ok, cervantes 18:00 <+fox> <Romster> auf die harte Tour mit Beispielen und dem Handbuch :) 18:00 <jrandom> ja, ich bin faul, ich benutze einfach polecat.i2p/i2psurvey/ und orion.i2p/ :) 18:01 <jrandom> (kein Bedarf für mich zu spidern) 18:01 <+legion> wenn jemand mit mir daran arbeiten möchte, würde ich den Code wirklich gern reparieren und mit Python 2.3 oder 2.4 zum Laufen bringen 18:01 <+fox> <Romster> ich habe hier 2.4 installiert 18:01 <+Ragnarok> Ich schaue es mir vielleicht an. Link? 18:01 <+fox> <Romster> denke eigentlich, es ist 2.4.1 18:02 <+legion> aktuell hat es keine py2exe-Kompatibilität und die Hälfte funktioniert jeweils mit einer Version, was bedeutet, dass jeder, der es ausführt, beide installiert haben muss. 18:02 * jnymo_ würde gern einen orion.i2p/I2PDirectory-Hybriden sehen.. Infos, Kategorien, Stats.. Butter 18:02 <+legion> Ich archiviere es nach dem Meeting und poste einen Link ins Forum 18:03 <+Ragnarok> ok 18:03 <jrandom> legion: hmm, siehst du viele Leute, die das ausführen müssten? Ich meine, nur wenige müssen spidern 18:03 <+fox> <Romster> beides, ugh, könnte etwas viel für mich sein, um es auf die neuere zu portieren – weiß ich erst, wenn ich den Code sehe 18:03 <jrandom> (nicht, dass etwas dagegen spräche, es diesen wenigen Leuten leicht zu machen, das ist :) 18:04 <+fox> <Romster> könnte zerlegt und für andere Dinge genutzt werden? 18:04 <+legion> Nun, ich sehe Anwendungen, von denen jeder profitieren könnte, der i2p betreibt. 18:04 <+fox> <Romster> könnte* 18:04 <jrandom> hmm, da bin ich mir nicht so sicher, könntest du erklären wie? 18:04 <jrandom> ich meine, ich möchte nicht, dass im Grunde jeder jede eepsite DDoS't 18:05 <+legion> eine davon wäre eine dynamische Lesezeichenseite, die alle 12–24 Stunden automatisch generiert wird. 18:05 <jrandom> ah, das ist in syndie trivial (tatsächlich eines der Hauptfeatures – 'neue Blogs') 18:05 <jrandom> ((aber natürlich hat syndie dafür noch kein großartiges UI)) 18:06 <+fox> <Romster> eigentlich bräuchte es nur ein paar, die spidern, und das in eine torrent-/DHT-ähnliche Datenbank werfen und zwischen Knoten synchronisieren 18:06 <jrandom> genau, Romster (obwohl diese torrent-/DHT-ähnliche Datenbank zum Synchronisieren, oder zum „Syndi“-zieren, syndie sein könnte ;) 18:06 <+fox> <Romster> könnte sogar ein versteckter Weg sein, mehr i2p-Knoten und -Dienste kennenzulernen 18:07 <+fox> <Romster> ja, oder syndie 18:07 <jrandom> ok, hat sonst noch jemand etwas fürs Meeting? das Curry wird kalt ;) 18:08 <+fox> <Romster> wenn syndie so großartig wird, könnte man statische Seiten cachen und ebenso Bilder 18:08 <+fox> <reliver> bon appetit, jrandom :-) 18:08 <jrandom> genau, Romster, das kannst du jetzt schon 18:09 <jrandom> ok, wenn es nichts weiter gibt... 18:09 * jrandom kommt zum Ende 18:09 * jrandom *baf*t das Meeting zu