I2P-Entwicklertreffen - 10. Januar 2006

15:26 <jrandom> 0) hi 15:26 <jrandom> 1) Netzstatus 15:26 <jrandom> 2) Durchsatz-Profiling 15:26 <jrandom> 3) Syndie-Blogs 15:26 <jrandom> 4) persistente HTTP-Verbindungen 15:26 <jrandom> 5) I2Phex gwebcache 15:26 <jrandom> 6) ??? 15:26 * jrandom winkt 15:26 <jrandom> Wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2006-January/001247.html 15:27 <jrandom> (ja, ich weiß ... wir brauchen ein 7) Noch eine Sache ...) 15:28 <jrandom> springen wir rein zu 1) Netzstatus 15:28 <jrandom> Im Allgemeinen scheint alles beim Alten zu sein, abgesehen von dem, was in der Mail steht. 15:28 <jrandom> Möchte jemand etwas zu 1) ansprechen? 15:30 <jrandom> ok, wenn nicht, gehen wir weiter zu 2) Durchsatz-Profiling 15:31 <tethra> klingt cool, aber darf ich fragen, was das Ziel ist? 15:31 <jrandom> schnelle Peers finden 15:31 <tethra> (verzeiht meinen Mangel an Witz und Takt) 15:31 <tethra> ah, cool. 15:32 <jrandom> Im Grunde war unser altes Geschwindigkeits-Profiling nicht so toll (siehe die Statusnotizen der letzten Woche für eine Zusammenfassung), und das hier scheint ziemlich gut darin zu sein, Peers zu finden, von denen ich weiß, dass sie schnell sind 15:32 <jrandom> (Ich weiß, dass sie schnell sind, weil ich geschummelt und sie mit nicht-anonymen Techniken gemessen habe) 15:33 <tethra> schockierend! ;) 15:33 <jrandom> ((ja, jemand könnte verrückt gewesen sein und Angriffe gestartet haben, um meine Messungen zu verwirren, aber, nun ja, ich bezweifle es ;) 15:33 <tethra> haha 15:33 <tethra> süß, also sollte das Client-Tunnel eher dazu bringen, einen 'guten' Peer zu finden, und vermutlich die 'schnellen' Peers weniger unter Druck setzen, oder? 15:35 <tethra> s/'good'/fast/ 15:35 <jrandom> Ja zum Ersteren, aber nicht wirklich zum Letzteren – es wird den Druck auf sie nicht verringern, aber es wird den Leuten erlauben, sie effektiver zu nutzen 15:35 <@cervantes> Ich schätze, diejenigen mit schnellen Peers müssen hoffen, dass die Peer-Drosselung gut genug ist, um die zusätzliche Teilnahme abzufangen 15:36 <jrandom> z. B. statt $slow-->$fast-->$fast wird es $fast-->$fast-->$fast haben 15:36 <tethra> ah, verstehe 15:36 <jrandom> ja, cervantes, ich habe auch auf das Kapazitätsprofil geachtet, und es hat seinen Zweck erfüllt 15:36 <@cervantes> großartig 15:37 <jrandom> Das Zusammenspiel zwischen Kapazität und Geschwindigkeit ist wichtig – Peers gelten nicht als schnell, wenn sie keine hohe Kapazität haben, selbst wenn ihre Geschwindigkeit höher eingestuft wird als die aller anderen 15:37 <@cervantes> wäre interessant zu sehen, wie sich das auf den Durchsatz auswirkt 15:37 <jrandom> (deshalb ist 'schnell' nur eine Abkürzung für 'schnell und hohe Kapazität') 15:37 <@cervantes> +h 15:37 <jrandom> ja, cervantes 15:39 <jrandom> ok, wenn es zu 2) nichts weiter gibt, springen wir rüber zu 3) Syndie-Blogs 15:40 <jrandom> Ich habe nicht viel mehr hinzuzufügen als das, was in der Mail steht 15:41 <@cervantes> sieht prima aus 15:41 <tethra> Mir persönlich gefällt sehr, wohin sich die Blogs entwickeln. Es scheint alles Bonus zu sein, könnte man sagen. 15:41 <tethra> :D 15:41 <+Complication> Etwas spät, sorry. 15:42 <jrandom> cool, es ist ähnlich wie ursprünglich, aber ich denke, die Blog-Ansicht hat Potenzial 15:42 <jrandom> willkommen zurück, Complication, keine Sorge, wir haben Logs :) 15:43 <+Complication> Lese gerade den Scrollback :) 15:43 <jrandom> Ich denke, es gibt für beide Ansichten ihren Platz, ich vermute, es hängt einfach vom Nutzer ab 15:43 <jrandom> (und vom Inhalt, und vom Autor) 15:45 <jrandom> Eine Sache ist allerdings, dass das HTML nicht so toll ist. cervantes hilft mir dabei, meine sehr grundlegenden Kenntnisse auf eine modernere Sicht zu bringen, aber es gibt noch viele Baustellen 15:46 <jrandom> Es wird fortlaufende Verbesserungen an Syndies Weboberfläche geben, und wenn irgendein HTML-Freiwilliger bei Formatierung, Design, CSS, Cross-Browser-Problemen usw. helfen wollte, wäre das sehr willkommen 15:47 <@cervantes> Abgesehen davon, dass es zwei öffnende <style>-Tags gibt, sieht der Code ziemlich sauber aus ;-) 15:47 <jrandom> heh, ups 15:48 <@cervantes> Ich denke, der Schwerpunkt wird darauf liegen, das Styling sauber und lesbar zu bekommen und vielleicht einige Vorlagen-Alternativen zu entwerfen 15:48 <jrandom> hmm 15:49 <jrandom> Das ist eine Sache, über die ich für die Blog-Ansicht nachgedacht habe – es wäre einfach, Leute bestimmte Attribute anpassen zu lassen (Farben, Schriften, Größen), aber ich bin nicht sicher, wie viel mehr 15:50 <jrandom> andererseits ist die Blog-Ansicht, wie die Thread-Ansicht, nur eine Vorlage über dem Syndie-Archiv 15:50 <@cervantes> nun, man will sicherlich keine installierbaren Vorlagen zulassen 15:50 <jrandom> also ist die Frage: Eine Vorlage für wen? 15:50 <jrandom> (welches Erfahrungsniveau bräuchten diejenigen, die die Vorlage benutzen) 15:51 <@cervantes> Ich dachte an eine einfache Popup-Konfigurationsoption, die jemand für seinen Blog auswählen kann 15:51 <jrandom> hmm? 15:51 <@cervantes> Ich möchte "Pony Look" 15:51 <jrandom> ah, ok 15:51 <@cervantes> also liefern wir Syndie mit einer Vielzahl von Skins aus 15:52 <jrandom> ja, vordefinierte Farben/Schrift/etc. 15:52 <jrandom> (und Icons, etc.) 15:52 <jrandom> Das ist etwas, das durch die Blog-Ansicht noch nicht wirklich umgesetzt wurde 15:54 <jrandom> Gute Idee mit dem einfachen Theme-Wähler, statt einem komplexen Optionssatz 15:54 <@cervantes> Eine Alternative wäre, dass jemand seine eigenen Vorlagen-Voreinstellungen als Download auf seiner Seite anbietet – die könnten in einen Theme-Ordner gespeichert werden 15:55 <@cervantes> Es liegt beim Einzelnen, ob er dem benutzerdefinierten Skin des Blog-Autors vertrauen will 15:55 <jrandom> ... vertrauen? 15:55 <jrandom> Nichts in Syndie wird unsicheres HTML oder CSS zulassen 15:55 <tethra> wie steht's mit unsicherem JavaScript/etc. 15:55 <jrandom> Die Skins wären Textdateien/Konfigurationsdateien/Bilder, statt jsp 15:55 <tethra> ? 15:56 <tethra> (Seiten leiten etwa mit JS auf nicht-anonyme Adressen weiter?) 15:56 <@cervantes> es hängt davon ab, ob ein Theme auch strukturelle HTML-Änderungen enthalten könnte 15:56 <@cervantes> okay, alles klar 15:56 <@cervantes> das würde es schön sauber und einfach halten 15:57 <jrandom> tethra: Ich bin ... unglaublich zögerlich bei JavaScript. Den neuen Blogpost heute von default gesehen? 15:57 <jrandom> "Ich bin nur neugierig: nutzt es AJAX? Die Seite scheint sich nicht als Ganzes zu aktualisieren..." 15:57 <tethra> nein, habe ich nicht. 15:57 <tethra> ich würde persönlich einen Weg finden, jegliches verwendete JS einfach rauszuwerfen. 15:58 <jrandom> Da Syndie *lokal* ist, ist es wahnsinnig schnell, und wir müssen uns nicht mit denselben Latenzproblemen herumschlagen 15:58 <tethra> weil ich dem nicht über den Weg traue. 15:58 <tethra> hmm :/ 15:58 <jrandom> cervantes: ja, ganz einfach – wir könnten sogar Dinge ermöglichen wie: Leuten, die ein Blog-Theme sehen, das sie mögen, erlauben, "dieses Theme klauen" zu sagen 15:59 <@cervantes> theoretisch könnte man eine Bibliothek "sicherer" Funktionen für Blog-Nutzer bereitstellen – aber wenn man alles Unsichere aus der Implementierung eines durchschnittlichen Browsers entfernt, bleibt einem die Funktion "alert();" 16:00 <jrandom> heh 16:00 <jrandom> (und dann hat man all diese Barrierefreiheits-Probleme von JavaScript) 16:00 <+Complication> cervantes: wohlgemerkt, alert() in einer Endlosschleife kann böse sein :P 16:00 * jrandom ist ziemlich stolz auf Syndies Lynx-Freundlichkeit 16:00 <tethra> lynx <3 16:02 <jrandom> ok, wenn es zu 3) nichts weiter gibt, springen wir rüber zu 4) persistente HTTP-Verbindungen 16:02 <jrandom> Ich habe nichts hinzuzufügen außer dem, was in der Mail steht ... zzz, bist du hier? 16:02 <@cervantes> es gibt andere Wege, eine *spuck* AJAX-UI umzusetzen, etwa eine Mozilla-Erweiterung 16:03 <jrandom> fire2pe++ :) 16:03 <jrandom> zzz scheint nicht da zu sein, daher müssen wir wohl später auf mehr Infos zu 4) warten 16:03 <@cervantes> fire2pe ist nur ein Helfer - syndilla meinst du ;-) 16:03 <jrandom> lol 16:04 <jrandom> (und die USB-Schlüsselbund-Version, syndog ;) 16:04 <jrandom> ok, weiter zu 5) I2Phex gwebcache 16:05 <jrandom> Complication: p1ng 16:05 <+Complication> Nun, da es die Integration ins Netz erleichtern würde ... 16:06 <+Complication> ...habe ich kürzlich daran gearbeitet, den gwebcache-Code, der bereits in I2Phex ist, wiederzubeleben 16:06 <+Complication> Er tut in diesem Stadium bereits sehr begrenzte Dinge (wie sauber abstürzen) :) 16:06 <+Complication> Nervt außerdem awup's Webcache-Server mit mäßigem Erfolg 16:07 <jrandom> lol, nice 16:07 <+Complication> Ich habe jedoch Hoffnung, dass ich es schließlich überarbeitet bekomme 16:07 <+Complication> (Vieles davon ist derzeit darauf ausgelegt, mit IP-Adressen umzugehen) 16:09 <jrandom> cool, viel Glück, und sag mir Bescheid, wenn ich irgendetwas tun kann, um zu helfen 16:09 <+Complication> Mach ich :) 16:10 <jrandom> ok, noch etwas zu 5) I2Phex gwebcache, oder sollen wir gemütlich rüberwandern zu 6) ??? 16:11 <jrandom> betrachte uns als rübergeschlendert 16:11 <jrandom> hat noch jemand etwas für die Sitzung? 16:11 <@cervantes> eine weitere Tasse Tee wäre nett 16:12 <tethra> heheh 16:12 <Pseudonym> wie steht's mit der Roadmap? 16:12 <jrandom> keine Änderungen 16:12 <Pseudonym> was bleibt für 0.6.2? 16:13 <jrandom> alles, was zu 0.6.2 gehört 16:13 * jrandom duckt sich 16:14 <Pseudonym> :-P 16:14 <@cervantes> etwas Bling-Bling 16:14 <Pseudonym> haben wir ein vorläufiges Datum/einen Zeitplan? 16:14 <jrandom> konkret die neue Kryptographie und Algorithmen für die Tunnel-Erstellung, die neuen Peer-Auswahlstrategien 16:14 <tethra> heheh 16:14 <jrandom> keine Daten und Zeitpläne (zumindest nicht in Meetings angekündigt ;) 16:15 <Pseudonym> gibt es bei den Peer-Auswahlstrategien mehr als das Durchsatz-Zeug, an dem du gearbeitet hast? 16:16 <jrandom> ja, diese Peer-Profiling-Änderungen sind Performance-Themen, nicht die anonymitätsbezogenen Peer-Auswahl- und Reihenfolgestrategien 16:16 <+Complication> jrandom: Erinnere ich mich richtig ... wenn ich vermute, dass sich die Kryptographie für die Tunnel-Erstellung auf Dinge bezieht, die auf der Mailingliste während der Diskussion über Predecessor- (Vorläufer-)Angriffe (und andere) besprochen wurden? 16:17 <jrandom> ja, Complication 16:17 <+Complication> s/related/relates 16:19 <+Complication> Du wirst versuchen, diese schicke kleine Datenstruktur zum Laufen zu bringen? 16:19 <jrandom> ja 16:20 <jrandom> (daher ist 0.6.2 nicht am Zwei-Wochen-Horizont ;) 16:20 <+Complication> Schick. Klingt interessant, ich sollte mich wohl darüber einlesen 16:21 <+Complication> Ich hoffe, es läuft reibungslos 16:21 <jrandom> Es wurde auf der Liste nur grob herumgewunken, noch keine Spezifikation digitalisiert 16:21 <tethra> Welche schicke Datenstruktur ist das, sorry? 16:21 <+Complication> Oh, und ich habe herausgefunden, warum der Link (aus der "moo"-Nachricht) nicht funktionierte. :D Es ist freedomarchives.i2p (im Plural, mit einem "s" am Ende) 16:21 <jrandom> Es wird nicht abwärtskompatibel sein, also wird „reibungslos“ nicht das Stichwort sein, aber hoffentlich tut es nicht zu weh :) 16:21 <jrandom> ah, verdammt 16:22 <jrandom> tethra: eine Datenstruktur, die es noch nicht gibt, zum Erstellen von Tunneln 16:22 <tethra> cool 16:22 <jrandom> (siehe die Predecessor-Threads von November oder so) 16:23 <tethra> Welche Vor-/Nachteile wird sie gegenüber der aktuellen haben? (falls es eine aktuelle gibt :o) 16:23 <jrandom> (siehe die Predecessor-Threads von November oder so) ;) 16:23 <tethra> ah, ok 16:23 <+Complication> Wenn ich mich recht erinnere, um die Tunnel-Erstellung für Beobachter weniger transparent zu machen 16:23 <tethra> "" 16:23 <tethra> ;) 16:23 <jrandom> aber es ist kein Vorschlag, es liegt nichts für 0.6.2 auf dem Tisch, bis all die Dinge vor 0.6.2 geklärt sind. 16:23 <jrandom> Sobald die Dinge, die funktionieren sollen, so funktionieren, wie wir sie brauchen, machen wir weiter. 16:24 <Pseudonym> abgesehen von schneller Peer-Auswahl, was funktioniert nicht? 16:25 <jrandom> schnelle Peer-Auswahl ist ein Teil von "guter Performance" 16:25 <jrandom> wir haben /wirklich/ gute Performance, für ein anonymes Netzwerk, aber nicht gut genug, um mit nicht-anonymen Netzwerken zu konkurrieren 16:25 <jrandom> um zu konkurrieren, müssen wir bessere Performance erreichen *und* Funktionen bieten, die sie anderswo nicht bekommen 16:26 <jrandom> (Anonymität verkauft sich nicht) 16:26 <Pseudonym> gibt es dabei mehr als die schnelle Peer-Auswahl? 16:27 <jrandom> In den letzten ein, zwei Monaten, beim Benchmarking verschiedener Aspekte von i2p, scheint die langsame Peer-Auswahl der kleinste Engpass zu sein. was der nächste Engpass sein wird, ist unbekannt. 16:27 <jrandom> (es gab auch unzählige Verbesserungen an verschiedenen Stellen zur Verbesserung der Performance) 16:27 <jrandom> (siehe http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD ) 16:28 <Pseudonym> also ... Release der neuen Peer-Auswahl diese Woche? ;-) 16:28 <teal`c_> i2p fühlt sich gut an 16:29 <jrandom> Pseudonym: ja, der neue Peer-Profil-Algorithmus ist im CVS und wird diese Woche mit 0.6.1.9 ausgerollt 16:30 <jrandom> ok, hat noch jemand etwas für die Sitzung? 16:30 <Pseudonym> cool 16:31 <jrandom> wenn nicht... 16:31 * jrandom holt aus 16:32 * jrandom *baf*t die Sitzung für geschlossen