I2P-Entwicklertreffen - 20. Dezember 2005

15:20 <jrandom> 0) hi 15:20 <jrandom> 1) Net-Status 15:20 <jrandom> 2) I2PSnark-Updates 15:20 <jrandom> 3) Syndie Blog-UI (Benutzeroberfläche) 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) hi 15:20 * jrandom winkt 15:20 <jrandom> wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> ok, springen wir rein in 1) Net-Status 15:22 <jrandom> Ich habe nicht viel hinzuzufügen zu dem, was in den Statusnotizen steht. 15:22 <+Complication> Wenn es nicht die gelegentlichen OOM (Out-of-Memory)-Fehler gäbe, würde ich mich trauen, es als gut zu bezeichnen 15:22 <jrandom> die Lasttests sehen ziemlich vielversprechend aus, was darauf hindeutet, dass wir noch viel Spielraum haben, die Performance zu verbessern 15:23 <+Complication> Und ich schätze, die OOM 15:23 <jrandom> heh, i2psnark-bezogene OOMs? oder schon davor? 15:23 <+Complication> tragen zur Flatterhaftigkeit bei, wenn entweder i2p-bt-, i2psnark- oder i2p-rufus-Instanzen … Dinge tun. 15:24 <zzz> Meine Theorie ist, dass der gestiegene Torrent-Traffic die IRC-Zuverlässigkeit etwas beeinträchtigt 15:24 <+Complication> (vielleicht sollte ich die SAM-Merkwürdigkeit nicht OOM nennen, da ich es mir nicht genau angesehen habe, aber es ist definitiv einer der Faktoren) 15:24 <jrandom> hmm, da bin ich nicht sicher, der IRC-Status war ähnlich wie vor den letzten Snark-Updates 15:25 <+Complication> Bandbreite war stabil, insbes. tunnel auch stabil … nur ab und zu Abstürze 15:26 <zzz> Wie auch immer, ich bin optimistisch, dass die tunnel build fixes in 0.6.1.8 die IRC-Erfahrung verbessern werden 15:26 <+Complication> Aus bekannten Gründen, die hoffentlich verschwinden, wenn ihre Zeit gekommen ist :) 15:26 <jrandom> jau, denke ich auch, zzz, daher werden wir wahrscheinlich in den nächsten ein, zwei Tagen ein Release haben 15:26 <+legion> Nun, IRC ist vielleicht einfach zu empfindlich, vielleicht wäre so etwas wie Jabber besser? 15:26 <zzz> besonders für Leute mit langsameren Maschinen und/oder Verbindungen 15:27 <jrandom> Jabber würde daran nichts ändern 15:27 <+Complication> Besonders mit tunnel redundancy auf 2 15:28 <+bar> ich würde sagen, IRC ist ein ausgezeichnetes Scheiß-o-Meter, um das Netzwerk-Wetter zu bestimmen 15:28 <+legion> Ja, es weht nur ein kleines Lüftchen und IRC kackt ab 15:28 <+bar> genau :) 15:28 <+Complication> Mir fällt auf, dass nach dem Shitlisting-Fix „Recent“ dazu neigt, immer „Known“ zu übersteigen 15:29 <+Complication> Könnte das daran liegen, dass „Known“ shitlistete Peers nicht enthält, „Recent“ aber schon? 15:29 <jrandom> jau, IRC ist ein guter Blick auf die Dinge, da es erhebliche Unterschiede bei verschiedenen Nutzern zeigt (z. B. dreamtheaterfan hat immer Probleme, etc.) 15:30 <jrandom> hmm, das ergibt Sinn, Complication 15:30 <+Complication> (Ich weiß es nicht sicher, nur eine Vermutung) 15:30 <jrandom> (da shitlistete Peers aus der netDb fallen, ihre Profile aber nicht entfernt werden) 15:32 <+Complication> Dann scheinen die Indikatoren OK zu sein (wollte nur fragen, falls nicht) 15:33 <jrandom> ok, noch etwas zu 1) Net-Status? 15:33 <jrandom> wenn nicht, gehen wir weiter zu 2) I2PSnark-Updates 15:33 <tealc_> welche Art von Updates gibt es? 15:34 <jrandom> siehe http://dev.i2p.net/pipermail/i2p/2005-December/001240.html für eine kurze Auflistung ;) 15:34 <jrandom> im Grunde kann I2PSnark jetzt mehrere Torrents gleichzeitig über eine einzelne I2P-Destination handhaben, hat ein Webinterface und ist in die router-Konsole integriert 15:35 <tealc_> ich nutze die neuesten CVS-Builds und i2psnark verursacht eine Menge Heap-Speicherfehler oder so 15:35 <+Complication> …und es kann auch von Azureus erstellte Torrents mit seltsamen Meta-Tags verarbeiten. 15:35 <+Complication> An denen es zuvor hängen geblieben ist. 15:35 <jrandom> ah, ja, da sind noch ein paar Dinge, die ich da debugge, tealc_ 15:35 <jrandom> (wie in den wöchentlichen Statusnotizen erwähnt ;) 15:35 <jrandom> ah richtig, Complication 15:36 <jrandom> oh, außerdem haben die Azureus-Leute einen Bug in ihrem Tracker gefixt, der I2PSnark von der Nutzung abgehalten hat 15:36 <jrandom> (also sollten Leute, die Azureus-Tracker vor B16 betreiben, baldmöglichst upgraden) 15:37 <+bar> ich hätte gern die Möglichkeit, den I2PSnark-Autostart leicht zu deaktivieren (für Low-BW-Szenarien, etc.) 15:38 <jrandom> das sollte sich leicht einbauen lassen 15:38 <+bar> klingt super 15:39 <jrandom> ok, noch etwas zu 2) I2PSnark-Updates? 15:40 <jrandom> wenn nicht, gehen wir weiter zu 3) Syndie Blog-UI 15:40 <zzz> zwei Daumen hoch für den neuen i2psnark – gute Arbeit 15:41 <jrandom> gracias, mjw hat die harte Arbeit gemacht und Snark so leicht erweiterbar gemacht 15:41 <jrandom> ok, wie in den Statusnotizen erwähnt, hat Syndie jetzt eine neue Blog-UI 15:42 <jrandom> Ich denke, sie bietet einen Ausgleich zwischen Whitelists und Blacklists und geht die verschiedenen Spam-Probleme an, die auftreten können 15:43 <jrandom> das rollen wir im nächsten Release aus, sodass ihr in ein, zwei Tagen damit herumspielen könnt 15:43 <+legion> Wird Spam wirklich in absehbarer Zeit zu einem großen Problem? 15:44 <+Complication> legion: wie uns jemand freundlicherweise demonstriert hat, könnte es so kommen 15:44 <jrandom> nee, Blacklists kümmern sich um Autoren, die fluten, und Whitelists um Spammer, die viele Autoren erstellen 15:44 <dust> (Anonymität bringt bei manchen Menschen das Schlimmste hervor) 15:44 <jrandom> (also ist Spammen kein Problem) 15:45 <+Complication> (Obwohl ich glaube, der Kerl hat Schlüssel regeneriert, um permanentes Blacklisting zu vermeiden, was schon etwas bremst.) 15:45 <+Complication> Wenn auch keine große Bremse, daher stimme ich voll zu, dass Whitelists ebenfalls gut sind. :) 15:46 <+bar> vielleicht wäre eine Hashcash-Lösung irgendwann gangbar, falls nötig 15:46 <jrandom> falls nötig, aber ich sehe nicht, warum es nötig wäre 15:46 <+bar> einverstanden, momentan sehe ich das auch nicht 15:46 <+Complication> bar: so was wie „nicht anzeigen, es sei denn, sie haben sich die Mühe gemacht, ein paar Zahlen zu berechnen“? 15:47 <+bar> ja, so in der Art 15:47 <+Complication> Klingt möglich, auch wenn vermutlich unnötig. 15:47 <+bar> vermutlich ja. 15:47 <jrandom> wenn eine Gruppe von Spammern ständig mit vielen neuen Autoren fluten würde, könnten Leute anderen immer noch von neuen Autoren erzählen, indem sie ihre Lesezeichen und Blog-Verweise in ihrem eigenen Blog posten 15:47 <+Complication> Oder eher hoffentlich unnötig. 15:48 <+Complication> Wäre gut zu überlegen, ob Syndie solche Funktionalität aufnehmen kann, falls je Bedarf entsteht. 15:49 <jrandom> jau, kann es, mit Headern im Blogpost oder in den eigenen Metainfos des Blogs 15:49 <jrandom> äh, Metadaten (verdammt sei bt!) 15:51 <jrandom> ok, wenn es zu 3) Syndie nichts weiter gibt, springen wir zu 4) ??? 15:51 <jrandom> hat sonst noch jemand etwas, das er im Meeting ansprechen möchte? 15:51 <+legion> ja, ein paar Dinge 15:52 <+legion> zuerst clunk 15:52 <jrandom> cool, ja, clunk klingt interessant 15:52 <+legion> Wie ich heute früher in i2p-chat erwähnt habe, arbeite ich daran, es mit cygwin und/oder mingw zum Kompilieren zu bringen. 15:53 <+legion> Bisher ist nur der Client kaputt, der Rest inkl. Server kompiliert und scheint zu funktionieren 15:53 <jrandom> nett 15:54 <tealc_> i2p könnte sich als echtes Problem für George Bushs grenzenloses Überwachungsprogramm erweisen. Wir sehen uns in den Todeslagern, bringt die Karten mit, ja 15:54 <+legion> Ich versuche nicht nur herauszufinden, warum der Client kaputt ist, sondern es auch zu beheben. Im Moment stecke ich fest. 15:56 <+legion> Das andere, worüber ich sprechen wollte: Könnte ein default tunnel zu meinem Jabber-Server im nächsten Update enthalten sein? Einfach um es für alle, die Jabber ausprobieren wollen, leichter zu machen. 15:57 <tethra> 20:34:37 <jrandom> wenn eine Gruppe von Spammern ständig mit vielen neuen Autoren fluten würde, könnten Leute anderen immer noch von neuen Autoren erzählen, indem sie ihre Lesezeichen und Blog-Verweise in ihrem eigenen Blog posten <--- vielleicht könnte so etwas wie polecats Ansatz zur Kombination von Vertrauen hier eine Rolle spielen? (d. h. sowohl Spammer blockieren -und- populäre Autoren fördern.) 15:57 <tethra> </$0.02> 15:58 <+polecat> Das wäre ein primitives Beispiel meiner Vertrauensnetz-Idee, mit einer Heuristik von 100% Vertrauensübertragung, ja. 15:58 <jrandom> legion: hmm, eine deaktivierte Konfiguration für neue Nutzer hinzuzufügen ist leicht, aber meine Zurückhaltung betrifft die Protokoll-Filterung (und welche Clients welche Infos leaken). Wie sind deine Erfahrungen mit verschiedenen Clients? 15:59 <jrandom> jau, es gibt viel Raum, Vertrauensmetriken in Syndie zu integrieren 16:01 <+legion> Nun, soweit ich weiß, leakt jeti nicht, abgesehen vom Dateitransfer, der in meinen Servereinstellungen ohnehin deaktiviert ist. Möglicherweise wird es in der nächsten jeti-Version korrigiert. Abgesehen davon weiß ich über die anderen Clients nichts. 16:02 <+legion> Ich weiß auf jeden Fall, dass Groupchat solide ist, unabhängig von den Clients; es ist nur der Kontakt außerhalb des Groupchats, bei dem manche Clients leaken könnten, wobei ich mir nicht sicher bin. 16:03 <jrandom> hmm, Leaken ist nicht wirklich boolesch, es ist eine Frage, /welche Informationen/ die Clients leaken, nicht ob sie irgendwelche Informationen leaken 16:04 <+legion> Richtig, ich meinte natürlich kritische Informationen wie IP-Adressen, obwohl gute Clients, wenn sie diese Informationen leaken, sie nur als 127.0.0.1 oder localhost melden sollten 16:06 <+legion> Daher würde ich empfehlen, nur bekannte Clients zu verwenden, die nicht leaken, wie jeti. 16:07 <zzz> könntest du deiner Client-Tabelle eine Spalte „verifiziert: leakt nicht“ hinzufügen? 16:07 <jrandom> es wäre hilfreich, wenn du dokumentieren könntest, was jeti leakt und was nicht (so in der Art, was postman für den SMTP- und POP-Proxy zusammengestellt hat) 16:08 <+legion> Laut jeti-Entwickler leakt es nichts, was die Anonymität kompromittieren würde. Das steht ohne Zweifel fest. Ich habe mir auch den Quellcode angesehen und nichts gefunden, was mich das Gegenteil denken ließe. 16:09 <jrandom> dass der Entwickler das sagt, mag sicher sein, aber was der Entwickler unter Anonymität versteht, ist eine andere Frage ;) 16:09 <+legion> Ja, zzz, ich könnte so eine Spalte hinzufügen 16:09 <jrandom> Ich bezweifle nicht, dass jeti sich korrekt verhält, aber wir müssen wissen, was das bedeutet 16:10 <zzz> scheint so, als könne man Nicht-Leaken nur durch Protokollmitschnitt verifizieren 16:10 <zzz> nicht durch Blick in den Quellcode oder durch Nachfragen beim Entwickler 16:12 <jrandom> ok, hat noch jemand etwas fürs Meeting? 16:12 <+bar> nur die Erinnerung, amd64 jbigi nicht zu vergessen 16:13 <+bar> (aber ich wette, es steht auf deiner Todo-Liste) 16:13 <jrandom> jau :) 16:13 <jrandom> (win amd64, nämlich, linux amd64 läuft bereits) 16:13 <jrandom> aber, wenn es nichts weiter gibt … 16:14 * jrandom leitet das Ende ein 16:14 <+bar> ja, win amd64. 16:14 * jrandom *baf*t das Meeting ab