I2P Entwicklertreffen - 6. Januar 2004

[22:02] <jrand0m> Tagesordnung: [22:02] <jrand0m> 0) hi [22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html [22:02] <jrand0m> 2) [Diskussion] [22:02] <wiht> Kann ich den Installer auf die Tagesordnung setzen? [22:02] <jrand0m> 0) hi [22:02] <jrand0m> oh ja, sicher! [22:02] <jrand0m> wir probieren diese Woche etwas Neues aus [22:03] <wiht> Du kannst es ans Ende der Tagesordnung stellen. [22:03] <jrand0m> statt des alten blablaantwortblabla beschreibt der Beitrag http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html das meiste von dem, was ich sagen wollte [22:03] * mihi_ ist #i2p beigetreten [22:04] <jrand0m> stattdessen versuchen wir diese Woche, das Treffen diskussionsorientierter zu machen – Dinge, über die Leute aus diesem Beitrag sprechen wollen, etwaige Folgebeiträge und/oder alles andere, worüber die Leute sprechen möchten [22:04] <jrand0m> zum Beispiel ein neuer Installer [22:05] <jrand0m> also, gesagt, getan: Leute sollten mit dieser E‑Mail/diesem Beitrag anfangen, und von dort gehen wir weiter :) [22:05] * mihi_away heißt jetzt mihi [22:05] * kaji liest den Beitrag [22:05] * mihi_ heißt jetzt mihi_backup [22:06] <jrand0m> 27 Nutzer mit nur einem Duplikat! w0w [22:07] * dm heißt jetzt dup [22:07] <jrand0m> ok, wenn die Leute das gelesen haben, können wir vielleicht damit anfangen, den Index durchzugehen und zu schauen, ob jemand etwas hinzufügen / kommentieren / diskutieren möchte? [22:07] <mihi> jrand0m: Woher weißt du, dass es keine weiteren Dupes gibt? [22:07] <jrand0m> heh danke dm [22:07] <jrand0m> mihi> Ich habe auf allen Rechnern Keylogger installiert (bwhahahaha) [22:07] <wiht> Ich möchte Installer als Thema 10 hinzufügen und eventuell Naming Service als Thema 11. [22:07] * mihi hat die Follow-up-Mail an die falsche Adresse geschickt :(, sende neu... [22:08] <jrand0m> gute Idee, wiht [22:09] <MrEcho> mrechos neues dns ist in Arbeit [22:09] <jrand0m> cool, mihi, ja, ich habe mich schon gewundert ;) [22:09] <kaji> wie läuft dns? – ah [22:09] <jrand0m> MrEcho> dein Beitrag, richtig? [22:09] <MrEcho> schreibe am Beitrag [22:10] <jrand0m> ok, in der Zwischenzeit: Hat jemand etwas zu 1) Streaming? Oder sollen wir zu 2) I2PTunnel, TunnelManager und i2pmgr springen? [22:10] <lucky> mein gott... ich könnte den Rest meines Lebens damit verbringen, diese Abhängigkeiten zu verstehen. [22:10] <wiht> Sagen wir DNS/NS als Thema 11. [22:10] <jrand0m> klingt gut, wiht [22:10] * duck kommt rein [22:11] <jrand0m> Abend duck [22:11] <mihi> zu 1, ich habe Code für i2ptunnel eingecheckt, der die Streaming-API benutzt [22:11] <jrand0m> ah richtig, großartig, mihi :) [22:11] <lucky> hi duck [22:11] * twosandals hat IRC verlassen (Leaving) [22:11] <kaji> jrand0m können mehrere Dienste denselben Schlüssel verwenden, wenn sie auf unterschiedlichen Ports sind? [22:11] <jrand0m> nein, kaji [22:11] <mihi> btw: warum löschen deine Ant-Dateien immer das jar, bevor sie es neu bauen? [22:11] <jrand0m> mihi> Paranoia [22:12] <mihi> stiehlt mir Zeit beim Debuggen, würde ich sagen ;) [22:12] <jrand0m> kaji> in i2p ist ein Schlüssel /ist/ im Grunde ein Port [22:12] <jrand0m> heh [22:12] <kaji> ah [22:13] <jrand0m> mihi> wenn du das aktualisieren willst – solange es das jar baut, wenn sich die Class-Dateien ändern, ist das ok [22:13] <mihi> wenn die Datei neuer ist als alle Dateien darin, und könnte es sonst überspringen. [22:13] <jrand0m> richtig [22:13] <mihi> und für Paranoia ist es besser, eine <depends>-Task hinzuzufügen [22:13] <jrand0m> einverstanden [22:13] <FillaMent> yo yo [22:13] <jrand0m> 'lo FillaMent [22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr [22:14] * TC ist #i2p beigetreten [22:15] <human> ich habe ein wenig gehackt, damit der TunnelManager die Job-IDs zurückgibt, wenn "openclient"- oder "openserver"-Befehle aufgerufen werden [22:16] <jrand0m> kickass :) [22:16] <human> so wissen Apps, die den TunnelManager verwenden, welchen Job sie später schließen müssen, ohne die "list"-Ausgabe zu parsen [22:16] <jrand0m> ja, ich war mit der Nutzung von tunnelmanager's list und close nie ganz zufrieden, da sich mehrere Clients so gegenseitig zerschießen können [22:17] <jrand0m> wir bringen den Patch direkt nach dem Meeting rein. gracias human :) [22:17] <human> es erforderte, dass I2PTunnel.runCommand etwas zurückgibt (derzeit eine Property) [22:17] <human> s/Property/Properties/ [22:17] <jrand0m> oh richtig, da gibt es ein paar Dinge zu ändern, bevor das in den Code kommt [22:18] <human> aber soweit ich verstehe, würde mihi lieber asynchrone Callbacks zur Logging-Klasse hinzufügen... [22:19] <jrand0m> richtig – damit Dinge sofort Informationen von den Tasks bekommen können, ohne zu warten, bis sie fertig sind [22:20] * mihi hat IRC verlassen (EOF From client) [22:20] <human> jrand0m: die Idee ist: lass I2PTunnel.runCommand() sofort zurückkehren und nutze dann ggf. Callbacks, um mehr Infos zu bekommen, richtig? [22:21] <jrand0m> richtig [22:21] <jrand0m> sodass die Tasks Callbacks auslösen, wann immer es Daten zu verteilen gibt [22:21] * mihi ist #i2p beigetreten [22:21] <human> nun, IMHO gibt es noch eine Frage: «Wie viele Java-Apps nutzen (werden) I2PTunnel.runCommand() asynchron (nutzen)?» *Alle* Apps, die derzeit I2PTunnel verwenden (auch via TunnelManager), kommen mit synchronen (auch wenn langen) .runCommand()-Aufrufen gut zurecht, und alles asynchron zu machen, würde die Dinge nur komplizierter machen (IMHO) [22:22] * mihi benutzt es über das GUI [22:22] <human> (nun, "alle" heißt der TunnelManager und Apps, die die TunnelManager-Ausgabe parsen) [22:22] <jrand0m> richtig, das GUI hängt, während der Befehl ausgeführt wird [22:22] <mihi> und das Eingeben der nächsten 3 Tunnel-open-Befehle ist blockiert, solange der erste läuft [22:23] <human> mihi: ok, das wusste ich über deine App nicht... dann brauchen wir eine Lösung :-) [22:24] <human> mihi: asynchrones .runCommand()-Verhalten würde eine Überarbeitung des TunnelManager erfordern [22:24] <mihi> human: wann (deiner Meinung nach) sollte runCommand enden? Wenn der Tunnel aufgebaut ist, wenn die Verbindung durchgekommen ist? [22:25] <mihi> "destination unreachable" wird *nach* dem ersten Verbindungsversuch bekannt sein. [22:25] <jrand0m> das Command-Pattern würde execute() erst zurückkehren lassen, wenn es abgeschlossen ist. [22:26] <mihi> was bedeutet *abgeschlossen*? [22:26] <jrand0m> (wenn wir also dem Command-Pattern folgen, würde runCommand blockieren, bis alles, was für diesen Befehl erforderlich ist, fertig ist) [22:26] <human> mihi: hehe, das ist die Frage :-) [22:26] <jrand0m> abgeschlossen bei "server 1234 privkeys" wäre, wenn der Server Verbindungen auf Port 1234 annehmen kann [22:26] <human> mihi: nun, IMHO sollte es bei TunnelServern nach dem Tunnelaufbau zurückkehren [22:27] <jrand0m> abgeschlossen bei "client 234 peer" wäre, wenn eine Verbindung zu Port 234 erfolgreich den peer erreicht [22:27] <jrand0m> so sehe ich das zumindest [22:27] <mihi> wie kannst du Letzteres feststellen? [22:27] <jrand0m> ich bin da nicht festgelegt [22:27] <jrand0m> vielleicht ein Ping? [22:27] * Sciatica ist #i2p beigetreten [22:28] <mihi> und wenn der peer direkt nach dem Ping ausfällt? [22:28] <mihi> imo ist es unmöglich, Netzwerkanwendungen ohne Callbacks zu machen [22:28] <jrand0m> richtig [22:28] <mihi> oder viele Threads, und ich bevorzuge Callbacks gegenüber zu Tode synchronisierten Threads [22:29] <jrand0m> vielleicht sollte es nur zurückkehren, nachdem es /versuchen/ kann, sich zu verbinden? [22:29] <jrand0m> oder vielleicht ist das Command-Pattern nicht das gewünschte Pattern [22:29] <mihi> das macht es gerade. und welches Ergebnis sollte es dann zurückgeben? [22:30] <mihi> der Punkt ist, dass du ein Ergebnis willst (anders als ein int für die Verbindungs-ID) [22:30] <jrand0m> richtig, für den Client-Befehl will man den Job (damit man ihn später schließen kann), aber für den genkey-Befehl will man den Public Key und Private Key [22:30] * mihi fällt nichts anderes ein, was zu diesem Zeitpunkt bekannt ist. [22:30] <jrand0m> einverstanden, mir auch nicht. [22:31] <dup> 0! [22:31] <mihi> und genkey sollte warten? ok, wenn du meinst. [22:31] <human> mihi: nun, so etwas wie einen Status ("ok" oder "error") und Fehlermeldungen... [22:31] <mihi> human: Fehlermeldungen kommen imo "zu spät" [22:31] <mihi> aber macht, was ihr wollt... [22:32] <mihi> solange ihr es danach auch mit der Streaming-API zum Laufen bringt... [22:32] <jrand0m> die Schmerzpunkte, die human anspricht, sind die Hacks im TunnelManager, der die Logging-Meldungen parst. Aber ich stimme zu, solange wir diese Informationen über die Logging-Schnittstelle exponieren können, ist das ok [22:32] <dup> mihi ist weise. [22:32] <human> human: manches kann sofort mitgeteilt werden (z. B. wenn der Tunnel-Port noch belegt ist) [22:32] <mihi> human redet mit sich selbst ;) [22:32] <human> ups! :-) [22:35] <human> vielleicht sollten wir schauen, welche Art von Anwendungen auf I2PTunnel aufbauen [22:35] <human> die asynchrone Schnittstelle ist das Right Thing(TM), aber sie ist komplizierter zu benutzen [22:35] <jrand0m> Ich denke, es wäre am besten, wenn wir dieselbe Funktionalität für die aktuelle Software beibehalten könnten – einschließlich des GUI. [22:35] <FillaMent> vielleicht falle ich unwissend dazwischen, aber eventuell eine Methode wie man sie oft bei HTTP findet: getHeader(String headerName) [22:35] <FillaMent> smake mich nach Bedarf [22:35] <FillaMent> smack [22:36] * jrand0m smake't FillaMent [22:36] <human> und der TunnelManager braucht es nicht (da er aufgrund seiner Natur *nie* asynchrone Events richtig unterstützen können wird) [22:36] * kaji hat eine komplett off-topic Idee [22:36] * FillaMent ergibt sich der Advocacy =) [22:37] <human> aber wenn mihis Anwendung den Tunnelzustand überwachen muss, dann ist die asynchrone Schnittstelle ein Muss(TM) [22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n. Wir müssen Async unterstützen. [22:37] <kaji> i2p als Java-Applet, damit man es auf fremden Rechnern schnell laufen lassen kann, indem man eine Website aufruft [22:37] * Sciatica hat IRC verlassen (EOF From client) [22:37] <human> jrand0m: ja, dann müssen wir den TunnelManager überarbeiten :-) [22:37] <jrand0m> kaji> i2p 3.0 :) [22:38] <jrand0m> einverstanden human, die TunnelManager-Implementierung war eine Quick-and-Dirty-Implementierung [22:38] <jrand0m> meinst du, du könntest dir ansehen, wie das ablaufen müsste? [22:38] * human kann sich anbieten, den TunnelManager an die asynchrone Schnittstelle anzupassen, wenn sie fertig ist [22:38] <jrand0m> w00t :) [22:40] <jrand0m> ok, sind wir bereit für Tagesordnungspunkt 3) I2COCP [22:40] <human> andernfalls wäre es möglich, Sync- und Async-Methoden für I2PTunnel zu erstellen [22:40] <jrand0m> stimmt [22:40] <jrand0m> aber Duplizieren könnte Overkill sein, wenn ein wenig Refactoring denselben Zweck erfüllt [22:41] * baffled hat IRC verlassen (Leaving) [22:41] <duck> persönliche Sorge bezüglich der tunnels: Apps schließen sie nicht, sodass dein ganzer TunnelManager geflutet wird [22:41] <human> jrand0m: ja, wir sollten die einfachste Lösung wählen – entweder den TunnelManager überarbeiten oder neue APIs zu I2PTunnel hinzufügen :-) [22:42] <jrand0m> guter Punkt, duck. Derzeit gibt es keine Timeouts/Verfallszeiten, und es wird angenommen, dass die Apps, die den TunnelManager nutzen, sich gut verhalten (und dass der TunnelManager keine Bugs hat [hah!]) [22:43] <mihi> apropos neue APIs: sollten die Streaming-API-Klassen die alten "ersetzen" oder sollte es möglich sein, beide zu nutzen (mit unterschiedlichen Befehlen?) [22:43] <jrand0m> mihi> Ich denke, die Streaming-Versionen werden ersetzen wollen, denn sobald die Streaming-API stabil ist, wird mode=GUARANTEED verschwinden [22:43] <jrand0m> (und daher funktionieren die alten nicht mehr) [22:44] * MrEcho 's E-Mail gesendet [22:46] <jrand0m> noch etwas zur Tunnel-Diskussion? (das ist natürlich nicht das Ende der Tunneldiskussionen insgesamt ;) [22:47] * dup heißt jetzt dm [22:47] <jrand0m> ok, I2COCP [22:47] <jrand0m> das war nur etwas, das human neulich vorgeschlagen hat, und es scheint eine Lücke zu füllen, die derzeit nicht abgedeckt ist. Aber ich denke, wir wollen mit der Implementierung warten, bis wir etwas haben, das es nutzen will :) [22:48] <wiht> Das ist ein etwas langer Name, sogar abgekürzt. [22:48] * jrand0m nennt I2COCP jetzt "Wilma" [22:48] <human> jrand0m: nun, ich wollte dieselben Worte schreiben :-) [22:48] <jrand0m> heh cool [22:49] <jrand0m> ok, springen wir zu 4) Roadmap [22:49] <human> jrand0m: IMHO sollte es allgemein eine Möglichkeit geben, dass Nicht-Java-Apps einigermaßen vollen Zugriff auf das I2P-Netzwerk haben [22:49] <jrand0m> einverstanden [22:49] <jrand0m> die Absicht ist, dass sie I2CP verwenden [22:50] <jrand0m> (wie alle Java-Apps, inklusive i2ptunnel und der Streaming-Bibliothek, das auch tun) [22:50] <human> jrand0m: ja [22:50] <MrEcho> I2PDNS "Janessa" [22:50] <jrand0m> aber du hast recht, sie wollen auch Streaming, also entweder tunnelmanager->i2ptunnel oder i2cocp->Streaming-Bibliothek [22:50] * jrand0m hat noch nie eine Janessa getroffen [22:51] * Sciatica ist #i2p beigetreten [22:51] <jrand0m> ok, ja, die Roadmap wurde aktualisiert. Keine großen Änderungen außer, dass 0.3 und 0.3.1 um 2 Wochen nach hinten geschoben wurden, 2.0-Infos hinzugefügt und einige weitere 1.0-Kriterien [22:51] <human> jrand0m: ja, es sollte "TCP"- und "UDP"-ähnliche Protokolle für I2P geben, mit vollständigem Protokoll-Event-Reporting, zugänglich für Nicht-Java-Apps [22:52] <MrEcho> human, klingt gut [22:52] <jrand0m> Ich möchte, dass es jede denkbare Schnittstelle gibt, aber ich möchte mich nicht mit zu vielen zu unterstützenden Schnittstellen übercommitten [22:52] * human wollte I2COCP (oder wie auch immer) für seinen I2P-twisted-Transport (siehe http://www.twistedmatrix.com/), aber vorerst bastelt er sich glücklich um den TunnelManager herum :-) [22:53] * w0rmus hat IRC verlassen (Lost terminal) [22:53] <jrand0m> word. Das wäre fürs Erste am besten [22:54] <jrand0m> ok, irgendwelche Kommentare zur Roadmap? [22:55] <jrand0m> [nichts zu sehen hier, la la] [22:55] <jrand0m> ok, 5) i2pIM [22:55] <jrand0m> thecrypto ist nicht hier, also können wir einfach auf einen Beitrag an i2p@ mit Updates warten :) [22:55] <wiht> Wir haben jetzt Jabber, wenn ich nicht irre. Brauchen wir noch i2pIM? [22:55] <jrand0m> ja [22:55] <jrand0m> Jabber hat einen Server, der Klartext bekommt. [22:56] <wiht> Oh. Gut, dann; dessen war ich mir nicht bewusst. [22:56] <jrand0m> das sind zwei Minuspunkte (ein Server und Klartext) [22:56] <jrand0m> für manche Dinge ist es allerdings eine gute Lösung, ganz sicher [22:56] <jrand0m> tatsächlich dachte ich heute Morgen, wenn wir i2pIM und i2psnark zusammenführen könnten, wäre das gut. [22:57] <jrand0m> (aber eins nach dem anderen) [22:57] <jrand0m> apropos, 6) i2psnark :) [22:57] <human> jrand0m: ich habe manchmal Jabber mit gnupg benutzt... [22:57] <jrand0m> für Chats mit >2 Personen? [22:58] <jrand0m> für eins zu eins stimme ich völlig zu, da gibt es bestehende Lösungen [23:01] <jrand0m> ok, weiter zu etwas Spaßigem, 7) Einführung von I.Toopie :) [23:01] <human> wie würdest du verschlüsselte Chats mit >2 Personen umsetzen? Einen geteilten privaten Schlüssel? [23:01] <jrand0m> ja, human [23:01] <jrand0m> oder über n! geteilte Schlüssel in der Gruppe [23:02] <human> nun, vielleicht könnte man das über das bestehende Jabber-Protokoll legen... [23:02] <mihi> human: einen gemeinsamen symmetrischen Schlüssel, der an alle Teilnehmer geschickt wird [23:02] <jrand0m> der schwierige Teil sind Joins & Leaves – Schlüsselrotation /etc [23:03] * Sciatica hat IRC verlassen (Ping timeout) [23:03] <jrand0m> das ist keineswegs trivial. Es ist wirklich wirklich wirklich schwer. [23:03] * mihi ackt [23:03] * human stimmt zu [23:04] <jrand0m> (weshalb es sinnvoll sein kann, eine dafür designte App zu haben, statt es über ein anderes Protokoll zusammenzuhacken) [23:04] <jrand0m> aber thecrypto kann seine Pläne am besten beschreiben [23:04] <jrand0m> (obwohl meines Wissens er noch offen für Ideen ist, wie man Gruppen handhabt) [23:05] * Sciatica ist #i2p beigetreten [23:06] <jrand0m> ok, weiter :) [weitere Diskussion auf i2p@, etc] [23:06] <wiht> Was ist aber I.Toopee? [23:06] <lucky> das Maskottchen... [23:06] <jrand0m> I.Toopie ist ein Typ, der sich eine gelbe Maske vors Gesicht hält [23:06] * lucky schaudert. [23:07] <lucky> aha. [23:07] <lucky> kann ich es sehen? [23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo [23:07] * mihi_backup hat IRC verlassen (EOF From client) [23:07] <lucky> ich habe Java in meine Compile-Queue aufgenommen... [23:07] <lucky> aber.. lol [23:07] <lucky> ich habe schon 7 Dinge am Laufen [23:07] <lucky> das wird dauern. [23:08] <lucky> aw, süß :P [23:08] <MrEcho> lol [23:08] <jrand0m> es gab viele coole Logos (ich kann nicht glauben, dass wir den Logo-Wettbewerb seit 3 Monaten laufen haben!), und es sieht so aus, als hätten wir mit I.Toopie starke Chancen. In seiner Einfachheit, seinem Konzept und seiner Vielseitigkeit. [23:08] <jrand0m> und, ja, es ist niedlich ;) [23:08] <mihi> sind einige imgs kaputt oder spinnt mein Browser? [23:08] <jrand0m> ja, einige sind kaputt [23:09] <jrand0m> (sie wurden vor 3 Monaten auf temporären Hosting-Seiten abgelegt) [23:09] <MrEcho> I.Toopies Stab ist jetzt ganz gelb ... [23:09] <MrEcho> letzte Nacht geändert [23:09] <jrand0m> ist er? [23:09] <jrand0m> die Leute sollten dann das WIKI AKTUALISIEREN [23:09] <jrand0m> ;) [23:09] <MrEcho> hehe [23:09] <MrEcho> ich habe das Bild nicht mehr .. sorry [23:10] <wiht> Ich sehe die Bilder mit Opera, aber nicht mit Mozilla aus irgendeinem Grund. [23:10] <jrand0m> du kannst http://img.villagephotos.com/p/2003-10/437060/badass.webp sehen? [23:10] <jrand0m> (das ist eines der Bilder auf der Seite) [23:11] <duck> Access Denied (User Account Disabled) [23:11] <jrand0m> ja, hier auch. [23:11] <MrEcho> ich kann es sehen [23:11] <jrand0m> aber ja, DrWoo hat mit I.Toopie einige kickass Sachen gemacht [23:11] <MrEcho> moz 1.5 [23:11] * soros hat IRC verlassen (EOF From client) [23:11] * mihi_away ist #i2p beigetreten [23:11] * lucky hat IRC verlassen (EOF From client) [23:12] <jrand0m> hier auch, MrEcho. seltsam. [23:12] <wiht> MrEcho: Ich benutze Mozilla 1.4. [23:12] <jrand0m> (hier auch heißt, ich bin auf moz 1.5 und bekomme Access Denied) [23:13] * jrand0m freut sich auf ein Tray-Icon mit i.toopie :) [23:13] <jrand0m> ok, weiter zu 8) Schachserver [23:14] * Sciatica hat IRC verlassen (Ping timeout) [23:14] * ion hat IRC verlassen (Ping timeout) [23:14] <jrand0m> die neueste hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) enthält den Verweis auf chess.fillament.i2p [23:14] <jrand0m> du kannst jeden beliebigen FICS-Client verwenden oder einfach dorthin telnetten und losspielen :) [23:14] <jrand0m> (yay) [23:15] <kaji> gibt es einen guten FICS-Client für Windows? [23:15] <jrand0m> kA, ich habe am Ende telnet benutzt [23:15] <wiht> Funktioniert eboard? [23:15] <jrand0m> (was einen ziemlich steilen Einstieg hatte, um die Befehle zu lernen) [23:15] * ion ist #i2p beigetreten [23:16] <jrand0m> kA [23:16] * BpX ist #i2p beigetreten [23:16] <wiht> Ich probiere es später. [23:16] <jrand0m> cool, wenn du posten könntest, was du herausfindest, wäre das super [23:17] <jrand0m> ok, 9) DHT [23:17] * wilde hat IRC verlassen (Ping timeout) [23:17] <jrand0m> wir haben immer noch keine dht, aber vielleicht ist das ein Ansatz für etwas, das wir zu portieren beginnen können [23:18] <jrand0m> (es nutzt UDP, also wäre es nicht schwer, es auf I2CP zu bringen) [23:18] <MrEcho> dht??? [23:18] <MrEcho> ich steh grad auf dem Schlauch [23:18] <jrand0m> MrEcho> siehe [10] in der E-Mail ;) [23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT [23:18] <Nightblade> entropy ist eine ausreichend gute Übergangslösung [23:18] <jrand0m> einverstanden [23:19] <jrand0m> allerdings denke ich, dass wir auch nach einer langfristigen Lösung suchen müssen [23:19] * soros ist #i2p beigetreten [23:19] * lucky ist #i2p beigetreten [23:20] * human ist besorgt über gcj/kaffe-Kompatibilität mit DHTs wie Bamboo (http://bamboo-dht.org/) [23:20] <jrand0m> ja, bamboo ist 1.4 [23:20] <MrEcho> afk [23:20] <jrand0m> das ist der Ruhm von i2cp – der router & die tunnels können mit gcj gebaut werden, während die Dinge, die darauf zugreifen, sonstwas sein können [23:21] <jrand0m> es ist /rein/ für eine App – nicht als Teil des Kerns [23:21] <jrand0m> ich versuche nur, an Dinge zu denken, die Endnutzern helfen würden, die i2p herunterladen, direkt etwas Nützliches zu tun [23:22] <jrand0m> (in der Lage zu sein, unzensierbare Inhalte anonym zu posten, wäre eine gute nützliche Sache) [23:22] <jrand0m> s/nicht zensierbar/sehr zensurresistent/ [23:23] <human> jrand0m: ah, ok – ich dachte, dass bamboo Kademlia für die NetworkDB ersetzen würde :-) [23:23] <Nightblade> der squid-Proxy ist etwas, was sie tun können... für Nutzer zum Beispiel in China wäre das eine sehr schöne Sache [23:23] <jrand0m> Nightblade> richtig, aber der squid ist nicht skalierbar [23:24] <Nightblade> ja, ich fände eine Art verteiltes JAP interessant [23:24] <jrand0m> einverstanden [23:24] <jrand0m> das ist also auch eine andere Sache, die großartig wäre, wenn Leute sie untersuchen könnten :) [23:24] <mihi> Nightblade: das Problem ist Abuse-Handling – ich öffne meine Kiste nicht für beliebiges ausgehendes http [23:24] <jrand0m> ich bin sicher, manche werden das aber tun [23:25] <Nightblade> mit einem zusätzlichen Teil, wo ein einzelner Node wählen kann, welche Sites er für Leute proxyt... ein Client könnte eine Anfrage für "whitehouse.com" senden und dann kann einer der Nodes, der das Proxying macht und diese URL erlaubt, antworten [23:25] <Nightblade> ja, es müsste irgendeine Art Zugriffssteuerung geben [23:25] <Nightblade> Blacklist oder Whitelist [23:25] <jrand0m> richtig [23:25] <Nightblade> von Domainnamen [23:26] <jrand0m> das ist das "Exit-Policy"-System. Allerdings ist das ein ganzes Projekt für sich [23:27] <MrEcho> es könnte auf dem DNS-System reiten... schätze ich [23:27] <jrand0m> ganz sicher [23:27] <wiht> mihi: Was, wenn du die genutzte Bandbreite limitierst? Oder sind es die aufgerufenen Websites, die dir Ärger machen könnten? [23:27] <MrEcho> zu einem sehr späteren Zeitpunkt lol [23:27] <jrand0m> wiht> viele Provider verbieten explizit das Betreiben jeglicher Server [23:28] <MrEcho> verizon fuckt definitiv mit Port 21... [23:28] <wiht> jrand0m: Oh. Ja, das ist ein Problem. [23:28] <Nightblade> es müsste eine Möglichkeit geben, dass Clients die Sites anfragen, die sie für sich herunterladen lassen wollen.. Broadcast-Anfragen sind keine gute Lösung, besonders auf i2p [23:29] <mihi> wiht: das Problem sind die Websites, die erreichbar sind. Vergleiche die Klage gegen JAP vor einiger Zeit. /me lebt im selben Land [23:29] <jrand0m> einverstanden. Broadcast ist ohnehin nicht möglich, ohne einen ~2^2300-Schlüsselraum mit roher Gewalt zu knacken ;) [23:30] <jrand0m> richtig, mihi, Menschen in repressiven Regimen könnten outproxies nicht sicher betreiben [23:30] <wiht> mihi: Was war die Klage? Ich erinnere mich nicht. [23:30] * dm hat IRC verlassen (Ping timeout) [23:30] <Nightblade> ich meine, selbst wenn man eine Liste von Destinations hätte, die Web-Proxying anbieten, wollte man nicht an alle broadcasten [23:30] <jrand0m> richtig, Nightblade [23:30] <Nightblade> also Request-Broadcast meine ich [23:31] <mihi> das Problem war, dass jemand eine Kinderporno-Seite aufgerufen hatte und es über einen JAP-Proxy ging und sie nicht sagen konnten, woher die Anfrage kam. Das wurde als Behinderung der Polizeiarbeit interpretiert [23:31] <jrand0m> Leute könnten sich Crowds oder Rewebber ansehen, um andere Projekte zu sehen, die an derselben Aufgabe gearbeitet haben [23:31] <wiht> mihi: Ah. Danke für die Erklärung. Ich sehe, verstehe jetzt, dass du besorgt bist. [23:31] * mihi_away hat IRC verlassen (Ping timeout) [23:31] <mihi> und diese Änderung an der jap-Software gemacht, die es ermöglicht, Leute zu fangen. Die später wieder entfernt wurde [23:32] <wiht> Äh, ich verstehe, warum du besorgt bist. [23:32] <mihi> am Ende kam heraus, dass der JAP die Daten nicht offenlegen müsste, aber ich will nicht wissen, was die Anwälte gekostet haben... [23:32] <Nightblade> ja, aber hat die Polizei die Informationen nicht trotzdem beschlagnahmt? [23:32] <jrand0m> ja [23:33] <mihi> haben sie... [23:33] <jrand0m> aber wie dem auch sei, ja, sowohl ein skalierbares DHT als auch ein skalierbarer Web-Proxy wären sehr gute Dinge, die wir bis 1.0 haben sollten [23:34] <mihi> und sie können es nicht zurückgeben, können sie? [23:34] * BpX hat IRC verlassen (Ping timeout) [23:36] * Sciatica ist #i2p beigetreten [23:36] <jrand0m> ok, noch etwas zu Punkt 9? Oder sind wir bei 10/11) NS/DNS? [23:36] <wiht> Ich würde nach Thema 10 gerne einen kurzen Kommentar zum Installer machen. [23:37] <jrand0m> 'k vielleicht nehmen wir das jetzt, da NS/DNS vielleicht nicht ultrakurz ist? ;) [23:37] <wiht> In Ordnung. Der router hat ein Start-Skript und ein Stop-Skript. [23:37] <jrand0m> richtig [23:37] <wiht> Ich hätte gerne, dass alle Dienste so gemacht werden – dass sie sowohl ein Start- als auch ein Stop-Skript haben. [23:37] <jrand0m> die meisten haben das [23:37] <jrand0m> oder? [23:38] <jrand0m> oh, keine Stop-Skripte [23:38] <wiht> Nein, nur der router. [23:38] <wiht> So könnten gewünschte Dienste beim Rechnerstart gestartet werden, genau wie der router. Ich habe dazu einen Beitrag an die Mailingliste gemacht. [23:38] <jrand0m> aum arbeitet an i2pmgr, das sowohl eine konsolenbasierte als auch eine GUI-basierte Schaltzentrale für die Dienste und den router selbst wird [23:38] <wiht> Sagen wir, ich will eep und nntp beim Boot starten. Aktuell kann ich das nicht. [23:39] <jrand0m> richtig, du müsstest nohup startEepProxy.sh & [23:39] <wiht> Übrigens, wo sind diese Skripte in CVS? [23:39] <MrEcho> k ich bin zurück [23:39] * mihi_away ist #i2p beigetreten [23:39] <jrand0m> wiht> die Skripte sind in der Install.java (aka gehackt) [23:39] <wiht> jrand0m: Danke./ [23:40] <jrand0m> aber guter Punkt, wir wollen es so einfach wie möglich machen, beim Boot zu starten, sowie bei Bedarf [23:41] <jrand0m> ok, weiter zu 10/11) ns/dns [23:41] <MrEcho> naja, schau meine E-Mail [23:41] <MrEcho> da sind ein paar Dinge, die ich vergessen habe reinzuschreiben [23:41] <jrand0m> leider ist deine E-Mail nicht wirklich gut in die Weboberfläche gegangen :/ [23:41] <MrEcho> wie "temp"-Namen [23:41] <MrEcho> ?? [23:42] * Sciatica hat IRC verlassen (Ping timeout) [23:42] * ion hat IRC verlassen (Ping timeout) [23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html [23:42] <MrEcho> wegen des Gifs oder so [23:42] <MrEcho> scheiße .. ich habe es signiert [23:43] <MrEcho> sorry [23:43] <jrand0m> die Mailingliste ist eigentlich als Text-only gedacht. pgp-Signaturen sind ok (andere haben signierte Dinge gepostet) [23:43] <kaji> was ist ein gutes kleines kostenloses Antivirus? [23:43] * ion ist #i2p beigetreten [23:43] <jrand0m> kaji> linux [23:43] * Sciatica ist #i2p beigetreten [23:43] <wiht> LOL. [23:43] <kaji> das mit meiner Hardware läuft [23:43] <wiht> kaji: Probier AVG Antivirus für Windows. [23:44] * MrEcho_ ist #i2p beigetreten [23:44] * MrEcho hat IRC verlassen (EOF From client) [23:44] <MrEcho_> fuckign iip [23:44] <jrand0m> MrEcho / (und alle anderen, die am NS/DNS-Thema interessiert sind)> hast du http://zooko.com/distnames.html gelesen? [23:44] <MrEcho_> j, soll ich die E-Mail nochmal senden? [23:44] <jrand0m> sie ist in der Liste gut angekommen, nur im Webarchiv nicht korrekt [23:44] <MrEcho_> ja [23:45] <wiht> jrand0m: Ich habe es noch nicht gelesen. [23:45] <MrEcho_> ich sehe es mir später an [23:45] * mrflibble ist #i2p beigetreten [23:45] <jrand0m> für die, die nicht auf der Liste sind, habe ich MrEcho_'s E-Mail unter http://i2p.dnsalias.net/~jrandom/mrecho_dns.txt gespeichert [23:46] <MrEcho_> danke J [23:46] <kaji> ist ja schwul, es will eine E-Mail-Adresse [23:46] <jrand0m> meine Sorge gilt der Sicherheit und Skalierbarkeit des Namensdienstes. Sobald wir eine Lösung finden, die diese Anforderungen erfüllt, fantastisch, aber bis dahin sollten wir mit Zwischenlösungen vorsichtig sein. [23:47] <jrand0m> kaji> E-Mail-Listen wollen normalerweise eine E-Mail-Adresse, ja ;) [23:47] <kaji> ich meine AVG Antivirus [23:47] <jrand0m> oh ;) [23:48] <wiht> MrEcho hat mehrere gute Ideen, die ich in meiner Spezifikation nicht hatte, wie eine Ban-Liste für schlechte Clients. [23:49] <MrEcho_> nicht wirklich eine Ban-Liste [23:49] <jrand0m> wenn es 1000 Clients gibt, heißt das, dass 125 Lookups nötig wären, um einen Wert zu finden? [23:49] <MrEcho_> nein [23:49] <wiht> Keine Liste, aber das Bannen schlechter Clients hatte ich nicht. [23:50] <MrEcho_> 2-4 Clients zum Prüfen [23:50] <jrand0m> also hat jeder Client 250 Einträge? [23:50] * mihi_away heißt jetzt mihi_backup [23:50] <MrEcho_> nein [23:50] <wiht> In dem, was ich habe, wäre es ein Lookup, eventuell ein paar Mal weitergeleitet, um einen autoritativen Server zu erreichen. [23:50] <MrEcho_> Clients werden nur haben, was sie brauchen [23:51] <MrEcho_> er wird andere Clients weiter abfragen, bis sie Daten bekommen, die für die Prüfung passen [23:51] <jrand0m> also bei 4 Peers würde es eine zufällige Suche machen, und im Schnitt würde es 125 Lookups benötigen [23:51] <jrand0m> (1000/4/2) [23:51] <jrand0m> oder sind die Peers ein DHT? [23:52] <jrand0m> (mit irgendeinem Maintenance-Protokoll?) [23:52] <jrand0m> oder ein Suchbaum? [23:52] <MrEcho_> in gewisser Weise ja [23:52] <MrEcho_> ich werde einen Cutoff bei Client-Suchen haben, dann fragt es einfach den MS ab [23:53] <jrand0m> sichere verteilte Namensgebung ist ein ziemlich gut untersuchtes Problem – was deinen Vorschlag einfacher analysierbar machen würde hinsichtlich Sicherheit und Skalierbarkeit, wäre, wenn du Vergleiche ziehen und Varianten anderer Ansätze validieren könntest, vielleicht? [23:54] <MrEcho_> wenn es innerhalb eines gesetzten Bereichs nicht genug Daten von Clients findet/bekommt, fragt es dann einfach den MS ab. [23:54] <jrand0m> so wie es ist, gibt es nicht genug Details, als dass ich Vertrauen in die Skalierbarkeit oder Sicherheit der Architektur hätte. Nicht, dass es nicht gut funktionieren könnte, ich sehe nur noch nicht, dass es so wäre. [23:54] <MrEcho_> kannst du kurz aufhören zu tippen [23:54] * jrand0m hört auf zu tippen. [23:55] <MrEcho_> es wird funktionieren .. es wird Skalierbarkeit haben, es wird Sicherheit haben [23:56] <MrEcho_> je mehr Nutzer, desto besser wird es [23:56] <jrand0m> also "vertrau mir", was? [23:56] <MrEcho_> vertraust du dem Internet-DNS-System? [23:56] <jrand0m> für manche Aufgaben. [23:57] <jrand0m> für viele nicht. [23:57] <jrand0m> (es ist ziemlich einfach für Regierungen / etc., Einträge ändern zu lassen – Gerichtsverfahren ordnen ständig an, dass Registrare aktualisieren) [23:58] <MrEcho_> die einzige andere Art, es zu machen, ist, große Listen von Namen zu haben und jede Menge Krypto auf jedem Client [23:58] <MrEcho_> und dynamisch sein .. vergiss es [23:59] * mrflibble hat IRC verlassen (EOF From client) [23:59] <jrand0m> Ich schlage vor, zookos Papier zu lesen, bevor wir weiter vorgehen, und seinen letzten Punkt 5 zu beantworten ("warum ich Unrecht habe") Session Time: Wed Jan 07 00:00:00 2004 [00:01] <jrand0m> ok, das war's wahrscheinlich zu Punkt 10/11 (viel künftige Diskussion bleibt natürlich) [00:02] <jrand0m> hat noch jemand andere Gedanken, etc? [00:02] <wiht> Ja. [00:03] <jrand0m> magst du sie mit der Klasse teilen? :) [00:03] <wiht> Ich werde die Spezifikation, die ich geschrieben habe, neu schreiben. Ich möchte einen lokalen SQL-Server verwenden, um Daten zu speichern, keine Dateien. [00:03] <jrand0m> ah cool [00:03] <jrand0m> (dieselben Bedenken gelten für die Spez, die du geschrieben hast – wenn du zookos letzte Frage beantworten könntest, wäre das entscheidend :) [00:03] * mrflibble ist #i2p beigetreten [00:03] <wiht> Lass MySQL oder einen ähnlichen Server die Datenspeicherung verwalten und lass Java diesen Server abfragen. [00:04] <duck> huh ? zooko-Spez? [00:04] <wiht> Ich denke, das wird leichter zu implementieren. [00:04] <jrand0m> duck> nee, ich verweise Leute nur auf seinen alten Artikel "Names: Decentralized, Secure, Human-Meaningful: Choose Two" [00:04] <duck> ah den [00:04] <Nightblade> wiht: welche Spezifikation ist das (ich habe viel vom Meeting verpasst)? [00:04] * MrEcho ist #i2p beigetreten [00:04] <jrand0m> (viel einfacher, als zu wiederkäuen, warum Supernode/zentralisierte Server gruselige Sicherheitsprobleme sind ;) [00:05] * MrEcho_ hat IRC verlassen (EOF From client) [00:05] * mihi hätte auch etwas für das Log ;) [00:05] <mihi> etwas Längeres ;) [00:05] <mihi> *** I2Ping-Ergebnisse: [00:05] <mihi> + + + eco.i2p [00:05] <mihi> + - - jabber.duck.i2p [00:05] <mihi> - + + i2pcvs.i2p [00:05] <mihi> - + + duck.i2p [00:05] <mihi> - + - jap.eco.i2p [00:05] <jrand0m> Nightblade> es wurde im iip-dev gepostet, zurück in... August? [00:05] <mihi> - + + irc.duck.i2p [00:05] <mihi> - + + human.i2p [00:06] <mihi> - - + nntp.duck.i2p [00:06] <mihi> - - - tc.i2p [00:06] <mihi> - - - dyad.i2p [00:06] <mihi> - - - bozo.i2p [00:06] <mihi> - - - ogg.aum.i2p [00:06] <mihi> - - - fcp.entropy.i2p [00:06] <mihi> - - - http.entropy.i2p [00:06] <Nightblade> jrandom: oh, vor meiner Zeit.. :) [00:06] <mihi> - - - www.mail.i2p [00:06] <mihi> - - - mp3.aum.i2p [00:06] <mihi> - - - smtp.mail.i2p [00:06] <wiht> Nightblade: Ich habe es am 15. September gepostet. [00:06] <mihi> - - - pop.mail.i2p [00:06] <mihi> - - - mp3.tc.i2p [00:06] <mihi> - - - lp.i2p [00:06] <mihi> - - - kaji.i2p [00:06] <mihi> - - - nm.i2p [00:06] <mihi> - - - squid.i2p [00:06] <mihi> - - - chess.fillament.i2p [00:06] <mihi> - - - mesh.firerabbit.i2p [00:06] <mihi> - - - nightblade.i2p [00:06] <mihi> - - - aum.i2p [00:06] <MrEcho> gezz ist überhaupt jemand am Laufen? [00:06] <mihi> - - - fillament.i2p [00:06] <mihi> *** Fertig. [00:06] <mihi> warum sind so viele Hosts down...? [00:06] * jrand0m betreibe meine Server gerade nicht [00:07] <FillaMent> Ich kann mich sowohl auf eep als auch auf chess mit mir selbst verbinden [00:07] * mrflibble hat IRC verlassen (Ping timeout) [00:07] <jrand0m> oh warte, i2pcvs ist up, nett [00:07] <Nightblade> mihi: meiner ist nicht up, weil der i2ptunnel bei mir nach ein paar Stunden abstürzt [00:07] <mihi> also ist mein router kaputt (oder es sind die üblichen I2P-Probleme...) [00:08] <jrand0m> wirklich, Nightblade? Bitte i2ptunnel-Abstürze melden (bugzilla wäre schön) [00:08] <Nightblade> ist im bugzilla [00:08] <lucky> hi [00:08] <Nightblade> Moment.. [00:08] <FillaMent> Nightblade: welche JVM? [00:08] <Nightblade> #39 [00:08] <wiht> Mein router läuft seit mehr als 12 Stunden, obwohl er ein Problem hatte, sich zu registrieren. [00:09] <Nightblade> java version "1.4.2-p5" [00:09] <Nightblade> auf freebsd... könnte ein JVM-Problem sein, ich weiß nicht. Java-Support ist auf freebsd nicht so gut [00:09] <jrand0m> du hast recht, Nightblade, mein Fehler [00:09] <jrand0m> das ist der ziemlich seltene i2cp-Bug [00:09] <jrand0m> ist das bei dir konsistent? [00:09] <Nightblade> der router ist bei mir sehr stabil, nur der i2ptunnel server tunnel macht mir Probleme [00:09] <Nightblade> ja, ist mehrere Male passiert [00:10] <Nightblade> ich habe es aber kürzlich nicht probiert [00:10] * jrand0m hat fillament's eepsite gezogen [00:10] <jrand0m> (Beim ersten Versuch, habe gerade gesehen, dass das Fenster fertig war) [00:10] <FillaMent> Ja,, ich habe gerade mit duck gejabbert, wiht versucht, chess zu erreichen [00:10] <jrand0m> ah cool [00:10] <jrand0m> aber ja, es gibt noch Zuverlässigkeitsprobleme im Netzwerk zu lösen. [00:10] * FillaMent stupst Leute mit dem beiliegenden Zwinkern an, "Er wird wahrscheinlich spielen wollen." [00:10] * human 's eepsite ist noch up – heißt, dass 'killall java' wirklich geholfen hat... :-) [00:10] <wiht> Ich habe mich gerade erfolgreich zum Schachserver verbunden. [00:10] <duck> ja? [00:11] <jrand0m> lol FillaMent [00:11] * mrflibble ist #i2p beigetreten [00:12] <Nightblade> ist es sicher, die CVS-Version von i2p zu laufen [00:12] <jrand0m> /me holt erfolgreich human's 1984-2004: twenty years of GNU! :-) [00:12] <jrand0m> ja, Nightblade [00:12] <FillaMent> konnte eco nicht bekommen... [00:12] <Nightblade> ok, vielleicht probiere ich das [00:12] <duck> mit freenet solltest du immer die neueste CVS-Version laufen lassen! [00:13] <duck> nur dann ist es bugfrei [00:13] <duck> s/freenet/i2p/ [00:13] * jrand0m hat eco.i2p gezogen [00:13] <FillaMent> habe gerade duck bekommen [00:13] <jrand0m> "Jan 4: Erster Feldtest von I2PSnark. Ziemlich katastrophal: gar kein Transfer. Schätze, meine Einzel-router-Testumgebung war nicht sehr repräsentativ :-) Zurück ans Reißbrett... " [00:13] <jrand0m> d'oh [00:13] <duck> naja, es hat eigentlich funktioniert [00:13] <duck> ardvark konnte etwas von mir snarken [00:14] <jrand0m> bt legt die Dateien vorab an – waren die Dateien tatsächlich gültig? [00:14] <duck> aber ze hat es am nächsten Tag herausgefunden [00:14] <duck> weil es in den Logs verschleiert war [00:14] <jrand0m> was, du meinst, die Logs, die i2p generiert, sind ziemlich irre? nawwwwww [00:14] <duck> nein [00:14] <duck> die i2psnark-Ausgabe [00:14] <jrand0m> ah [00:15] <duck> zusätzlich vermute ich, dass snark zu viel churnt (sp?) [00:15] <duck> der normale Bittorrent-Client scheint einfacher zu sein [00:15] <duck> auch die hohen Verzögerungen auf i2p könnten zu verfrühten Blöcken führen [00:16] * mrflibble hat IRC verlassen (Ping timeout) [00:16] <duck> Letztes ist, dass wir i2ptunnel ein paar Mal neu starten mussten :/ [00:16] <jrand0m> einverstanden [00:16] <human> letzte Frage zu I2PTunnel / I2PTunnelManager (ja, ich weiß, ich bin langweilig): was ist mit meinem Patch, der "openclient" und "openserver" eine aussagekräftige jobId zurückgeben lässt? [00:16] <jrand0m> also, ja, viel Arbeit zu tun [00:16] <human> 1. Lass uns ihn annehmen, damit der TunnelManager funktioniert, bis die neue asynchrone Architektur rockt [00:17] <human> 2. dein Patch ist kompletter Mist, verpiss dich, und scheiß auf den TunnelManager [00:17] <human> 3. ... [00:17] * MrEcho_ ist #i2p beigetreten [00:17] * mihi ist für 3 ;) [00:17] * MrEcho hat IRC verlassen (EOF From client) [00:17] <jrand0m> 4. schauen wir, wie wir den TunnelManager auf async updaten können? Sollte nicht zu schwer sein [00:17] <jrand0m> der Patch ist gut, aber mihi hat einen Punkt [00:18] <human> jrand0m: ja, ich stimme zu [00:18] <jrand0m> wir haben immer noch 1+ Wochen bis 0.3, also haben wir Zeit bis zum nächsten vollen Release [00:18] <human> jrand0m: aber meine Frage ist: wie lange wird es dauern, bis die Async-Schnittstelle im TunnelManager implementiert ist? [00:18] <jrand0m> tunnelmanager selbst waren 2 Stunden, ich könnte Async heute Nacht hinzufügen [00:19] <jrand0m> (alles, was passieren muss, ist ein Update am BufferedLogging, um .set-Aufrufe zu akzeptieren) [00:19] <human> jrand0m: (mit "zu haben" meine ich auch "in I2PTunnel implementiert zu haben) [00:19] <jrand0m> (oder .nofity/etc) [00:19] <jrand0m> richtig [00:19] * mrflibble ist #i2p beigetreten [00:20] <jrand0m> wenn du magst, könnte ich mit deinem Patch anfangen (der die Job-ID hinzufügt) und ihn mit den Updates für Async mergen [00:21] <human> jrand0m: ich könnte die Async-Schnittstelle selbst zum TunnelManager hinzufügen, aber die Schnittstelle existiert noch nicht :-) [00:22] <jrand0m> richtig, füge einfach public void notifyEvent(String eventName, Object value); zu Logging.java hinzu [00:22] <human> jrand0m: ich würde vorschlagen "lass uns den schmutzigen Hack mergen, um die Job-IDs im 0.3-Release halbwegs zum Laufen zu bringen, und dann an der Async-Schnittstelle arbeiten" [00:23] <jrand0m> 0.3 ist noch ein Stück weg [00:23] <mihi> 0.3 sollte die Streaming-API ohnehin haben, oder? [00:23] <human> jrand0m: ich rede vom Worst Case [00:23] <wiht> jrand0m: Vielleicht sollte es eine weitere Version vor 3.0 geben, um diese Themen zu klären? [00:23] <jrand0m> ja, mihi [00:23] <mihi> human: der Worst Case ist "cvs rollback && patch -p0 your.patch" [00:24] <jrand0m> ok, wie wäre es damit. Ich implementiere Async und committe es heute Nacht, wenn du dir das morgen ansehen könntest, human, und schaust, was getan werden muss, um dein Update da reinzubekommen? [00:26] <FillaMent> jrand0m: hast du einen Job? [00:27] <jrand0m> i2p [00:27] <duck> mach 1.0 fertig! [00:27] <FillaMent> Ich meine eine Einkommensquelle [00:27] <jrand0m> :) [00:27] <FillaMent> für die du arbeiten musst [00:27] <jrand0m> Einkommen ist überbewertet. [00:27] * jrand0m hat meinen Chef gefeuert [00:27] <Nightblade> "will code for food" - das ist mein Motto [00:27] <Nightblade> lol [00:27] <human> mihi: nun, aber ich und aum (der an einer Python-App für den TunnelManager arbeitet) hätten gerne ASAP JobIDs... [00:28] <human> jrand0m: ok, ich arbeite später/morgen an deinen Änderungen [00:28] <FillaMent> Job/Geld, Schlaf/Hygiene, Essen, Nebenprojekte, Sozialleben: Wähle beliebige 3 [00:29] * jrand0m wählt nur eins. [00:29] <jrand0m> word human [00:30] <FillaMent> Hat jemand andere Ideen für "einfach tunnel zu"-Dienste, die im Netzwerk nett wären? [00:30] * jrand0m will immer noch ein telnet-basiertes Adventure :) [00:30] <jrand0m> oder ein Waffle-BBS [00:30] * duck heißt jetzt enduser [00:30] * jrand0m tritt enduser [00:31] <jrand0m> (verdammt, keine Ops) [00:31] <FillaMent> Für OS/2 gab es einen Comm-Treiber, der einen COM-Port auf einen TCP-Port mappen konnte =) [00:31] <enduser> welchen Unterschied werde ich als enduser sehen, wenn I2PTunnel die SteamingAPI verwendet? [00:31] * enduser heißt jetzt duck [00:31] <jrand0m> keinen [00:31] <human> lol [00:31] <FillaMent> FillaMent: ein Freund von mir hat eine Weile lang so ein BBS betrieben [00:31] <jrand0m> Performance, und vielleicht Anonymität [00:31] * human hätte gerne einen I2P-Tunnel zu einer rootshell [00:32] <human> Freiwillige? :-) [00:32] <duck> rootshell auf einer UML [00:32] <jrand0m> gechrootete rootshells wären gut [00:32] <jrand0m> oder UML'ed :) [00:32] <FillaMent> human: hätte ich eine Kiste übrig, würde ich es tun [00:32] <jrand0m> hehe FillaMent [00:32] <duck> vnc-Verbindung zu meinem vmware win98? [00:32] <FillaMent> ernsthaft, Leute... [00:32] <wiht> E‑Mail-Server wäre auch gut. Oder haben wir das schon? [00:32] <FillaMent> wiht: denke, TC hat pop und SMTP [00:33] <jrand0m> das ist aum, aber die sind offline, da seine Kiste offline ist [00:33] * human könnte Telnet-Accounts auf seinem GNU/Hurd-System anbieten... [00:33] <jrand0m> ooOOoo [00:33] <FillaMent> naja, ich bin nicht so scharf darauf, offenen SMTP-Zugang einzurichten [00:33] <jrand0m> verständlich [00:34] <FillaMent> vielleicht wenn das Netzwerk stabiler ist und ich Geld habe, meine Bandbreite zu erhöhen [00:34] <wiht> Wie wäre es mit einem PGP-Keyserver? [00:34] <mihi> FillaMent: du könntest einen Tunnel einrichten, der auf einen Klartext-Remailer zeigt [00:34] <FillaMent> wiht: das ist jetzt eine großartige Idee =) [00:35] <FillaMent> mihi heh... ich könnte den Tunnel einfach auf die SMTP-Box meines ISP zeigen =) [00:35] <mihi> FillaMent: das würde *dich* für Abuse verantwortlich machen... [00:35] <mihi> s/be// [00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html [00:36] <duck> ernsthaft, sollte duck enterprises einen pgp-Keyserver betreiben? [00:37] <FillaMent> duck: ich habe da selbst reingeschaut... willst du es übernehmen? [00:37] <duck> wir waren einer der stabilsten Service-Provider laut mihis unabhängigen Ping-Logs [00:37] <jrand0m> hehe [00:37] <wiht> duck: Ja, bitte zieh es in Erwägung. [00:37] <jrand0m> btw duck, wie machst du das? Startest du periodisch neu oder läufst du nur auf einem zuverlässigen OS und einer zuverlässigen JVM? [00:38] <FillaMent> Frage: cached die JVM DNS-Resolves? [00:38] <duck> Neustart ist für Kernel-Updates [00:38] <jrand0m> ja, aber du kannst ein bisschen fiese Tricks nutzen, um es zu vermeiden, FillaMent [00:38] * wiht stellt fest, dass das Meeting jetzt seit 2h40m läuft. [00:38] <jrand0m> oh ja, [00:39] * mrflibble hebt die Hand [00:39] <jrand0m> ähm, das Log dieses Meetings wird riesig. Und ich dachte, Dinge vorab zu posten würde das Meeting /verkürzen/ [00:39] <jrand0m> was gibt's, mrflibble? [00:39] <FillaMent> jrand0m: ok... weil ich ohne Ausfall bin, aber meine IP ändert sich periodisch... mein dyndns-Update-Skript läuft jede Stunde, also max 60+~10 Min, in denen meine benannte Addy nicht auf meine IP zeigt... [00:39] <FillaMent> wie würde das die Präsenz meines routers im Netzwerk beeinflussen? [00:40] <mrflibble> meine Kiste könnte für irgendein dämoniges Ding verfügbar sein [00:40] <jrand0m> cool, FillaMent, sollte kein großes Problem sein, solange du auf dein dyndns zeigst [00:40] <wiht> mrflibble: demony? [00:40] <mrflibble> ich schätze, es hängt davon ab, wie viel Bandbreite das Ding verbrauchen würde [00:40] <mrflibble> daemony [00:40] <jrand0m> w3rd mrflibble – läuft der router zuverlässig bei dir, oder bist du einfach ein guter Samariter? :) [00:41] <mrflibble> nicht wirklich, aber das liegt daran, dass meine lokale BW gerade gesättigt ist [00:41] <mrflibble> ich lasse es noch nicht auf meinem Colo laufen [00:41] <mrflibble> will zuerst lokal damit herumspielen [00:41] <jrand0m> ah cool. ja, i2p ist noch nicht wirklich für den breiten Einsatz bereit, noch hauptsächlich zum Testen [00:42] <FillaMent> Heh.. ich richte einen Tunnel zu meinem CUPS-Server ein und ihr könnt anonym drucken =) [00:42] <jrand0m> rofl [00:42] <mrflibble> wenn es etwas gibt, das du willst, dass ich es laufen lasse und das <40gb Bandbreite im Monat nutzt, sag Bescheid [00:42] <FillaMent> einfach eine Bannerseite beilegen, damit ich weiß, wohin ich den Ausdruck schicken soll =) [00:42] <mrflibble> hehe [00:43] <jrand0m> wikked mrflibble, ich bin sicher, wir kommen darauf zurück :) [00:43] <mihi> banner | lpr ? ;) [00:43] <FillaMent> mihi du kannst CUPS mit einer Bannerseite konfigurieren [00:43] <mrflibble> oky doky! [00:43] <mihi> banner wird höchstwahrscheinlich viele Seiten erzeugen ;) [00:43] <jrand0m> ok, bevor wir zur Mixminion->Printer->Postamt-Gateway-Diskussion kommen, schließen wir dieses Meeting ;) [00:44] * jrand0m macht den *baf*'er bereit [00:44] * jrand0m *baf*t das Meeting geschlossen.