I2P-Entwicklertreffen - 8. März 2005

13:06 <@jrandom> 0) hi 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) mail.i2p-Updates 13:06 <@jrandom> 3) i2p-bt-Updates 13:06 <legion> also hängt es mit den IRC-Servern zusammen? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) hi 13:06 <@jrandom> Wöchentliche Statusnotizen online @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> hi 13:07 <+postman> hi 13:07 <frosk> Guten Tag 13:07 <@jrandom> legion: nein, bezogen auf I2P-Bugs, wird daran gearbeitet 13:07 <bla> hi 13:07 <legion> ok 13:07 <@jrandom> Apropos Bugs, an denen gearbeitet wird, springen wir rein zu 1) 0.5.0.2 :) 13:07 <cervantes> 'lo 13:07 <cervantes> -- Verbindung getrennt 13:08 <@jrandom> heh 13:08 <ant> <mihi> hallo zusammen 13:08 <@jrandom> 0.5.0.2 ist draußen, und auch wenn eure IRC-Verbindung manchmal laggt, fängt sie sich wieder ;) 13:08 <@jrandom> Whoah, hey, mihi 13:09 <cervantes> hey mihi 13:09 <@jrandom> Die Statusnotizen geben einen allgemeinen Überblick, wo wir stehen und was die dringendsten Prioritäten sind 13:10 <@jrandom> Das Beunruhigende, dem ich nachgehe, kann man hier sehen: http://localhost:7657/oldstats.jsp#router.invalidMessageTime 13:10 <bla> Für meinen Teil kann ich sagen, dass 0.5.0.2 die Zuverlässigkeit im Vergleich zu 0.5.0.1 bereits _enorm_ verbessert hat: Fehler, bei denen Ziele nicht kontaktiert werden konnten, treten fast nicht mehr auf 13:10 <@jrandom> Diese Zahlen sollten eigentlich sehr, sehr klein sein, sind es aber leider nicht 13:10 <@jrandom> krass, bla 13:11 <@jrandom> Ja, 0.5.0.2 ist definitiv eine Verbesserung, und alle sollten so schnell wie möglich updaten 13:11 <bla> 375.932,22 in den letzten 10 Minuten hier.... 13:11 <@jrandom> Nun, der konkrete Wert ist nicht wirklich das Problem, sondern die Häufigkeit 13:11 <@jrandom> (Ereignisse pro Zeitraum) 13:12 <@jrandom> Diese Meldungen lassen sich wahrscheinlich 0.5-Routern zuschreiben, und zum Teil 0.5.0.1-Routern, weshalb ich möchte, dass die Leute so schnell wie möglich upgraden 13:12 <@jrandom> Es kann allerdings auch etwas anderes sein, aber das möchte ich ausschließen 13:12 <bla> jrandom: Ich bekomme hier etwa 200 pro Stunde 13:13 <@jrandom> bla: Ich habe aktuell 93 in dieser Stunde, aber die Spitzenzahl ist viel höher (tausende) 13:13 <@jrandom> Wie auch immer, diese spezielle Statistik wird in der netdb veröffentlicht 13:13 <bla> jrandom: Wie wäre es, 0.5-0 softwareseitig aus dem Netz auszuschließen, wenn 0.5.0.3 erscheint? 13:14 <@jrandom> So können wir uns alle umschauen und sehen, welche Werte andere haben ;) 13:14 <@duck> 309.854,24 Spitze 5.473.314,59 13:15 <@duck> den falschen eingefügt, was 13:15 <@jrandom> bla: auf jeden Fall. Ich habe in der 0.5.0.2-Revision etwas Code hinzugefügt, um etwas Forward-Kompatibilität zu ermöglichen, die 0.5.0.1 und 0.5 nicht haben 13:16 <@jrandom> duck: schwer, eine nicht-ganzzahlige Anzahl von Ereignissen zu haben ;) 13:16 <bla> jrandom: Gut. Zumindest erlaubt dir das, deine Hypothese „ungültige Nachrichten kommen von 0.5-0“ unter kontrollierten Bedingungen zu testen 13:16 <@jrandom> bla: ja, wobei es großartig wäre, wenn die Leute vorher updaten ;) 13:17 <@jrandom> (also für alle Daheimleser: http://www.i2p.net/download ist euer Freund ;) 13:17 <maestro^> jr: diese Zahlen für router.invalidMessageTime sind Abweichungen in ms? 13:17 <@jrandom> maestro^: ja 13:18 <@jrandom> (sprich: einige extrem verzerrte Werte) 13:18 <legion> Hier ein kleiner Netzwerkbericht [Version|Anzahl Knoten][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> ja, ihr wart großartig beim Updaten 13:18 <legion> Also laufen noch ein paar Leute auf 0.5 und viele auf 0.5.0.1 13:18 <maestro^> irgendeine Idee, wo sie hängen könnten? 13:18 <bla> jrandom: Freenet hat in jeder Version ein Flag, das die minimale Node-Version angibt, mit der es kommuniziert. Ist der neue Forward-Compat.-Code so etwas in der Art? 13:19 <@jrandom> maestro^: viele, viele Ideen, warum 0.5- und 0.5.0.1-Nutzer laggen. 13:19 <@jrandom> bla: ähnlich 13:19 <maestro^> oder ist es Clock-Drift auf den Nodes? 13:20 <@jrandom> maestro^: Clock-Skew, einige Serialisierungs-Bugs, der 100%-CPU-Bug 13:20 <@jrandom> ok, das ist generell mein Fokus im Moment, die Zuverlässigkeit der Nachrichten wieder hochzubekommen 13:21 <@jrandom> Hat jemand Fragen/Kommentare/Bedenken zu 0.5.0.2? 13:21 <ant> * mihi hat hier einen 0.4.2.5-Router auf der Platte, seit dem 22. Dezember nicht gestartet... aber er denkt, er löscht den besser... 13:21 <@jrandom> heh 13:21 <@jrandom> ja, der wird nicht mit allzu vielen Routern reden ;) 13:21 * postman hat eine Sicherungskopie seiner letzten 0.4-Installation :) 13:21 <ant> <mihi> die Frage für mich wäre Upgrade oder Löschen. 13:22 <@jrandom> löschen 13:22 <@jrandom> (Ziel-Schlüssel vorher sichern) 13:22 <@jrandom> Es gibt keine Upgrade-Prozedur mehr von vor-0.5 13:22 <legion> Vielleicht wäre es gut, ein weiteres Update, sagen wir 0.5.0.2-1, zu veröffentlichen, das nur Verbindungen von 0.5.0.2 oder neuer zulässt? 13:22 <@jrandom> legion: das würde das Netzwerk segmentieren 13:22 <@jrandom> die Leute sollten einfach upgraden. 13:23 <@jrandom> (und wir sollten die, die es nicht tun, umschiffen) 13:24 <legion> ja, bis die Leute mit veralteten Nodes updaten ;) 13:24 <@jrandom> Die Segmentierung des Netzwerks schadet uns allen, nicht nur ihnen 13:25 <legion> Vielleicht, wenn es eine Update-Benachrichtigung in der Router-Konsole gäbe oder so, die ihnen sagt, dass sie veraltete Versionen laufen haben? 13:25 <@jrandom> ja, das wäre auf jeden Fall ziemlich cool 13:25 <@jrandom> hoffentlich lässt sich das auch mit dem Updater verknüpfen 13:26 <legion> ja, ich weiß, Segmentierung ist schlecht... 13:26 <@jrandom> smeghead arbeitet an einigen Schlüsselkomponenten davon, allerdings weiß ich nicht, ob das auch die Benachrichtigung/den Download umfasst 13:26 <@jrandom> (also wenn jemand daran mitarbeiten will, meldet euch!) 13:27 <@jrandom> ok, weiter zu 2) mail.i2p-Updates 13:27 <@jrandom> postman: ping 13:27 <+postman> ja 13:27 <bla> jrandom: smeghead hat meines Wissens (IIRC) was zum Signieren gemacht (damit man bei einer Update-Meldung wenigstens weiß, dass sie echt ist und kein Phishing/Spyware/Schrott) 13:28 * postman übernimmt das Mikro 13:28 <legion> hmm, vielleicht wenn es eine eingebaute Auto-Update-Funktion gäbe, bei der Updates über i2p geladen werden und die Nodes einfach das Update herunterladen und dann einen sanften Neustart machen. 13:28 <@jrandom> genau, bla 13:28 <ant> <Gatak> Oh, btw. Würde I2P hinter NAT funktionieren, selbst wenn man keinen Port öffnen kann? 13:28 <@jrandom> Gatak: noch nicht. Manche werden es mit 0.6 können, andere mit 2.0 13:29 <@jrandom> legion: Patches willkommen 13:29 <ant> <Gatak> 2.0, verdammt, das ist weit in der Zukunft =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> ähm, soll ich jetzt anfangen? 13:29 <aum> morgen zusammen 13:30 <@jrandom> das Mikro gehört ganz dir, postman (sorry ;) 13:30 <@jrandom> 'lo aum, doch noch zum Meeting geschafft 13:30 <@jrandom> (d’oh! /me hält wieder den Mund) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> Zuerst wollte ich sagen, dass wir bei postman.i2p bereits 300 registrierte Accounts erreicht haben 13:30 <@jrandom> w00t 13:30 <+postman> Die Anzahl der Mails von/ins Internet wächst stetig und beweist einmal mehr, dass wir weiter vorankommen müssen 13:31 <cervantes> *quiiietsch* 13:31 <+postman> Nachdem ich vor einigen Wochen mit jr gesprochen habe, haben wir vereinbart, v2mail zusammen mit I2P 1.0 zu veröffentlichen 13:31 <+postman> Aktueller Stand: Der Java-basierte SMTP-Proxy, der auf jedem Node laufen soll, ist fertig 13:31 <@jrandom> schön! 13:32 <+postman> Der Java-basierte POP3-Proxy ist bei 80 %, es fehlt nur noch die Maildir-Engine 13:32 <+postman> Es wird einen Web-Manager geben, der noch stark getuned werden muss (15 % fertig) 13:32 <+postman> Die Inter-Node-Kommunikation ist bei 40 % - wir haben etwas Datensatz-Austausch mit HTTP/XML getestet 13:33 <+postman> scheint recht gut und sogar schnell zu funktionieren 13:33 <+postman> selbst wenn ein Relay-Node ausfällt/über ein paar Tage ausgeschaltet war, wird er innerhalb weniger Minuten nach dem Wieder-Online-Gehen synchronisiert 13:33 <@jrandom> krass 13:33 <+postman> ich denke, wir sind ziemlich auf Kurs 13:34 <+postman> Eine Sache ist bemerkenswert 13:34 <bla> postman: Gute Arbeit, Mann! Eine Frage: Viele Nodes können auf Port 25 nicht empfangen oder senden (jedenfalls nicht direkt). Können Node-Betreiber das angeben (oder wird das automatisch erkannt)? 13:34 <cervantes> cool 13:34 <+postman> bla: später 13:34 <+postman> in v2mail wird es eine lokal laufende Web-App geben 13:34 <+postman> damit kannst du deine lokalen Proxys verwalten UND einen „Relay-Account“ beantragen 13:35 <+postman> Dieser Relay-Account wird dann genutzt, um deine Adresse/Domain den Relays zuzuordnen 13:35 <+postman> die Relays synchronisieren die Informationen automatisch 13:35 <@jrandom> cool 13:35 <+postman> Sogar Funktionen wie das Adressbuch/öffentliche Schlüssel und so weiter werden über das LOKALE Interface funktionieren 13:36 <+postman> Die Idee ist also, einen zentralen Manager zu haben, in dem du all deine Mail-Sachen erledigen kannst 13:36 <+postman> Relevante Daten werden an EIN Relay übertragen und anschließend zwischen den Relays synchronisiert 13:36 <+postman> und dieser webbasierte Manager läuft auf deinem eigenen Node 13:37 <+postman> Wenn dein Node online ist, liefern die Relays Mails aus, die für deine Destination/Domain/Adresse in der Warteschlange stehen 13:37 <+postman> sie werden an deinen lokalen SMTP-Proxy zugestellt 13:37 <+postman> du kannst das Ganze sogar mit ETRN triggern :) 13:37 <aum> nochmal hi 13:37 <aum> ich würde gern einen Diskussionspunkt in diesem Meeting ansprechen, wenn’s ok ist 13:37 <+postman> soviel zur Zukunft, Leute :) 13:37 <+postman> . 13:38 <@jrandom> klingt verdammt gut, postman 13:38 * postman gibt das Mikro zurück 13:38 <@jrandom> aum: super, dafür sollte es Zeit bei 4) geben 13:38 <+postman> ja, ich bin aus dem Häuschen :) 13:38 <@jrandom> postman: also für den normalen Nutzer: Der SMTP-Proxy hat das lokale Maildir, und der POP3-Proxy liest usw., richtig? 13:39 <+postman> ja, der SMTP-Proxy hat ein MDA 13:39 <+postman> und wird die Mail in lokale Maildirs zustellen 13:39 <+postman> es können sogar mehrere Accounts/Benutzer lokal angelegt werden 13:39 <cervantes> postman: werden die Relays deine Quotas etc. nachhalten und solche Infos untereinander propagieren? 13:39 <+postman> und den Accounts deiner Domain zugeordnet 13:39 <+postman> cervantes: ja, werden sie 13:39 <septu_ssh> sorry, kann ich postman nach Zahlungs-/Anti-Spam-Mechanismen im neuen Modell fragen? 13:40 <+postman> septu_ssh: hast du irgendwelche Dokumente auf der Webseite gelesen? 13:40 <+postman> cervantes: es ist nicht perfekt in Echtzeit 13:40 <+postman> cervantes: aber ich bin mit einer Aktualisierung des Quota-Austauschs alle paar Minuten einverstanden 13:40 <septu_ssh> postman: steht auf der Leseliste :/ 13:40 <septu_ssh> aber wenn es dokumentiert ist, ist es ok 13:40 <cervantes> postman: ja, dachte ich mir 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: das ist wirklich kein Drama – das Quota ist eine vernünftige Grenze 13:41 <cervantes> postman: selbst wenn jemand nRelays * Quota Empfänger schicken kann, ist das keine schlimme Sache 13:41 * septu_ssh ist bungle 13:41 <+postman> cervantes: jup 13:42 <+postman> Ziel ist nur, jeden davon abzuhalten, den Dienst wirklich zu missbrauchen 13:42 <+postman> in den Tests, die ich hatte, waren 3 Relays richtig schnell 13:42 <@jrandom> postman: habe ich vergessen: Wird es Unterstützung dafür geben, dass der lokale SMTP-Relay direkt mit dem SMTP-Relay von jemand anderem spricht, statt über deine Nodes zu gehen? 13:42 <+postman> cervantes: innerhalb von 10 Sekunden waren sie synchron :) 13:43 <@jrandom> (oder vielleicht erst später) 13:43 <+postman> jrandom: die I2P-Mail-Relays werden von mehreren Leuten betrieben und sind die bevorzugten Ziele zum Routen von Mail 13:43 <cervantes> postman: du könntest eine exponentielle Verzögerung in die Sendequeue einführen 13:43 <cervantes> falls es ein Problem wird 13:43 <+postman> jrandom: also kann das Senden an andere Destinations unter bestimmten Umständen praktisch sein 13:44 <@jrandom> ja, unter anderen Umständen aber gefährlich 13:44 <cervantes> je mehr Mail du sendest, desto länger wird die Mail in die Warteschlange gelegt ... sollte den Relays Zeit geben, aufzuholen 13:44 <+postman> jrandom: aber wenn der Besitzer eines Nodes seine IMIO-Destination offenlegt, könnte er unkontrolliert zugespammt werden :) 13:44 <@jrandom> genau 13:44 <@jrandom> andererseits gilt das Gleiche, wenn die I2P-Mail-Relays feindselig sind 13:45 <+postman> jrandom: in der Tat, es ist eine WOT-ähnliche Konstruktion 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: ich kann einen Relay-Betreiber nicht daran hindern, ein Quota von 0 für deine Adresse zu verteilen 13:45 <@jrandom> ’k, super. Ja, darum müssen wir uns jetzt nicht kümmern 13:45 <+postman> :) 13:46 <+postman> ok 13:46 <+postman> . 13:46 <@jrandom> ok, cool, danke für das Update. Wirklich spannende Sachen 13:46 <@jrandom> ok, weiter zu 3) i2p-bt-Updates 13:46 <@jrandom> duck: ping 13:46 <@duck> hi 13:47 <@duck> Gestern wurde BitTorrent 4.0.0 veröffentlicht 13:47 <ant> <dm> klingt deutsch 13:47 <@duck> worauf wir mehr oder weniger gewartet haben, bevor wir mit 0.2 anfangen 13:47 <@duck> habe eine Aufgabenliste/To-do geschrieben: http://pastebin.ca/raw/7037 13:47 <@duck> (sorry, mein WWW ist gerade down) 13:48 <@jrandom> cool 13:48 <legion> Welchen Zeitplan haben wir für 0.2 ungefähr? 13:48 <@duck> Ziel waren 4 Wochen 13:49 <legion> cool 13:49 <@duck> wie ihr seht, ist RawServer (der Teil, der mit I2P kommuniziert) die größte Aufgabe 13:50 <@duck> . 13:50 <@duck> eine kurze Umfrage: 13:50 <legion> ja, dessen bin ich mir sehr bewusst :) 13:50 <@duck> wer plant, einen i2p-bt-Fork zu erstellen? 13:50 <@jrandom> cool, gibt es etwas, womit die Leute helfen können? 13:50 <@jrandom> heh 13:51 <ant> <dm> ich 13:51 * jrandom greift sich einen Löffel 13:51 <ant> <dm> bin willig zu helfn 13:51 <legion> ich 13:51 <ant> <dm> bin schwul 13:51 <legion> Ich arbeite an einem Fork 13:52 <@duck> gut, dann weiß ich, wen ich nicht ernst nehmen sollte. 13:52 <@duck> wirklich, ich halte das für albern; Ressourcen zu bündeln könnte euch viel weiter bringen 13:53 <@jrandom> oder wenn es bessere Wege gibt, könnt ihr duck vielleicht überzeugen, so zu arbeiten? 13:53 <named> Ich werde einen Fork in QBasic schreiben, bitte nehmt mich ernst. 13:53 <@duck> Ich werde versuchen, den Prozess offener zu gestalten, sodass andere sehen können, was geplant ist usw 13:53 <ant> <dm> deine Offenheit überzeugt uns nicht. FORK! FORK! FORK! FORK! 13:53 <@duck> wenn ihr weitere Vorschläge habt 13:54 <ant> * dm hebt legion auf seine Schultern. 13:54 <legion> hmm, das mag stimmen, aber bei dem, was ich mache, wollt ihr vermutlich nicht, dass ich den Hauptentwicklungsprozess von i2p-bt verunreinige ;) 13:54 <ant> <dm> FORK! FORK! FORK! FORK! 13:54 <@jrandom> legion: was machst du, das duck nicht unterstützen möchte? 13:55 <@duck> legion: Glückwunsch, wenn man nach 'i2p bittorrent' googelt, ist eine Ankündigung „Windows I2P Bittorrent Version 1.0“ auf Platz 1 13:55 <@jrandom> Jesus 13:56 <bla> jrandom: Ja? 13:56 <+postman> jrandom: ja, die werden diesem Netzwerk bald den Hintern aufreißen :) 13:56 <bla> ;) 13:56 <named> 1.0? Verdammt, ich benutze 0.1.8! 13:56 <Ragnarok> oje 13:57 <legion> omfg, echt?! Ich kann’s nicht glauben... das ist irre. 13:57 <@duck> wie auch immer, ich glaube, dazu gibt es nicht viel Neues zu sagen 13:57 <legion> Mein 1.0-Release basiert auf 0.1.8; wenn du 0.1.8 laufen hast, bist du ok. 13:58 <@jrandom> (und das 1.0-Release ist eine .exe, die niemand überprüft hat, YMMV) 13:58 <legion> Ich habe es schlecht benannt und nummeriert, sorry, nochmal dafür. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> an jedem Tag der Woche 13:59 <@duck> leicht verwandt: 13:59 <@jrandom> ok, noch etwas zu 3) i2p-bt, oder gehen wir weiter zu 4) ??? 13:59 <+postman> legion: wann wird es den Sourcecode zum Download geben? 13:59 <frosk> "I2P-BT 0.1.8 läuft bisher ziemlich gut und stabil. Ich sehe persönlich keinen Grund, auf I2P-BT 1.0 zu aktualisieren" (im Forum gesehen) 13:59 * jrandom seufzt 13:59 <@duck> letzten Monat hat Bram Cohen an irgendeiner Universität einen Vortrag über BitTorrent gehalten 14:00 <@duck> ziemlich interessant: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (Lerneffekte aus großen P2P-Programmen, plus einige BitTorrent-Details erklärt) 14:00 <@duck> . 14:01 <@jrandom> word 14:01 <@duck> postman: legion hat etwas Sourcecode veröffentlicht 14:01 <ant> <dm> ist er der Erfinder von BT? 14:01 <@duck> aber laut smeghead ist es nicht dasselbe wie die .exe 14:01 <@jrandom> dm: ja 14:01 <legion> Es gibt einen Entwickler-Source, den du hier herunterladen kannst: http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 14:02 <+postman> k, schaue ich mir an 14:02 <ant> <dm> ist die exe ein direkter Compile dieses Sources? 14:03 <legion> obwohl die 1.0-Quelle eigentlich nur 0.1.8 mit einem Patch von smeghead ist, kompiliert und hübsch gepackt. 14:04 * cervantes geht rüber zu 4)??? und wartet, bis alle nachkommen 14:04 <ant> <dm> die Frage bleibt unbeantwortet 14:04 <ant> <dm> Legion, haben Sie einen Code Red angeordnet oder nicht??? 14:04 <@jrandom> *hust* 14:04 <legion> Vielleicht sollten wir zum Thema zurückkommen, meine BT-Client-Diskussion ist nach #itorrent umgezogen 14:05 <@jrandom> ok, 4) ??? 14:05 <@jrandom> gibt es sonst noch etwas, das jemand ansprechen möchte? 14:05 <@jrandom> aum: du hattest etwas? 14:06 <ant> <dm> stasher ist zurück? 14:06 <legion> Ich sehe gerade etwas merkwürdiges Verhalten mit 0.5.0.2 bei Phasen mit hohem Traffic... 14:06 <aum> ja 14:06 <aum> ich möchte die Frage der automatisierten Tunnel-Erzeugung/-Verwaltung aufwerfen 14:07 <ant> <dm> weiter 14:07 <+detonate> Es gibt eine NullPointerException im Systray-Ding unter Windows, ist mir gerade aufgefallen 14:07 <aum> es ist 1337, dass die Web-Konsole jetzt erlaubt, manuell Tunnels zu erstellen/zu löschen/zu verwalten 14:07 <@jrandom> detonate: kannst du sie in die Bugzilla werfen? 14:07 <aum> aber ich bin auch fest der Meinung, dass es immer eine zuverlässige und bequeme Möglichkeit für Programme geben sollte, Tunnels zu verwalten 14:08 <@jrandom> aum: niemand widerspricht. Wir brauchen das, und wir werden es haben. Nur noch nicht. 14:08 <ant> <dm> kann man das nicht über SAM machen? 14:08 <aum> mir ist bei meiner jüngsten Rückkehr zu I2P aufgefallen, dass die pysam-Bibliothek nicht mehr funktioniert 14:08 <septu_ssh> ich habe danach auch eine kurze Frage 14:08 <aum> was eine Enttäuschung war 14:08 <@jrandom> das SAM-Protokoll funktioniert, pysam nicht 14:08 <Ragnarok> hat es jemals funktioniert? 14:09 <aum> korrekt 14:09 <aum> pysam hat früher brillant funktioniert 14:09 <legion> In solchen Phasen gibt es 1000+ Tunnels, an denen mein Node beteiligt ist, und mehrere Sekunden Lag und Verzögerung. 14:09 <@jrandom> legion: ja, die Anzahl der Tunnels liegt an älteren Builds 14:09 <cervantes> ah mymodesty 14:09 <cervantes> eerm pymodesty 14:09 <aum> ich schreibe derzeit ein Modul 'i2ptunnel.py', das Klassen definiert, die eine einfache Tunnel-Verwaltung ermöglichen 14:10 <legion> also, wenn ältere Builds nicht verbunden würden, wäre das Networking deutlich flüssiger? 14:10 <@jrandom> ’k, ich weiß nicht, ob das die richtige Langzeitlösung ist, aber wenn es dir die Lücke jetzt überbrückt, cool 14:10 <@jrandom> legion: diese Tunnels sind nicht das Problem 14:11 <aum> nun, die Klassen-Interfaces können bleiben, auch wenn sich der zugrundeliegende Mechanismus ändert 14:11 <@jrandom> ’k 14:11 <legion> sind sie nicht? 14:12 <legion> Wenn es wenige Tunnels gibt, gibt es sehr wenig Lag und Verzögerung... 14:12 <cervantes> legion: sorry, aum bringt gerade ein paar Fragen vor, wenn du kurz Geduld hast 14:12 <legion> es kommt mir nur seltsam vor. 14:13 <legion> ok 14:13 <@jrandom> Ich mache mir nur Sorgen, dass wir berücksichtigen müssen, was in der Vergangenheit funktioniert hat – die Web-Konfiguration funktioniert und wird gepflegt, weil sie jeder benutzt. Vielleicht wäre es am besten, deine App erstmal mit manueller Tunnel-Erzeugung zum Laufen zu bringen, das wäre effizienter? 14:13 <@jrandom> einfach damit es stets etwas gibt, das i2ptunnel.py benutzt, um es zu stressen 14:13 <aum> wir scheinen zu blockieren 14:13 <+detonate> jrandom:sicher 14:14 <ant> <dm> dann machen wir weiter 14:14 <aum> ich will keine Zeit in die Entwicklung meiner App investieren, bis ich eine Tunnel-Management-API habe, auf die ich mich verlassen kann 14:14 <septu_ssh> \o. - Punkt anzusprechen 14:14 <cervantes> realistischerweise kann ich mir allerdings nicht vorstellen, dass das Tunnel-Interface in den nächsten paar Monaten überarbeitet wird... 14:14 <@jrandom> aber du siehst sicher, dass wir eines trivial hinzufügen können 14:14 <cervantes> eine Zwischenlösung ist also sinnvoll 14:15 <named_> Könnte die Web-Konfiguration nicht irgendeine Art API haben, die aums Programm manipuliert? 14:15 <@jrandom> named_: ja 14:16 <@jrandom> es ist trivial, etwas hinzuzufügen, um sichere Steuerung per URLs zu erlauben, aber es ergibt nur dann Sinn, wenn es etwas gibt, das es braucht 14:16 <@jrandom> sonst vergammelt es nur 14:16 <aum> named_: das wäre schön und könnte funktionieren, wenn es ein hartkodiertes Passwort in der Config gäbe, das Client-Programme zusammen mit den Tunnel-Steuerfeldern per POST mitsenden müssen 14:16 <cervantes> Ich persönlich würde gern das ganze Tunnel-System komplett überarbeitet sehen; wenn du von Anfang an ein Tunnel-Management-Interface einbaust, musst du dir keine Gedanken über den Mehraufwand machen, ein separates Interface zu pflegen 14:17 <@jrandom> ja, die Proxys brauchen eine Menge Arbeit, vor der ich mich so gut es geht drücke :) 14:17 <aum> SAM ist für manche Situationen gut, für andere schlecht 14:17 <cervantes> aber das liegt noch etwas weiter vorne... 14:17 <fedo> ( 14:18 <@jrandom> aum: aber als Zwischenlösung könntest du nicht einfach eine der drei verfügbaren Methoden nutzen? 14:18 <cervantes> d. h., wenn das Webinterface selbst die API verwendet, gibt es keinen Wartungsaufwand 14:18 <@jrandom> genau. Das Webinterface benutzt die TunnelControllerGroup 14:19 <aum> Die Nutzung von SAM wird schwierig, wenn man bestehende Libs einsetzen will, die stark von Standard-TCP-Sockets abhängen 14:19 <aum> jrandom: die I2PTunnel-CLI funktioniert nicht zum Öffnen von Server-Tunnels, deshalb schreibe ich gerade Code, um die TunnelControllerGroup zu verwenden 14:19 <@jrandom> aum: bestehende Libs müssen sorgfältig auditiert werden. Zum Beispiel legt das gzip-Utility selbst sensible Daten offen 14:19 <aum> ich code während wir sprechen 14:21 <@jrandom> Ich bin sicher, dass die CLI für Server-Tunnels funktioniert, aber die Nutzung der TunnelControllerGroup ist vorzuziehen, wenn du es so brauchst 14:21 <@jrandom> ok, hat sonst noch jemand etwas anzusprechen? 14:22 <septu_ssh> Meine Frage betrifft eine verteilte Version der hosts.txt: Eine DHT-Tabelle wird derzeit für routerInfo verwendet, könnte man das nicht auf eine verteilte Version von DNS ausweiten? Die DNS-DHT könnte Abbildungen von www.bla.i2p auf die eepsite-SHA enthalten, und die Einträge würden von einem 'I2P Registrar' signiert... Kommentare? Gegenargumente? 14:22 <mancom> eine Frage zur Roadmap: Ist 0.6 noch für April geplant? 14:22 <@jrandom> septu_ssh: nicht-routing-bezogene Daten kommen über meine Leiche in die netDb ;) 14:23 <septu_ssh> jrandom: nicht dieselbe DB 14:23 <septu_ssh> eine andere verteilte DB 14:23 <aum> jrandom: hast du meinen Bugreport gesehen? Der CLI-Befehl 'server' funktioniert /nicht/ 14:23 <maestro^> septu_ssh: es gibt keinen I2P-Registrar 14:23 <@jrandom> septu_ssh: Beim Naming gibt es viele gefährliche Aspekte, mit einigen zentralen Trade-offs. Hast du die Naming-Diskussion auf ugha.i2p gesehen? 14:24 <@jrandom> septu_ssh: ah, eine DHT auf I2P ließe sich sicher verwenden, um Einträge zu verteilen, allerdings wären diese Namen nicht sicher, wenn sie als globale Einträge behandelt würden 14:26 <@jrandom> aum: ich habe es täglich genutzt bis vor ein paar Wochen, hast du meine Antwort gesehen? 14:26 <@jrandom> maestro^: das ist der Plan 14:26 <@jrandom> äh, mancom: 14:26 <cervantes> aum: Ich habe eine Antwort auf die i2plist-Mail von jr, ist sie noch nicht bei dir angekommen, oder besteht das Problem weiterhin? 14:26 <septu_ssh> Der einzige Grund, warum ich einen 'Registrar' vorschlage, ist, dass es sonst zu Kollisionen kommen kann 14:26 <@jrandom> septu_ssh: freunde dich mit Kollisionen an :) 14:26 <@jrandom> global eindeutiges, menschenlesbares, verteiltes und sicheres Naming existiert nicht 14:27 <septu_ssh> das kann auch in der hosts.txt passieren, wenn sie manuell bearbeitet wird, aber das Problem bleibt dasselbe 14:27 <@jrandom> lass den ersten Parameter weg, und du bist goldrichtig 14:27 <aum> jrandom: ich habe deine Antwort gesehen - und ich habe streaming.jar in meinem cp 14:27 <septu_ssh> postman betreibt einen zentralen Node für Mail, also gibt es ein gewisses Vertrauenselement im Netzwerk; sicher würde jemand einem Registrar vertrauen, den Namensraum zu verwalten? 14:27 <@jrandom> ok, cool, und es kommt immer noch mit diesem Stacktrace zurück, aum? 14:28 <aum> ja 14:28 <@jrandom> septu_ssh: postman fungiert nur als zentrales Element für postmans Outproxies und Inproxies 14:28 * Ragnarok muss wirklich mal dazu kommen, das Adressbuch-Dokument zu schreiben... 14:28 <aum> das ist, wenn ich die CLI manuell starte, ein genkeys mache und dann ein 'server' mit der von genkeys erzeugten privkeyfile ausführe 14:28 <@jrandom> septu_ssh: niemand wird irgendwem vertrauen, einen Namensraum zu verwalten. Zensur == Druck auf diesen Registrar ausüben. 14:28 <maestro^> jeder ist im Grunde sein eigener Registrar 14:29 <maestro^> du vertraust deinen Freunden und sie vertrauen dir 14:29 <aum> oh Mist, ich habe einen alten Classpath erwischt 14:29 * aum testet nochmal 14:30 <ant> <dm> ok, ich werde der Registrar sein. 14:31 <ant> <dm> ich werde so unparteiisch sein wie ich kann... cool? 14:31 <septu_ssh> hmmm, ok, dann zurück ans sprichwörtliche Reißbrett... 14:31 <@jrandom> septu_ssh: ein guter Ausgangspunkt zum Nachlesen ist http://zooko.com/distnames.html :) 14:32 <@jrandom> jeder will es, aber das, was sie wollen, ist einfach nicht sicher. Wir haben eine Lösung, die sicher ist, aber wir geben globale Eindeutigkeit auf 14:33 <septu_ssh> hmmm, ok 14:33 <@jrandom> ok, hat sonst noch jemand etwas für das Meeting? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - ok, CLI 'server' funktioniert jetzt, aber ich habe nie eine 'Job Number' für den Tunnel bekommen 14:34 <@jrandom> hmm, stimmt, es läuft endlos 14:34 <aum> oh, ich muss 'list' machen, um die Job-Nummer zu bekommen 14:36 <@jrandom> ok, cool, wenn es sonst nichts gibt... 14:36 * jrandom holt aus 14:36 * jrandom *baf*t das Meeting zu